These are unedited transcripts and may contain errors.
ADDRESS POLICY SESSION 5 MAY 2011 AT 11:00AM
CHAIR: So welcome back everybody to the second slot of the Address Policying withing withing with. To those gentlemen in the back, come in, find a seat. Stop the hallway discussions. Thank you.
So welcome back to the Address Policy Working Group. We're in parallel to DNS now so some loss is to be expected. I'm happy to see still so many of you come back, so it wasn't that boring.
Our agenda for the next 90 minutes signature: It's not that many points, so we have enough time to really go into detail on the first one. Alex from the RIPE NCC has explained that the current IPv6 PI policy is causing friction and I will give some more background on why the policies are the way they are, how it came to be. It might be easier to understand why things are the way they are today. We have been discussing this and we have some ideas how to fix it all in one go. And I think we will need lengthy discussion on that. Then we go into specific proposal that also relates to IPv6 PI policy about removal of the multi homing requirements and at the end of the time slot, Dave Wilson wants to show to you a document that he's been working on guidelines for transfers that wants feedback, needs some thought. After that it's lunch break. If we happen to end up very far before the end of our time, I might take over some things from Friday, but that's what we have in mind for now.
The discussion reminder slides, you've seen that before, just to make it clear again. We're not going to decide anything today, except agree on the way we want to work on things on the mailing list later on. So all the discussion go back to the mailing list and formally formal decisions are taken there. And I don't think I need to remind anyone about the microphones and so on, because you have done this perfectly well this morning. Thank you.
Returning to the PI discussion. At this point in time we have decided that getting the IPv6 policies right is the important bit and IPv4 is going to run out eventually. So I'm not going to focus on IPv4 today. This is only about IPv6 and this is the future of the Internet and if the Internet of the pass has policies so be it.
This is a slide I have shown at the last pipe meeting explaining some of the problems with IPv4 IPv6 PI, showing the differs, asking the room if you want to have this discussed and at this point in time there was no discussion so I thought okay, we're fine with the policies, the differs are understood and accepted. Then on the mailing list a huge discussion exploded with something like 150 or 200 e mails in that thread. So we definitely have the need to do something here.
Before the coffee break Leo has asked why is there a difference between PI and PA in the first place. It it be explained by the traditional split between the ISPs on one side and the end users on the other side which at a certain point in time was easily true. And that sort of had different implications for the way address space was given out. PA space was given to Internet providers who used it to number thousands or millions of customers from that space. These blocks tended to be big. The allocation policies somewhat liberal because ISPs tend to grow and you don't really know where the growth is going to, specially in IPv6 the policy is fairly liberal. And then you have sort of end users that need to do things where they really need globally unique address space that is not tide to one ISP at a time. So we have portable or provider independent address space there.
The rules are different because after long discussions that's what we ended up agreeing. The blocks are smaller because it's meant to just number this person's network. And it was not meant to be a replacement for a PA allocations. If you do ISP like business, so there are strings attached, like if you have PI, you're not supposed to give numbers from there to your customers. And this is causing the most friction these days.
The price was also very different because if you want PA it's assumed that you're an ISP, you're a RIPE member, so basically the PI comes nearly for free but you have to have the RIPE membership which has a price tag attached while PI is a much smaller price. And that leads to business models where people run ISP like things on PI which was not what we envisioned that things would be, and it shows that well, the distinction is somewhat arbitrary and doesn't work anymore, at least that way.
Going back in history to set the stage for the discussion, when we started thinking about IPv6 allocation policies, there was some guide lines from the IETF that said this is how the address architecture looks like, we have a top level aggregator and 13 bits to number the top level aggregator, there's going to be at maximum 8,000 routes in the global table, which is a cool thing. Table growth bounded. There's just a small technicality, the ISPs did not give guidelines, what sort of commercial enterprise is worthy to be a top level aggregator. The ISPs doesn't dictate businesses and there were no rules to decide who gets a top level aggregator and who not. That obviously doesn't work out. So the first official regional registry policy that we had in 1999 said the TLA model isn't working. We followed the established IPv4 model, if you're a member, you're an ISP, if you're ISP you get a block. Doesn't matter if you're big or small you get a block because we cannot decide who's worththy of that anyway. There were 35, the famous ones, that worked but 35 is a bit on the smaller side if the ISP wants to get out 48s, so there was changed to 32s in 2002. And that's pretty much the policy we still have. The focus has been on aggregation all the time. So at this point in time there was no PI at all because the wish was aggregation and ISPs do aggregate lots of customers. We have tuned but the over all concept is there. If you're a RIPE member, local registry you get a big block of addresses and that's PA.
In 2000 six we had a proposal on the table to have provider independent address space in the RIPE region. And that proposal dragged on for nearly three years because well basically two camps. One camp said if there's no PI we're not going to deploy IPv6 and so there's a need for PI. And the other camp said, the routing table will explode, everything will explode, we cannot have PI, PI is so evil. Eventually a compromise was found that people agreed that if you are an end customer of a certain size, you want to do multi homing to two different ISPs, there is no other technical way to do it than to do BGP based multi homing and you need portable addresses for that. So we compromised on a PI policy that says if you multi homed, if you're an end side, so this is not for ISPs as a cheap way. It's for end sides that are multi homed you can get PI and everybody else, we will reconsider later on, if the need arises. So that's why there's so many strings on the PI policy.
Generally speaking in the last 12 years, we started with a policy very strong on aggregation and keeping everything out of the routing table, which didn't really help IPv6 adoption that much. And now the emphasis is more on keep a working compromise that permits people to do IPv6 if they wanted.
Just a short reminder, what we have to keep in mind when doing IP address policy, registration is basically the most important one for v6, knowing where the addresses are. So you can actually verify if somebody is entitled to use these addresses and that requires registration documentation.
Aggregation is nearly as important to make sure the huge amount of numbers we have don't mean the routers will all explode. That's an even more tricky balance, because, well, everybody wants to be independent, of course, but everybody else has to pay the cost, so a compromise needs to be found there.
Then of course there's conservation, people keep saying IPv6 is infinite, which it isn't, so the policy needs to have some sort of eye on not running out in the next 50 years or so.
This is again the things we need to balance in address policy, routing table on one side, NCC founding because to have a proper registration system we have to have money flowing so they can do their job. End user costs, so if we make PI too expensive, people will find creative ways around that, like get a big block of PA and sell off slices of that, well take it and use it anyway you want. This is happening today so it's not something I'm making up. Usefulness of the address space, efficiency of the allocation. And something that's actually important in the whole PI versus PA discussion is good stewardship regarding the amount of addresses end users can get. If we do policies that have a financial insent tiff to give single IPv6 addresses to end users, we're sending a funny signal since we really want end users to receive a whole block. Some numbers I stole from my routing table talk on Tuesday to quell some of the fears regarding routing table growth. This is slots in the routing table, broken down by category.
The solid lines here are allocations to the local registries, PA blocks. And the dotted lines are PI blocks. The registry that has the most liberal PI policy for v6 Ryan now is ARIN. If you qualify for an IPv4 PI you get an IPv6 PI. There was, of course, fear that this might explode the whole routing system. The policy's in place since 2000 six for ARIN, and the table still has not exploded. So we're something like 700 absolutes, and half the number of PA blocks. This is the perspective that I want to set that this is viewing the same numbers from a different angle. This is /32s and /48s in the global table. We've had some power year's experience with PI allocations from very liberal regions and it's still less slots in the table than for the PA allocations, which means that growth is sort of under control and not everyone of the million DSL users is rushing to get a PI space, which is keeping it bounded.
So, again, short recap on why the current PI policies are difficult on people. One is the multi homing requirements, I might not be multi homed today but want to keep the option of being multi homed in three years, so I cannot do PI today, this is a shame. PI as of today is much cheaper than PA and that is an incentive for people to want PI to number their network, even if they run an ISP, which they can't, so they are unhappy. And there's user restrictions on it, so sub assignments people on IPv4 today cannot do on IPv6 so they did i ever implementing IPv6 which is not what we want. We can tune the PI policies to death or go for a more radical approach. And I have discussed this with my co chair. I have discussed this with Jochem from the RIPE NCC financial side. He's discussed it with the board and we think we have an approach that might work. And that's abandon the discussion between PI and PA, have numbers available, so it's no red and green numbers anymore, it's just blue numbers. If you want a number you go to the NCC and get a must be. If you don't want to have a contract with the RIPE NCC because you don't want to do busy with these funny folks you go to your friendly LIR in the neighborhood and ask to get the NCC to provide numbers. If you have the numbers you use the numbers to number things. Of course we still have businesses that are ISP like and need lots of numbers. And we have networks that do not need that many numbers. So the idea was that on the application form you have a check box that says I want to give out certain chunks of numbers to third partys and that would immediately boost the request to a /32. If you don't really need to give out numbers to numbers, excuse me, numbers in large size chunks to third parties, a /48 would be sufficient, so you get a /48. If you sort of like fall don't fall into the categories, you can provide documentation that explains why you need a different sized chunk.
Jochem and Nigel have briefly touched this in the AGM yesterday. They are working on a new charging scheme that actually helps us go forward with this. The charging scheme is not yet done. So I cannot tell you how it's going to look like. But the rough idea is that the entrance fee to become an LIR, the yearly basic fee would be very low. So it's not a real barrier anymore. So anybody who wants to be an LIR can be an LIR for a reasonable entry fee. And then you have sort of like a fee per chunk of numbers that you got. So if you want to have the model that you be a local sponsoring LIR to all your friends you get a larger bill because you have lots of chunks that you handed out. If you just want addresses for yourself, your bill will be smaller. Which is sort of reasonable.
As I said, the charging scheme isn't yet done. There will be a proposal on the mailing lists later this year. The important bit here is that this time we actually checked with the NCC and the NCC board before coming up with funny policy ideas and they are fine with that. So we don't have big resistance here.
So this is actually throwing the proposal at you. Getting feedback from you. We have half an hour of discussion for that. If necessary, we can go a bit longer. We're not going to decide anything right now. We just get feedback and then write it down, make a formal policy proposal. As for the mechanicices of this, we as Working Group chairs are supposed to be neutral and steer the process, but sometimes you actually need one of us to push forward. So we have decided that Sander is going to write this all up and be the formal proposal of the change and I'm going to be the neutral entity that just watches that the process is being followed, validated that consensus has been reached, so we have different heads this time. I see the first two people sanding up at the mike hone. Hans.
SPEAKER: Hans. This is a discussion that I seem to remember back even from my first RIPE meetings, and that's many years back. So thinking through all those years and all those discussions, I'm all in favour of simplification. So if we can make this really simple and don't have different colours of IP addresses I'm in favour of that. The fear I see on the other side is everyone getting their own addresses. Are we trying to create number portability the way phone companies have done it? Because the right mechanism is DNS not numbers. We need to figure out if there's some kind of criteria to get these addresses which is different from I just want some numbers. And I haven't really figured out what that criteria could be yet. That I think is interesting.
CHAIR: I expected that concern and we have been thinking about this for a while, so there's some small hurdles in the way. You have to have a contract with people. You have to be willing to pay the yearly fee for that. Whatever it's going to be, it's not going to be free. So some geeks might want to have this just for vanity reasons, which is fine with me. My sort of reality check is always looking at my parents network at home and I can't for the Hell of it see why my parents would want a portable address at home. They don't know what a PI addresses. They know what IPv6 is because they know it pays my job but they don't want portable addresses because that's not what they need to run their DSL network. What I see is a certain risk that smaller enterprises that might have not used PI yet, might want to get portable numbers. So we will see we will see some shift between formally PA and formally PI, but I don't expect, actually, that the large mass of DSL or cable or mobile customers will apply for this because at the same time their providers will not route it. If I go to Deutsche Telecom and I say I have a 20 euro a month account will you route, they will say, what sort of stuff is that? What are you talking about? If you're billing to pay business ISP to route these numbers for you, there's a hurdle in it. It's a monetary hurdle to pay for the NCC, to pay for business ISP, and going back to the numbers from ARIN that have a very liberal policy, we have not seen demand explode so much. So I think we will not see an explosion here. If I'm wrong, I'm not promising anything.
AUDIENCE SPEAKER: From James Blessing from Limelight asks: Can it be such that you must be an LIR if you're handing addresses to other parties?
CHAIR: Well the answer to that is of course we could do it that way. The question is what's the benefit? I think that's one of the questions that need to be discussed then on the mailing list because going back and forth between Jabber and me is a bit complicated. But we will take that one in mind and have it on the mailing list.
AUDIENCE SPEAKER: I'm not as optimistic as you are. I've seen too much bad network design and bad software design in history. We have in my own company acquired company who made cache register who communicate with the central database, fixed IP address, there's no way of updating the software, we need to keep that IP address for as long as we have that solution out there. That stuff is going to be there if there is the option to make software simpler by forgetting DNS and hard wiring IP addresses and you can do that because you can get your IP addresses directly. So I fear opening up such a mechanism can have a much larger impact on the Internet than we're able to imagine. We're used to making good designs, those that are present in this room and the rest of the world doesn't necessarily share that. They optimise on their own financials which is shortest time to market and shortest hassle if they change providers. It will reduce my own cost and I impose that burden on someone else. I can pay my business ISP to do this but do they have to pay their up streams and other providers? There is no such mechanism today and the pain is on somebody else. This is bringing back to the NANOG discussion before there were provider independent space in the ARIN region and the other way to do this is to set up a separate entity that would provide this service. An LIR could provide this and you could guarantee with a contract as well because you would have to make arrangement with the other ISPs and you would have to provide tunnels as the last resort. I know Axel thinks I've been talking too much. I'll leave it at that.
CHAIR: To directly reply to that, these customers wanting to do exactly this can do so today. We have a PI policy in place that permits them to do exactly that, get a PI space, put their own server on it and have the ISPs routed. What I think what we're going to see as a matter of scale so we will see enterprises going for PI but the number of enterprises is sort of like manageable. We will not see the great mass of DSL and capable users with millions of them go for PI and that I'm pretty sure of. How many percent will go for PI I cannot say. Financially the incentive is not to go because there's a yearly recurring fee here.
I think Ruediger is next.
AUDIENCE SPEAKER: Ruediger Volk: I would warn, I do not think that the ARIN statistics or any statistics about IPv6 that have been collected so far allow any useful prediction about what's happening when IPv6 is actually taken up. And for the PI well, okay, my suspicion is, well, okay, it depends on whoever some consultants get the experience that, well, okay, if they tell their particular client, well, okay, all lawyers, you must go PI, that is the way to do a lawyer's office, you get band and none linear effect. And I don't I don't know, I don't know any good criteria to protect there. And, well, okay, doing business an teen, criteria, protects in some way but doesn't look very reasonable.
CHAIR: I should point out again that we have PI today. This is not about introducing PI, it's actually getting rid of the weird strings attached to numbers. I give it over to Sander to steer the discussion because I've been losing track and he's good at keeping track of things.
SANDER STEFFANN: One point I want to make. We already have PI and everybody in this room knows how to run a network. So.
(Laughter.)
SANDER STEFFANN: Is involved with running networks. Sorry. Like I said, it's this will not be interesting for a vast majority because they do not run a network, they don't have knowledge, they don't have the time to do that. Keep in mind that we're talking about organisations that actually consciously run a network and want addresses for that. It's not going to be everybody. And I hope it's not going to be every little firm out there. I can't imagine it being that. Please keep that in mind. We're already talking about something that exists and actually we just want to make it clearer and easier.
AUDIENCE SPEAKER: I am fully supporting any proposal that makes life less complicated. Yes, I think this is going in the right direction. I want to just put a reminder that whatever comes out of this discussion as the new policy for managing the IPv6 space, don't lose track of the fact that if you make it simpler for a wider audience to get numbers because they need them, make sure that the policy makes it very clear that whoever you are and whatever you do with your numbers, your numbers must be entered in the registry and that information must be kept up to date. We have seen triggered by the introduction of certificates in the IPv4 area, that historically have not only two flavors or callers of addresses but more and we now see that it's very fine to introduce certificates, it is relatively easy for the part of the address space that has been handled by the RIPE NCC. It is extremely difficult to find workable model, for instance the IPv4 legacy space and for the PI space. So whatever comes out of this discussion, keep the registry requirements absolutely clear, otherwise we solve one problem and create another one.
SANDER STEFFANN: Thank you.
AUDIENCE SPEAKER: I like the idea of simplifying the system and I really like the idea of making sure there's a financial burden on whoever's announcing a prefix rather than just a financial burden on the rest of the world. The only thing that worries me is what happens if this gets too popular, the RIPE NCC cannot sit on a mountain of cache. If there's a simple system where mass audiences can get a bit of PI space and a few ISPs say yeah, we can do this, then you need to increase the price of doing this, so that less people want to do it but then you also end up sitting on more cache or reduce the price until everyone can do it and then you find it's very very popular if it's too easy to do so.
SANDER STEFFANN: I think the NCC will take this into account when designing the charging scheme. I think Ruediger was first.
AUDIENCE SPEAKER: Randy bush, eternal loyal opposition. I have never understood this PI PA crap. And I actually have tried. So getting rid of it is fine with me. The RPKI stuff is completely neutral on this and the fact that you have problems deciding about legacy and PI space, rob is purely a pipe layer 9 issue and no technology is going to solve that. But I actually came to the mike to respond to Ruediger to predict the routing table based on what we have on IPv6 I agree is foolish. To predict it based on IPv4 is not unreasonable. And I would point to a paper that I and a bunch of godless communist Europeans published sometime in the last couple years. I can dig it up for you if you want. We actually analyzed the difference between fragmentation IE increase of the routing table due to multi homing and traffic engineering or security or whatever people chop their 16s into 24s for some arbitrary reasons. And in fact the latter has staid dead flat as a percentage of the address space for the last 13 years. Multi homing is going up. But people fragging out is not, as a percentage of the address space. So I think worrying too much about how our policy is going to infect that kind of fragging may be less productive than we think it maybe.
CHAIR: So you think actually agreeing with me, I think. This is confusing.
AUDIENCE SPEAKER: I was agreeing with you on the policy, yes.
CHAIR: Thank you.
AUDIENCE SPEAKER: As I said, I started with I've never understood and by never I mean, what is it, 20 years or something.
AUDIENCE SPEAKER: This time with my hat as treasurer of the RIPE NCC. I would like to remind this room that contrary to one of the previous speakers, RIPE NCC is a not for profit and tries to run a balance budget. If we have 50,000 members, the membership fee is negligent I believe, then that's what it is.
SANDER STEFFANN: Sorry, what you are saying is actually the address space could become very cheap if that happens.
AUDIENCE SPEAKER: If the entire world wants to become a member of the RIPE NCC then the entire world becomes a member of the RIPE NCC and we still have to run a balanced budget.
AUDIENCE SPEAKER: I think you should make it as simple as possible to get IPv6 space to companies because then they get it if they need it for critical infrastructure for their critical infrastructure. Many companies today out source their complete IT, they get IP numbers from someone else. If you get this space and do BGP you have to have persons who run BGP routers and this is more costly than anything charged by the NCC this is the real cost. I don't feel the explosion because companies don't want to pay personal consultants for this. This is too expense sieve if they don't need this space very very badly.
CHAIR: Can I just have this slide back, please. Regarding numbers, this is why I asked Alex to give us some background. These are the IPv4 numbers. So there's about the same number of PA and PI that has been handed out by the RIPE NCC. So that's the number of PA slots or blocks giving out given out by the NCC and that's the number of PI prefixes and that's the number showing up in the routing table. So PI is behaving much better than PA. And this is v4, so we have had some 50 years of time to make mistakes, have the routing table explode and so on. I've always been a skeptic about PI and tried to put hurdles in the way and people go for it nevertheless. But still the numbers don't give an indication that being somewhat liberal here is going to have everything explode. Please back to the other ones.
AUDIENCE SPEAKER: Benedikt Stockebrand, freelance IPv6 guy. The actual problem that the I space from a technical point of view is the explosion of the routing tables in the default zone. What will happen if we have millions of people who need highly reliable Internet access because that's what people care about. I need PI addresses, I need somebody to run BGPAS which for some people is quite a problem as was pointed out. I suspect if there is a significant coast for the routing table problem and there is, eventually people will have to pay for that. It's not alone a matter of the RIPE NCC membership fees, but of the cost that generally occurs. I mean the Internet is like a box and some corners you put money in and some sides it goes out. If you drain more money out than you put in, eventually it will be empty and there will be a suction effect and people will behave for sensibly eventually. That's one point.
The other one is it is possible to provide people highly provide independent Internet access PI addresses without their own BGPAS. That is possible. It's a radically different approach but it can be done and it will put more work load on the providers, on the LIRs, which for smaller customers is a good thing because you put work on the people who know about BGP. Doesn't work for the big enterprises but then there's not that many of them that there are a problem, routing tables. Maybe next meeting I might give a talk on how this can be done. Maybe some people realise that might be a business opportunity somehow. Thank you.
SANDER STEFFANN: Hans is next.
AUDIENCE SPEAKER: I just had a question to the figures that you showed up there, if you could bring it back. What's the meaning behind this? Because it seems that it's 3.8 times number of routes for the first category and 1.1 for the last category. Is it more multi homing in the first category or more fragmentation or is it both?
CHAIR: Yes. We don't actually know. On average for a single block of PA space 3.8 routes show up, but we don't
AUDIENCE SPEAKER: The answer to the question should be there, because either you count the address block showing up on different parts in the
CHAIR: We haven't investigated.
AUDIENCE SPEAKER: That would be interesting to know
CHAIR: This is just counting. This number of PA slots goes to that number of routes. We don't know whether it's it could be five of them completely misbehaving and announcing slash tens as 34s. That level of investigate we did here doesn't show. Experience is it's a mix of people multi homing and deaggregation for whatever reasons, traffic engineering, fear of hijacks stuff, it's just the numbers that same amount of allocations, many more routes.
SANDER STEFFANN: I think Randy has some numbers.
AUDIENCE SPEAKER: I wasn't going to read the numbers but give you a pointer, J sack last October evolution of deaggregation space, myths and reality. Pierre Francois, he was a co author. It's got the numbers and the pictures.
SANDER STEFFANN: Okay. I've seen a lot of the regular people standing up at the microphone. I'm curious about the opinion in the room. So yes I'm going to ask for a show of hands. Basically on the basic idea, on one side we have the idea abandon the discussion between PA and PI and make policy for numbers. On the other hand, we have keep the distinction because people feel it's an important distinction and serves some purpose. So I'd like a show of hands on the first one. Who thinks this distinction is no longer important and we should just talk about numbers and no longer PA or PI? Thank you. And who thinks the discussion between PA and PI is useful and we should keep it? Okay. Thank you.
CHAIR: Show looking from here, it certainly looks like we have about five times more people that actually want us to go forward and bring this as a formal proposal to the list and we'll sort out the wrinkles on the mailing list. But it gives us the backing to go forward with this and spend some thoughts. Thank you for that. And, actually, thanks for being quick with the discussion. We're five minutes ahead of schedule.
SANDER STEFFANN: We have one more.
AUDIENCE SPEAKER: Just one comment. I don't have any strong opinion whether for or against and I didn't take part in the vote, yet I think it's extremely important to educate people who will read these proposals or any evolution of it, and not only on the RIPE mailing list. For instance, I know that the last implemented PI policy, this was in 2009, I know that there are too many operators that don't know even that exists. And I'm not blaming RIPE for not communicating. But I think that the effort to make people understand what is it at stake for them is also all the community which should communicate and be aware. Otherwise, people will keep confused. And I know many stakeholders which are concerned with that, are confused because they don't understand what is sort of getting through a sponsor LIR or getting directly and it's not only the cost of it and also the technical aspects and the administrative. So you should really be very careful about how the communication with this will go to the community.
SANDER STEFFANN: Thank you.
CHAIR: I actually would like to put that action item on Emilio and the NCC. You're doing a good job with the outreach already. If somebody is not listening it's a bit hard. I know you're on that anyway. Tell people what's going on.
AUDIENCE SPEAKER: I have a question or comment from James Blessing remotely. He says that the question is more complicated than that. He says it's good if the policy for getting addresses makes sense.
CHAIR: I should point out that we didn't vote. It's really more tell us the way we should be working on that and not a vote for something, as we don't vote here.
SANDER STEFFANN: Please.
AUDIENCE SPEAKER: Will just numbers help the customer understand that he may have routing problems in the future?
SANDER STEFFANN: You assume he will have routing problems in the future with this?
AUDIENCE SPEAKER: Who knows.
SANDER STEFFANN: Well, basically, we try to keep some routing things in mind. We talk about routing table size. But routability is not something we can decide on. So I don't know how to actually respond to this.
CHAIR: What we see today is people that cannot get PI easily because of the policies are somewhat convoluted, go for a PA block, chop it up and sell it in small bits and pieces. I think that's going to be more problematic for routing because you see more specific and you cannot know if this is more specific with an aggregate or PI like things. This might actually make it easier to look at a route and check the registry and see whether this has been given out or whether it's more specific and help build reasonable
AUDIENCE SPEAKER: What I was actually referring to is in v4 PI you're warned you may have problems routing this somewhere in the world. I don't see the difference in v6 if you have small blocks and the routing table will grow, that at a certain point there will be filtering and there will be routing problems. And you just sell numbers, will the customer be aware that he's having a block which may have problems in the future? That's what I actually meant.
CHAIR: So the wish is to put a warning sticker on the form that says, I have considered using address space from my provider, and I think this is going to work for me?
AUDIENCE SPEAKER: Fine.
CHAIR: Okay.
SANDER STEFFANN: I think we're perfectly on time.
CHAIR: We're so perfectly on time. Schedule time was to 12. It's two minutes to.
Here we go. This is sort of a bit more long term approach because we don't have it formal in the machinery yet and we have a short term proposal to change the rules for the existing PI on the table today. Eric brought it up and he's going to explain to you what it's about and then we'll get some feedback from the room.
Eric Bais: Eric Bais. I'm one with a green dot on my badge here. Doesn't mean I'm new but my company is, that's what the green dot stands for, I've been told. This is actually one of this is my first policy that I present and one of the things as a LIR, you know, we all have to work with the current policies in place. One of the things that I found interesting and hard to explain to my customers is why is there a difference between IPv4, IPv6, and specifically for getting PI and is it actually in the best interest for the customer that that are additional requirements? Specifically the multi homing requirement.
So the policy as it stands currently is open for discussion. And the end phase for that is 13 of May and it has an impact on 512.
So in short, the policy proposal stating removal of multi homing requirement for IPv6 PI. And it's actually pretty simple. As you see the current policy text, there are two requirements that are stated in here, demonstrate that it will be multi homed and the second one is meet the requirements for the policies described in the NCC document entitled, with the URL there. This is basically what the whole policy says, removal of the point 8. And the reason for that is something I'll go further on in the presentation, but this is basically it does not change anything else, you know. It's not about getting your customers, as a hoster start with this, it's purely for making it easier for end customers that do not require or do not see themselves as an ISP, that do not have the requirement to allocate space to another entity or for strategic reasons do not want to become a LIR, that's where, you know, the thinking came from for this policy change.
So the reason for if you look at the current policies and what's already in place, there is a difference between there's currently discrimination, if you call it like that, because if you have enough money, you can basically say I'll become a LIR and I do not have the requirements. And if you are an end customer or you don't want to become a LIR, then suddenly you need to do multi homing and there are all kind of restrictions. But basically there is no there's no difference in between. I've actually seen customers that said, screw this, I'll become a LIR, pay the fee, that's it. I don't like to have all the questions done or those kind of things. And there are plenty of LIRs that are not multi homed, that are basically saying we want to have our own IP space and please ISP, can you do the routing for me. Which is basically the same as what another customer would like to do as an end side.
So in the thinking about where does this come from? Obviously we've heard about and most of you probably know about the background better than I do, so I've made some assumptions here, limiting IPv6 for PI with multi homing as an additional requirement was probably about the fear of the explosion. And this is where the discrimination comes in place, as I call it, if you actually become or pay the membership fee for a LIR we as a community have decided we don't care about the DFZ anymore. If that's the case and we'd like to have the same, you know, level plague field for, you know, the requirements on one side and it's not a technical discussion. It's basically already a financial question. So there are plenty of reasons why a company actually don't want to sign up as a LIR, it's either strategic reasons, they don't require the allocation address, to allocate addresses to other entities, they don't see themselves as an ISP. I have a couple customers actually by self for that specific reason their own IP space, they don't want my IP space, and at the same time for each and every entity they work with, they actually request new PI space because they say, well, there are dedicated environments for those customers, they're large enough, and I'm not going to provide IP space to my actual end customers or additional end customers. But these companies, they still require IP space, even if they don't require or don't have the knowledge to actually do multi homing.
And this is actually where the other part comes in play. Multi homing, BGP is not for the faint hearteded. It's not cheap. So doing this as an additional hurdle for companies that actually say, well, I got my routers anyway for IPv4, you know, I got an AS number anyway, so I've already used to that, but you need expensive equipment, you need multiple transit, you need to have engineers or consultants who have an understanding of what is IPv6, who is BGP, how does this work and even still BGP mistakes are quite common and mistakes are happening, even still.
So I think that the current PI IPv6 multi homing requirement is not helping the actual number of IPv6 deployments. I've had this question from customers multiple times, can I have v6 PI and basically the answer was, well, are you going to plan for multi homing? And whenever the question came back and said no, I'm not, this is not my thing, then I had to sell them sorry, either you become an LIR or you need to do BGP, you need to start multi homing, and they said, well, I don't want to do that and for all the reasons I stated already, they fit perfectly within the other requirements, but the multi homing is just limiting them for actually deploying IPv6.
So, in order to get your feedback on this, it's actually important to get your feedback before 13th May on the address mailing list and even if it's as simple as I support the policy, and if not, let me know. So it's important that we get your feedback. Not only here in the room, but also on the mailing list.
Any questions?
SANDER STEFFANN: I see Ruediger standing up.
AUDIENCE SPEAKER: Rudiger Volk: Sorry, I can't keep my mouth shut. Well, okay, the multi homing requirement is essentially the one technical thing, really valid reason, for saying, well, okay, if you need to multi homing, you will be more or less forced to take up an additional routing slot in the global system. If you don't, you can aggregate into your upstream provider. Whatever the cost and requirements for, well, okay, being able to renumber or not, comes into the picture, is kind of not really the basic argument. Your complaint that, well, okay, actually paying the fees as an LIR ask a cheap way to work around that criterium, yes, okay, that's a cheap way. And, well, okay, it's quite obviously would be a really bad idea to raise the barriers for people to become LIRs if they choose to pay that money. I'm not really happy about that money flow. But, well, okay, the technical background is actually fairly strong in this part.
SPEAKER: You've probably seen that on the address list, mailing list discussion as well, there is currently a lot of discussion going on on the cost of PI, actually in the first draft of the policy that we discussed, I was actually stating, well, I'm from the stand point where I think that PI in itself is too cheap, and that it has to go more into a price range, but, you know, that is separate from the discussion here that's on the table. Looking at looking at that, the change from basically getting the technical requirement out and introducing a financial requirement you know, a hurdle, is basically not something you can do someone a single policy.
AUDIENCE SPEAKER: Well, okay, when you say cost of PI, I assume you're talking about charging handing out numbers, you're not talking about the cost of the technical system?
SPEAKER: Exactly.
SANDER STEFFANN: Any more questions?
AUDIENCE SPEAKER: Job Snijders from InTouch. It is nowhere really specified in the Address Policy that it has to be BGP multi homing, so if we have LISP, it's very nich to take it it from place to place and reuse it. What we currently do is cheat. We have have multi op EBGP sessions into the DF set. We make sure it thinks that but it's proxy routers catching the traffic and forwarding it to the real place. I would very much like if we get rid of this limiting requirement.
SPEAKER: Yes.
AUDIENCE SPEAKER: Yet again I don't have any strong opinion against or for this, but isn't it a little bit related with the previous topic? And if the previous topic is going forward, isn't it will it be obsolete as soon as the other gets out?
SPEAKER: Hopefully, yes. However, that change and the previous topic is not something that's going to be is my expectation, not going to happen within the next year or so. That is the long term.
AUDIENCE SPEAKER: Do you think it's real, that you need to get through this anyway, anyhow, the previous topic will go forward? Is there enough energy to get that?
SPEAKER: It's an intermediary solution, basically, to get to the same requirements for both.
AUDIENCE SPEAKER: Actually, I don't want to make much comment. I support it. I would like to see if this audience could show an indication how much the support of this policy change would be.
SANDER STEFFANN: This is a request for a show of hands? Well, okay. Who is in favour of removing the multi homing requirement for PI space, please show your hand. Thank you. And who is against this change? Seems to me a bit like 50:50, so no strong majority either in favour or against. So I guess we have to keep discussing this. Ruediger is at the microphone.
AUDIENCE SPEAKER: Well, yes, actually I would like to add a little bit of comment to Job's remarks on LISP. Actually, I would be extremely happy to see the price of PI lowered to zero or extremely closely, and no multi homing requirements for PI space that is marked. It will never show up as a separate route in the routing table, like the things Job was talking about.
SANDER STEFFANN: Actually, we have talked about that at some earlier RIPE meeting. At that point the opinion was if people pay enough money, the filters will be removed and it will show up in the routing table. But if the current feeling is we can do this, I think we should be open for a policy proposal on that.
AUDIENCE SPEAKER: Can I respond to that? More specifics not showing up in the DFZ, I think that's doable if we have a big aggregate, but not showing up will create a separate Internet and I'm not in favour of that. Maybe there's something we can reserve in that area. We don't have to make it free. 50 euros is good. What's a routing slot worth?
SANDER STEFFANN: I'm looking forward to any future input on that. Back to this discussion. Anymore questions? Anymore comments? Then we're exactly on time to move on to the next subject. I would like to thank you for your presentation.
(Applause.))
DAVE WILSON: I guess I'll introduce myself since I stole the microphone. I'm Dave Wilson. I work for HEAnet and we've been talking in our company, as I imagine many of you have, about what happens when we see a reasonable amount of traffic of our customers looking to transfer address space, to or from, one way or another, and while discussing that, we realised we think we're missing a document, maybe someone should write that. So what we're going for is this: At the moment when we get addresses, the more than likely fresh addresses from the free pool, not always, not necessarily, but the likelihood of getting addresses that someone has previously used is pretty low and soon that will flip and that will be pretty high, if you can get them at all. This probably has quite a lot of not really obvious problems. It's not something we've done on an industry scale before. And I think that there might be a lot of benefit of trying to write these problems down. Now, I want to be very very clear about what we have in mind here or what our thinking is. There already exists some documents that I think we do not need to mess with or maybe people want changes but I'm not looking to changing them. There is a policy for transferring policies, I don't want to touch that. That's a separate discussion in my opinion. There are also procedures that the RIPE NCC uses and Athina was talking about then yesterday, and that's what they use in order to arrange transfer according to the policy. Again, I don't want to change those. That's a separate discussion again.
There is, I think, a third category of things which are things that a prudent person should do when attempting to change hands for a block of addresses. I see them as guide lines. And right now I think we're not really clear on what those are. Now, I'm going to really lay this on. Such guidelines I think, must be descriptive, not prescriptive. This is not something which is binding. If it's binding that's a policy and that's a separate discussion and I don't think we need to go there. That document already exists and therefore it must not contain the word must, whatever this document is. I see along the lines of best current practice and maybe that's what we'll call it if it goes to completion.
I think as an industry we should be trying to enumerate the things that may cause problems down this road and I think we already have some ideas on the problems you might run into trying to recycle the space, but the reason I think we should try to keep this independent of policy if we decide to do this is because it will describe the things that will happen if you follow policy and the risks you take if you don't. There are certain things I think which are going to be outside our control. I assume at some point I'll have customers coming to me and asking about transferring space and I'll have to have a conversation about what the policy is and there will be times that they may want to do something that's within policy and maybe sometimes outside of policy and I need some support to explain what the consequences of that are. And there are probably going to be times that they want to do something that is not covered by policy. And I would really like to have some support for that discussion as well.
So what we have at the moment in mind is to separate this into four or five different sections and this is only our first draft of how to divide it up. I'm not laying a bunch of text on people today. I think it's too early to do that today. I think we might get the picture out and some clarification out on the shape of the document that needs to be exist or we think needs to exist, give an idea of the different categories of problem, couple of examples and see what the feedback is. At that point we'll try and write a proper first draft. One of the things and I think this is the most obvious one, the kind of problems people run into when they have a block of addresses or a fragment of a block of addresses and try to route it. I'm actually not sure yet, for example, what the feeling of the community is if someone has a block, tries to split it up and transfer part ever it to someone else. I don't know yet what we want to do with that. Again, I say this isn't about saying you may not fragment. If you want to have that discussion I'm delighted but that's for the routing Working Group and there's a document for that. I have in mind things like why it is important and this is crucial why it's important to document any changes in the routing registry. And then, indeed, if you want to write if that's according to policy, what the risks are there. And the risks of running into bog on filters, if one manages to get a strange piece of space from somewhere. There are a bunch of security considerations and I'm not sure to to begin writing this but I'm sure it needs to exist. Some examples here are the organization that is transferring addresses away probably wants to ensure themselves that they have fully vacated the space. And that's more than just ceasing to announce. That's things like changing firewalls rules, changing access list, notifying third parties who are allowing space which you may or may not pay for, and the acquiring organisations, well they themselves probably want some guidelines on how to verify the space they're getting is is ready for them. Perhaps we need to have some guidelines on what to expect about space occurring on spam blacklists, and what to do on that occasion. Maybe it's something we should leave aside but I'm sure a customer will come to me, I've got this space, it's on all these blacklists, what do I do? If my answer is you should have done something before now, I want to make sure we have that written down somewhere in advance.
And in some way relating to this sorry, I say it's not necessarily about or it's not explicitly about telling people what to do but where there are policy in place and where none compliance with those policies could result in revocation by the regional registry, we should note that as a risk in exactly this sort of document.
A bit on what I call and I don't know what the best wording to use is but reliability of the transfer itself. Once two people have agreed and shake hands they want to do this, how can they satisfy themselves that this is actually going to work? The analogy I use, once you've paid your money for your mars bar, are you sure you're going to get a mars bar? Among other things, I suspect that some people who will be getting their hands on address space, will be some people who have not had networking experience before because they came late to this. It might not be immediately clear to them what they need to do to ensure their upstream IP of their choice will actually route those addresses. This is also we might want to ensure that we cover that fragmentation of addresses, that it's properly reflected in the registration database.
And then there's a bunch of considerations for other people because other people will always be affected by these transfers. Going back to the blacklists, one good one is should we make sure to provide an efficient mechanism or does one already exist, to notify people who are maintaining something like a spam blacklist that the holder of these addresses is now honestly and totally different? And perhaps provide some reasonable way for the blacklist operators to verify that so they can forgive the signs of the addresses based on the previous holder.
And I think in particular, as an upstream I'm going to need some guidance on how to satisfy myself that a particular address block that someone has received is valid or not. And best of all, I would really, really like and if I get nothing else out of this discussion, this alone would please me, I'd really like to be able to describe to my customers why the database is important. Yes, I can give a very good argument but what I have today is my opinions and feeling feelings and experience, what I don't have is a clear statement of the will and reasoning of the community on that. So I know the integrity of the database is crucial but I think there will be a bit of difference between me saying in my opinion, if we do not keep the database up to date there may be some problems down the road versus the community saying here are some clear problems and risks that the community will encounter and that you personally will encounter if you fail to keep the registration database up to date.
So that's where we sit. We are looking for feedback at this moment on whether this document should exist and how to draw it up. I'll suggest but not require three questions for discussion, if I may. The first being: Is there room for this document, one that talks about the general risks and ways to mitigate those risks of dealing with addresses that you are handing or taking from someone? Should we be doing this at all?
The second is: How and this is very subtle and very interesting, how do we make sure we don't accidentally and unintentionally create responsibilities or liabilities? If I have a document, for example, that and this is pure example, that says the people acquiring the address space should check if it's on spam blacklist, have I then that no one has a responsibility to do that except the person receiving? So a statement like that can have effects that we may not intend. I don't mind if the community says, that is the correct way to behave and we agree on that but I don't want to walk into that accidentally.
The third is on the categories, are they the right kind of categories? Are we missing some and how far into the details or what kind of details should we bring up? That's what I have. I would be delighted to hear any feedback. Thank you.
AUDIENCE SPEAKER: A comment from Jabber.
AUDIENCE SPEAKER: Question on from James Blessing at Limelight Networks. He says any documentation that can include guide line on dual location and blacklists fixed are good and should be explored.
GERT DORING: I see Rob coming up to the microphone, that should answer the first question.
AUDIENCE SPEAKER: I think I fully support this initiative. I think we have a transfer policy in place and a document that explains all the technicalities you should keep in mind and look at when you do a transfer, it's hardly welcomed.
Secondly you had another question about creating liabilities and responsibilities. I think once you are nearly finished with the draft text, you could ask the RIPE NCC legal department to have a look through that and looking for potential pitfalls there.
DAVE WILSON: Thank you.
AUDIENCE SPEAKER: Todd Underwood, Google. Two things. One is I think all of the RIRs if they intend to survive in I a post v4 runout world will have to be like resource title agents where they provide clear title of the history of the ownership of any particular numbered resource, who has had it, how long they had it, anyone purchasing it or transferring it can be aware of it. It seems like a solid move in that direction. Has any work been done in boot strapping the RPI work in doing this? It seems straight forward, take a text form of the RPKI, it's designed to be read by routers, but it could also be read by humans so I take a resource, I sign that resource and the signature has the entire chain of authenticity of the signatures all the way back and I post that on eBay or whatever I'd like to post it and you look at that and able to validate the signature, and you send me an intent to purchase which I can sign with the signature that has the signature validations which means I'm me and can sign other things and we execute the purchase by me signing the new allocation, at which point RIPE NCC can validate that and sign the new person, so it gets rid of this need for synchronization and careful coordination between the buyer and seller
DAVE WILSON: I hear what you're saying. One clear for a paragraph is if you follow the policies and keep the registration database up to date you may have the benefit of RPKI current state. And I can also see that that could be prop matic in other ways. It is an area I want to concentrate on. I'm almost afraid to give an opinion or at least the opinion I have now might change tomorrow. So I I am and I think I speak for the other clearly we're open to this and we do need to discuss it in detail in time. Thank you. I can't see anyone.
AUDIENCE SPEAKER: Geoff Huston in response to Todd's comments. Certainly it's's pretty clear that there's a potential to use digital signatures and certification with the RPKI to allow parties to a potential transaction to understand the bona fides of each other, otherwise the addresses are just numbers. So there is some potential roll role. However this community in terms of offering guidance to their local RIR, should consider careful what roles they would like to see an RIR participate in in terms of such a market for these numbers. There are roles such as facilitators, there are roles that are more passive and are merely title. To what extent you want the RIPE NCC in this region's case to be a participant and to what extent you merely want it to under pin transactions that are created and formulated in other environments is something you need to careful consider as a community and give the RIR some very clear guidelines as to what their role should be. And that does include things like the RPKI on the assumption that the community allows and wants the RPKI to accurately mirror the contents of the authority I have database that the RIR holds that subscribes the association between people and resources that they hold. If the RPKI varies, then consideration loses relevance in terms of reflecting what's in the database. But the key message I really wanted to say here, the RIR could be many things in such an environment going all the way through to contacting blacklist holders and telling them stuff, through to a relatively passive and neutral title office. Exactly what you would like it to do, and the opportunities, benefits and liabilities of various roles is something you need to consider as a community.
SANDER STEFFANN: I just want to make one comment. Dave explicitly said he didn't want to change policies. If we start discussions about what we want the RIPE NCC to do we should do that in a separate discussion about a policy proposal and not here. Thank you for your input.
AUDIENCE SPEAKER: Nigel Titley wearing various hats, in this case as co author of the transfer policy. The transfer policy in the RIPE region already requires transfer blocks to be signed. That is a requirement, not optional, okay. So we already have that.
GERT DORING: Okay. We're already five minutes into lunch. But I think it was a good use of our time. From what I seem to be hearing from the room is one more comment.
AUDIENCE SPEAKER: Hello. I'm not very sure if it's proper to ask that but most our business are IT intensive so we use lot of IP addresses. We are wondering if the transfer, the market for transferring IP addresses are really happening which means the cost and will rise after this year basically so we're worried that might affect our business because our cost of IP address will be raised really when we need approach new customers. We're wondering why people need: Rather than transferring in the market, it's just a lot of costs for us, so why we make this a market place rather than as based on need.
GERT DORING: Well basically this is somewhat out of scope of this document. If your sufferability on the market depends on the availability of IPv4 addresses I think I have bad news for you. So yes, IPv4 addresses are going to be expensive and they're going to be more expensive by year till a certain point that they lose their value because nobody is using that anymore. This is really out of scope of this document. This document is not about pricing market, it just explains if you want transfers, however the transfer got ranged, please be aware of the pitfalls. I need to wrap up at this point because we're really into lunch break. So we'll good to have these discussions can, of course, be done off line with us on the mailing list. I welcome all comments on the mailing list. Thank you for being here. Thank you for giving this your considerations and your time. There will be more Address Policy tomorrow morning at 9:00 and I fully expect you not all to be there but I'm happy about everybody who does show up.
(Applause.)
And thanks to the stenographers and thanks to the scribe to actually keep up with us.
LIVE CAPTION BY:
ANNA PAPA MURPHY, RPR
DOYLE COURT REPORTERS LTD,
DUBLIN, IRELAND.
WWW.DCR.IE
63