These are unedited transcripts and may contain errors.
Address Policy Working Group,
3rd November, 2011, at 9 a.m.
GERT DÖRING: Good morning, Working Group. Looking into the room I am not exactly sure whether DNS is so much more exciting at nine o'clock in the morning or whether the party was so great yesterday evening. I am still happy to see a number of faces here, so I hope you are the ones that are really interested in policy deployment and not here because of the great Wi?Fi.
The agenda for today is pretty much a single big item, trying to discuss the idea about PA/PI unification, and, sort of, if we go there, what would the mechanics be. And then there is the Open Policy Hour where anything that sort of, like, might interest the group about policy, is welcome. We have something from Kurtis here about a new RFC from the IETF which might have some impact here, but more on that later on. If there is anything you want to bring up, Open Policy Hour is the place to go.
And then I start with PA/PI. A reminder that all of you have seen before, this discussion is webcast. You can participate remotely. If you want to say something, please speak into the microphone so that remote participants can hear you and please speak your name so that it can be properly attributed and people know who is talking. But you all know that.
So...
This will be a bit presentation and then I hope a longer bit, more interesting bit, actually, discussion. But I think it's useful to sort of summarise where we are and present the ideas before entering the discussion. So, I'll start with the summary.
There has been lots of of discussion on IPv4 PI, IPv6 PI, differences between IPv4 PI rules, IPv6 PI rules, and I am not going to do anything about IPv4 PI, because, well, what's IPv4? That's sort of, like, over.
But, people still tell me that the IPv6 PI policy is giving them problems, and so maybe we can clean up something there.
As a wrap?up why there is a difference in the first place, if it's just addresses anyway. When this distinction came up, there was a pretty clear difference between participants on the Internet. You had Internet providers, which had the whole business centred around connecting end users to the Internet. And they would get an aggregatable parks network block, aggregating thousands or millions of customers so, the idea was they get a big block with not so many questions asked because they will provide connectivity to lots of people, so they need lots of addresses. Then we have PI for people that well want to be independent of all the ISPs around them, sometimes for very good reasons, sometimes for vanity reasons, but anyway, for reasons. And traditionally, these were sort of independent end users and they run their own network and nothing else, and needs are sort of smaller thing. And the sides difference influences policy difference, inferences a strictness of evaluation, minimum assignment sizes and all this. Which seemed to have made sense at the time, but since then, we moved to IPv6 and, well, the actual structure of, is somebody clearly an ISP or clearly an end user or something in between has been muddied, so the world has become more complex and so maybe our simple black and white policies don't really match that any more.
Some words about the IPv6 policy history here in RIPE land. This is all old news, but I still think it's useful to have to see on what time scales we are discussing, because I had the comment yesterday: We are changing this again and again and again so how should people know what to expect? Can we not have some stability on that? We are basically doing this on a ten year scale, so I don't think we are changing things too often.
The initial idea that the IETF had was very, very strong aggregation, at the maximum 8,000 ISPs in the world, 8,000 top level aggregators and everybody else would have to use space from these top level aggregators, and then people figured out that the IETF had no guidelines on who is big enough to have a TLA and who is not big enough to be a TLA and that the IETF had no business in influencing business decisions for, well, companies, so that idea was abandoned.
The registries then had the initial v6 allocation policy in 1998, I think, or 1999, it says here, where everybody could get a /35, every LIR, which was then later extended to a 32 in 2002, so that's nine years ago, and in the discussion on whether we want to extend that to a /29, that was nine years. We have learned from then. So, I don't think we are doing too frequent revisits to the policies.
We have adjusted a few things in the parks allocation policy but nothing really serious. A little tweaking on the HD ratio. There was something in the policy about you have to aggregate it as ?? you have to announce it as an aggregate, and we removed that to give more flexibility to the routing Working Group to actually come up with recommendations on aggregation, which they did.
In the beginning, there was no PI. The PI proposal was introduced in 2006 and initially, the reaction was, well, if we have PI, the world will end. We had PI for five years now and the world has not yet ended. But due to the initial resistance on PI, the criteria have been pretty strict. Like, you have to be multihomed and you are not supposed to use that for anything else but your own network. And this is causing problems for people that have sort of like not such a very clear distinction between my network and my customer machines, like virtual hosting providers and stuff. So there is friction here.
Some background on the numbers, because in all these discussions, we have lots of emotions in it and not so much actual data to back the emotions and I want to share what I have. This is the allocations and assignments done by the five regional registries over the last five years. You have solid lines, solid lines is allocations to local Internet registry, so that's the provider aggregatable block. Even if some of the registries call it differently, but that's the provider allocations. And then you have the dotted lines down there, that's the provider independent assignments. So, even if some of the other registries have far for liberal PI policies than we have, like ARIN, it's still not like there has been a huge explosion and there is ten times more PI out there than PA. So, looking at this for over a five?year period, I think we can sort of like be a little bit more little relevant about things, because it's not going to end right away. Of of course we have to monitor this.
Looking at the routing table, what we have today broken up by size. We can see that we have about 3,700, 32s, which is the ISP prefixes and interesting enough, 2,500 48s, that's a high number because there are so many PI assignments at all. About half of that is more specifics from the local registries. Then there is the green?ish line, with about 1,000 prefixes in the range 33 to 47, which is mostly also more specifics. There is a few PI assignments of bigger than 48, but they usually show up at 48s, these are more specifics, which is quite a big sum. I have not yet completely looked into this, where it's coming from, whether it's individual networks leaking 500 prefixes at a time, but it's fairly consistent so it's not just temporary leaks.
Then I have looked at the numbers again and broken it down by assignment or allocation, that's called LIR and non?LIR here, and then by whether it's seen in the routing table exactly as it has been allocated or assigned or whether it's more specifics, so...
These are the prefixes that have been given to local Internet registries and show up exactly as they have been allocated. And this is actually some, 2,500 more specifics 33 to 128 from local Internet registry address space, and these are PI DNS Anycast route name server and this is more specifics from there, so they sort of independent addresses or end user assignments or whatever the registries call them, don't make up as much a big part of the routing table yet anyway, so, no immediate danger here.
So, some background that you are all familiar with, I still want to have it here on record. What's important about IP address management is one is registration, of course, that's knowing very clearly who has been given what to be able to actually verify that somebody is responsible for space and somebody is entitled to route space, to actually make this work more robust or keep this working in a robust way.
Aggregation is even more important in v6 than in v4, because the theoretical number of of routes you can have is to huge, pretty much unbounded. So whatever we do, we should take care that aggregation is not destroyed or still the routing table is kept in a manageable size.
Of course, there is balancing to be done between what people want and what the Internet could peer.
Then there is conservation of course, which was more important on v4, but on v6, well, the address space is so huge that as long as we are not going to run out next year, but keep it going for 20 or 30 years, conservation is not the primary goal. It certainly needs to be ?? there needs to be an eye on that but it shouldn't be the primary focus.
Breaking this down a bit differently. What we have to take into account when doing policy, watch out for the routing table because if we do something that results in a million routes, it will break for everybody so there is no good in it.
NCC costs: So if we decide addresses are going to be free forever and everybody can get them without any ties to the NCC and then just close down the shop and keep the addresses even if they are no longer an NCC member, the amount of money the NCC gets stops, and then we have no database, no documentation, no registration. So that would also be bad.
End user costs: If we make prefixes too expensive, people will find creative ways like run a whole ISP on a 48 IPv6 space with multiple layers of IPv6 NAT behind it or so. We don't go there.
Usefulness: That's something we had in IPv4 PI. If you need a prefix to be visible on the Internet and you get a /29, which is not visible, which will not be routable, then it's not so useful, so this also needs to be taken into account.
And, of course, the efficient use of the address space, so don't give out /16s to people needing just one address. And good stewardship, encourage actually using the address space in a useful way.
This is an old slide but I decided to just leave it in there because it's still actual. What's the problems we have with IPv6 PI? That's the multihoming requirements that if you have, if you become an LIR, get PA space, there is no multihoming requirements. If you do basically the same thing but say well my network is smaller and I don't need a 32, I could live with a 48, and I don't want to pay that much, all of a sudden there is things cannot do with PI space, like be single?homed. There is the proposal 2011?02, which aims to remove the multihoming requirements and we still discussing whether we have consensus on that, Sander mentioned that yesterday. So maybe the multihoming bit is gone already. But then there is of course the cost part like, if you give the NCC more money, you get address space with different strings attached and I'm not sure whether this is exactly the right approach that the amount of money controls what you can do with addresses, so something to keep in mind.
User restrictions: That's the thing that cannot run a hosting provider on IPv6 PI space right now, even if the address space would easily permit that because the policy says no sub?assignments and giving addresses to other people is sub?assignment, or is considered sub?assignment right now. So different strings attached again.
So, we could spend lots of cycles to fix up the PI policy, fix up the PA policy, change blue strings against green strings and maybe that's the way to go, maybe not. So, the idea was to do this more radically. This has been presented at the last RIPE Meeting so you have seen the idea, but now we have worked out more of the details. And that's pretty much to abandon the distinction between PA and PI. What does that mean? That means that if you need addresses you go to the RIPE NCC and you get addresses. If you want to number your machines, you number your machines and there is no different colour text attached to the addresses that says, oh, with these blue addresses you can only number blue machines, but with blue addresses cannot number green machines. But you have addresses and you use that to number machines.
Initially, this sounds very easy, straightforward and no problems with that and then you start looking into the details and there is lots of details to be taken into account. You see an URL here, that's a posting on the mailing list from Friday last week where I sent a concept document to the list which has all these bullet points in it. Why are we doing this? How are we planning to do that? The feedback on the mailing list so far has been interesting, because the main focus was on charging, which is something the Address Policy Working Group actually doesn't decide. So on the idea itself, I have gotten feedback in person by a couple of persons saying this is not such a bad idea, let's go there. One person said, no way, and I am going to discuss this here later on, of course.
Let's go and look at the details.
The first interest in question is who gets address space in the first place? And we could be more radical and change the whole model on how LIRs and RIPE membership, and so on, works. But at this point in time I think would be useful to keep the existing LIR and sponsoring LIR model. So if you want addresses, either you become an LIR and apply directly to the NCC, or if you don't want to become an LIR because you don't like the NCC, you just find a friendly LIR in the neighbourhood, do a proper contract with them, have the LIR send the contract to the NCC, and the NCC will funnel addresses through the sponsoring LIR back to you. So that's pretty much what we have today for PA goes to LIR, PI goes through the LIR to the end customer without the direct assignment user category, because I think that's just complicating contracts so if somebody wants direct contact with the NCC, they can just become an LIR.
So, next interesting question: So far, we had end users get 48 PI and LIRs get 32. If it's all just numbers, we still sort of need to figure out which size the number blocks should be, that a consumer of these numbers will get. And one of the good things of v6 is that there is enough numbers, so, it doesn't make sense to have extremely detailed addressing plans for the next 20 years because crystal balls usually don't work so well for 20?year time frames. And we don't want to go into all this haggling about address spaces again, so this is what I propose, how it could look like.
If you go there and say give me addresses, you get a 48, because that's sort of like the end site unit. If you go there and say oh well I have two different end sites, they are not connected, but they both need independent address space, you get two 48s, like so you can get bigger addresses, or multiple 48s if you show that you have, well, multiple end sites.
If you show up and check the check box that says do you want to give addresses to other parties in the 48 to 64 range? So, do you want to do ISP like things, you get a 32 like today, or maybe a /28, depending on how the proposal from Jan works out. So you get sort of like the bigger allegation block. And if you go there and say I am Hungarian Telekom and I have 10 million customers, I want to give every customer 48, then you get bigger blocks of course, but you have to provide documentation for that. So for the really big blocks, nothing would change. You need the documentation. But for the small blocks, it's basically, it's a check?box that says 4832. Of course people that only need a 48 could check the box and get a 32, the question is whether we consider this abuse and want to deny it, and whether we can deny it in the end, or whether we are just pragmatic about it. We'll come back to that slide to discuss it later on.
Then there is in the policy today there is special case networks for exchange points, route name servers, Anycast named servers. With the new policy framework we could basically do away with all these special cases because they are consumers of numbers, they come up, they get a 48, be happy with it. There is one catch to that and that's that these prefixes have usually different ?? want people want to apply different filters to these prefixes in the routing system, so it would be useful to look at a prefix and immediately see oh, that's Anycast DNS, yes I should handle this differently in my routers, or that's an exchange point prefix, I don't want to see that in my routing table. So, the idea is that on the application form, there is a check box that says "This is going to be used for exchange points, for route names or for Anycast" and the NCC would then use the ranges they already have set aside to take the numbers from there. Basically, not changing the policy, well not making a difference regarding policy but just making a difference on which numbers you get. So, people can filter by these numbers.
Same thing for former PI stuff, that's things in the 33 to 47 range, or 48 range. Take it from a different block, so people can sort of like filter it by minimum assignment size. What's useful to prevent leaks and weird things and ?? well people seem to want that, but that's up for discussion.
Costs:
Originally that slide said we don't do costs. But that's too easy. So...
The Address Policy Working Group doesn't decide on costs for NCC Services. That's for the general meeting to decide. But of course we can give input on what we think that the charging scheme should look like. And sometimes that even gets taken into account. Sometimes not so much. But I think it's still useful to spend a few minutes on how do we think that a good charging scheme for this sort of addresses should look like, how it should not look like, because it sort of like gives incentives to people to do the wrong thing, and then give that as an input to NCC management to take into account for the next charging scheme.
And finally, one of the biggest cans of worms here, that's the multiple blocks to a single LIR thing. Right now, the policy says that if you have one 32 from the RIPE NCC, and that one is full, you can get a new one. But while there is still space in it, I will not be able to get a second 32. Which sort of models the IPv4 way of thinking, you get a new allocation every so often when the old one is full. That brings problems for people that just operate multiple different networks that can not use the address spaces for whatever reason. Maybe they have the same geographical networks that has a single entity so maybe there is a single entity that can become an NCC members, that are not open to two LIRs, or maybe a group of local ISPs decide that it's sufficient if one of us does the NCC membership thing, and we all like this guy so we all want to have our numbers using this friendly guy as a sponsoring LIR. Since there is no difference between PA and PI, this automatically implies that you could get your LIR, your provider allocation through a sponsoring LIR, because there is no difference. So if an end user can get their space through a sponsoring LIR, another provider could do so as well. Whether that makes sense or not, is a local business decision. But, if the numbers doesn't tell what they are going to be used for, we can not make a difference there like you can only have one ISP allocation but you can have as many end user allocations as you want, so we need to take that into account and decide on what the criteria should be.
For end user blocks, it's pretty much easy. Every site you have 48. But what could the criteria for provider blocks be? 32s or bigger. And just making it very liberal, come ask for it, get a block, I think that's not going to get consensus because then people are rightfully worried about address space burning and routing table and stuff. So, maybe there should be some rational who can get a second block, third block, fourth block, and under which conditions. And what Sander and I came up with is for any distinct network you can get a block of numbers. Now the question is what makes up a network, and this is what we came up with.
A network is, well, nodes that are interconnected to each other, so if you have two nodes that are not connected, they are two networks operated by the same entity, so if there is two different providers operating on the same network but having distinct customers, it's still two networks, because it's two different entities. That's important for some of the deployment models you see in like DSL with virtual ISPs, but everybody wanting to have their own address space.
Operator with a common routing policy, I think that's boarder case where is this be useful to make the distinction, have a different routing policy, be a different network.
And of course layer 3 networks. So this is not about bridged connectivity, layer 1, layer 2, or virtual hosting stuff, but this is really the entity that runs the IP addressing bits, the layer 3 part of the network is what's considered the network.
The plans to be reasonably flexible, so not be too strict because this is v6 after all, but not be too open because then I think we are not going to get consensus on that.
Some of the cases why this is all not so straightforward. There is providers using other providers layer 2 infrastructure for their layer 3 service. So, like, if we operate on top of Telefonica's network to give addresses to our customers, we don't own the network, we don't operate the network, but we still provide layer 3 services to our customers. So this model wants to take that into account. So, we still could get addresses.
Some of the cases that have been brought before us in the last year have been single LIRs that operate two different networks in some cases due to political reasons there is a commercial network and a research network that are not interconnected, but are operated by the same people because, well they know how to do it. So they would need two different blocks and cannot get them under the current policy.
There is other things like the French research network operating like the network on some of the French islands, which is definitely not connected to the mainland, so they need address space for that as well.
Then of course there is the classical PI end users being independent so that also brings up multiple blocks per registry.
And other cases.
So, now it's to you. I hope everybody is awake by now. The coffee is working. What I plan to do now is, we have some 35 minutes to discuss this, and first I want to have some feedback on the general idea whether we should pursue this at all, so if you want an early coffee break, just stand up and say, "no, we don't do this, please abandon the idea," then you can immediately go to coffee. But if you ?? I think we should at least give this just sometime. James, not yet please.
And given enough support, then we go into the nitty gritty details and give each of them some five minutes thought.
Okay. Let's start here. James Blessing is first then ??
AUDIENCE SPEAKER: James Blessing, Limelight. My only comment is, I think it's a good idea. But with the charging bit, has yesterday proved, we couldn't change the charging scheme under the current tax requirement. It's a nice idea to try and make v6 chargeable in a particular way, but apparently we can't do that. Otherwise, the rest of the proposal, having thought about it, makes sense.
GERT DÖRING: Now I am surprised because he approached me yesterday and said don't go there. I don't want this. Thank very much actually. I think that's the best thing that can happen to me that people come up say this is bad and say please reconsider, please read there and then they come up and say I have read through it and thought through it and it seems to make sense.
AUDIENCE SPEAKER: I would just say that I think it is a really good idea and you should continue pursuing this way
GERT DÖRING: Thanks. So no early coffee break for you.
AUDIENCE SPEAKER: It's Nina from TDC. I would have very, very, very difficult for me to try and explain this to my customers, because to the end customers that I have, the idea of PI space is so ever what's been seen. So now trying to say now we no longer have categorise but some of the space you can treat in one way and some you can't in another is going to be a very educational task whenever we finish this work, if we should do it. And I have not read it through and thought a lot about it, but that is my initial thing, is, like, oh, no.
GERT DÖRING: So for ?? I have heard a lot of questions about when to use PA when to use PI and there is actually fuel going that way because people get even more confused when they are running an ISP network and want to use independent space but have to go for PA to be independent. So, there is lots of confusion here.
So, we could do it in a different way like have the same policy but then have a tack on it PI and PA, but do you really think it would make life easier?
AUDIENCE SPEAKER: Nina. Probably not. But I do have a comment also on the tracking thing
GERT DÖRING: Let's come back to that. I will go through all the next slide one by one and try to keep the different topics sort of like bundled.
AUDIENCE SPEAKER: Sascha Luck. I think it's an excellent idea, I have always been in favour of this and the numbers from yesterday's GM, the fact that there are seven?and?a?half thousand layers, of which 300 vote, clearly show that there are a lot of layers that don't really want to be one, they just do it because they have to. The down side of that obviously is that if all these people are not layers any more, then the fees for the actual layers will probably go up significantly.
AUDIENCE SPEAKER: I admired one part of your talk, but I did not, others. So, let me say that I missed two arguments. One argument is that we are allocating numbers, not just allocating numbers, but those numbers should be in the table and these should be emphasised. And the other issue which I base that, with IPv6, you can allocate two different blocks or more different blocks from provider aggregated address space to the same customers, so this is not a problem, and this solves some of your problems to join two different providers in the times. And this is in the scheme that you are thinking about in the past.
But anyhow, provider aggregation is needed for routing
GERT DÖRING: Of course.
SANDER STEFFAN: Can you please state your name for the record?
AUDIENCE SPEAKER: Sorry ??
GERT DÖRING: Sander is reminding everybody to speak your name and affiliation, even if we know who you are. People on the other end of the microphone might not.
AUDIENCE SPEAKER: If you need longer than [] gaze a, because I was called always that name, [] gaze a too Channey.
GERT DÖRING: Just to respond to that, I don't ?? what I'm not trying to achieve is hand out more blocks, so, I do have aggregation and the routing table still inside. In the end, today people who think that their network needs a routing table slot can get one, even if it means they have to become an LIR and get an LIR prefix. One of the things driving this is that I don't think the amount of money that you invest into your numbers should be relevant on what you can do with the numbers. Because that's sort of like unfair.
What I certainly don't want either is that 10 million end customers or 50 million end customers of Deutsche Telekom all show up here and ask for a block of numbers that would go to the routing table. I have some confidence that this is not going to happen. Look can at the numbers from the other registries that have very liberal PI policies.
So, I still think that most, say 99.9 percent of the users of the Internet will still use address space from their providers and will not ?? numbers provided by the RIPE NCC directly, to avoid calling them assignments, allocations, PI/PA. But what I hear from the room is we need to be careful on how exactly we are going to do this. But in general, we should pursue this. So, no early coffee break for you. Now we have to go into the details.
First thing, who gets address space? Should we keep the model that we currently have? The alternative model would be everybody who wants address space from the RIPE NCC becomes a member of the RIPE NCC, which would mean something like 20,000 members, which I have heard some people voice that they might want to see it because then, of course, the NCC has more direct contact to the users of the numbers. I have heard other people say that they don't want this because doing all this international paperwork stuff is unnecessary hassles, they have friendly ISPs nearby that can do all the paperwork for them. So please let me know what you think.
Kurtis?
AUDIENCE SPEAKER: Kurtis Lindqvist, Netnod. I think you should keep the sponsoring LIR model because otherwise, I think that's the best way to ensure we have accurate and up to date data.
AUDIENCE SPEAKER: My name is [] /TARB a sand os, I speak as a private person. What happened with IAT network in the country is I want to change this network to another country and we need to remember...
GERT DÖRING: Well, since currently ?? well, if it's ?? let's say the countries are in the RIPE service region, then basically you are free to use it wherever you want anyway because the country indication is just where your company is registered. It's not where the network is used. So, if you want to transfer the network to a different party, we are actually in the transfer policy discussion, but if it's just you building a new network in a different country, so there is nothing wrong with that and no need to re?number.
AUDIENCE SPEAKER: Then I need to be an LIR?
GERT DÖRING: No. Basically, the networks are not given two to countries, networks are given to people signing the contract. So when that person moves to ?? or that company moves to another country, which is not that frequent, but persons move to different address, so I don't see any problem with that. It sort of needs to be documented if it's a private user and you move to a different country, your home address changes and well the home address on the contract, then of course the contract needs to be updated but the network doesn't need to be changed.
AUDIENCE SPEAKER: But in another country I need another response from an LIR.
GERT DÖRING: I see the problem here. You don't. You can change the sponsoring LIR by making a new contract and moving the NCC records to the new sponsoring LIR, but since the network itself is independent of the sponsoring LIR, it's not coming from their aggregate. You can take the network with you. And, of course, you can keep the old sponsoring LIR, like, even if you move to a different country, you are still friends with the people over there, you still pay your yearly dues, nobody forces you to change the sponsoring LIR.
AUDIENCE SPEAKER: Okay. Thank you.
AUDIENCE SPEAKER: Sascha: I just sort of wanted to agree with Kurtis and I forgot to say that earlier that if only those who want to be LIRs and not a lot of people who have to be, are LIRs, then the quality of the database will obviously be much better because most of the have to be LIRs don't really have an interest in doing anything beyond getting IP addresses.
GERT DÖRING: That's actually an interesting angle. I have not thought about that so thanks for bringing that in. But, yeah, participation of people that just are LIRs, because that's the way to buy numbers, is low.
Okay, so let's go to the next details to be worked out.
So, anybody who wants to comment on that? Okay. I see some people giving clear signs that they don't want to talk about that. Whatever that means. I personally think it's workable. Maybe let's throw the ball at the NCC. Alex, do you think this would be workable for you?
ALEX LE HEUX: I think something like this will definitely be workable. And there is one case that might happen that I don't see, what happens if for example, one of the very large ISPs in Europe decides that they would go through a sponsoring LIR as well instead of be one themselves and that they, you say here /32 and you plan to assign /48s, what if that's one that has 20 million customers?
GERT DÖRING: Yeah, that's ?? well the very large one is larger that when documented need. Well I see no difference between LIR and going through an LIR, so...
ALEX LE HEUX: Me neither. I just wanted to have that clarified.
GERT DÖRING: Okay. That was an easy one. I think that's also something it's just quite straightforward because it's just there to help people to see what's going on but I welcome your input. You do want an early coffee break. James?
AUDIENCE SPEAKER: James Blessing: The only comment is you might want to register that it's a special use in the database as well as just putting out a single block, but that's not Address Policy, that's someone else's problem
GERT DÖRING: That's the documentation bit, which of course we want to do. Yeah, good point. So people that just, don't just look at the numbers but also look at the database and we can see that that this number is tagged specially.
AUDIENCE SPEAKER: Kurtis: I want to say the same you want to take this ?? if there are specially want to be able they are spec and treat them specially but I guess for example the route server already has addresses so that's a non?issue, but we /32s by the way, not /38s, and that might be worth ??
GERT DÖRING: That doesn't actually say how big the range is.
AUDIENCE SPEAKER: Kurtis: I mean, the two route servers in the region have v6 space but there might be other cases like the ISP prefix that is you do want to treat specially therefore they should be coming out of a separate block for those addresses so don't treat them as any PI space.
GERT DÖRING: Okay. So that's definitely a space.
AUDIENCE SPEAKER: Chris Buckridge from the RIPE NCC. We have got a comment on the Jabber chat. Ivan Beveridge says the LIR quality of data issue is quite valid, I feel, would only have a number of years or a decade consider VIX contact issues today.
GERT DÖRING: I am not sure I fully got that comment. Can you bring me the laptop so I can just read it.
AUDIENCE SPEAKER: Was that referring to the previous discussion?
MR. BUCKRIDGE: It's possible is only just appeared in the window.
GERT DÖRING: I have been asked to repeat this again. I think it was actually related to the previous discussion about the LIR quality of data, and I think it's the argument that the quality of data of the LIRs. That argument is valid. And he said consider the EIX contact issues today, but I think that should be the ERX contact issues. Whatever. Correctness of the database is important. That's clear to me.
I really need a chat screen up here, which actually would work because that laptop screen is not connected to that laptop. Anyway, cool standing up here and just chatting to people.
Next one:
The nasty one. With the costs, one of the things to keep in mind is to give proper incentives which means that if we tell people a 48 is very cheap and a 32 costs 100,000 euros a year, then we will see Internet providers running their whole business with millions of these customers on a single 48, giving customers a single IP address and making them use NAT, which I think would be bad stewardship. So, at the same time, I think that just making it flat, like every LIR pays the same amount of money every year no matter how many blocks of numbers they have been given out is also the wrong signal because that, in the end, could mean that only one LIR per country remains, and they do all the numbers in their country. National Internet registry, that might actually be an interesting thing to...
Okay, that look, you should have seen that look. People are awake. So that's the idea I came up with with: Have a base fee which sort of like, well covers the base amount of money the NCC needs and then per prefix fee which is sort of slightly going up with size but not extremely so. This is a really problematic one because we only can recommend it and the HEM can decide whatever they want. So, this is problematic, but of course we can recommend, so I am interested to hear what you have to say.
SANDER STEFFAN: I want to make a short comment, yesterday during the AGM it was said charging per address block would cause problems for the NCC.
GERT DÖRING: Networks charging per address. So if it's linear, like, you can't have ?? buy a piece which we had in the last years without problems, but we can not go buy address. That would actually cause problems.
SANDER STEFFAN: The point is if the tax office thinks the NCC are selling addresses they are going to tax them, so that's not a good idea so we have to keep that in mind a bit.
AUDIENCE SPEAKER: Wilfried Woeber, around on the net and in the LIR business for a while. The thing that worried me yesterday during the general meeting and that worries me again, looking it slide, is that we seem to be drifting away, consciously or not, I don't know, we seem to be drifting away from the traditional model that the cost should be related to the effort in the RIPE NCC. So, looking at the activities of the RIPE NCC, I do see two very large but slightly separate areas. One of those areas is actually the, keeping the infrastructure in place and keeping contacts with other parties and doing all that interesting stuff that came about over the last three to five years, and I think this is a cost which should be shared rather flatly across the community one way or another, I don't have any particular proposal, but I think those entities and those parties who are interested in the well?being and in the proper management of the Internet, should have the environment and also should have the willingness to join in with the RIPE NCC to enter a formal relationship, contract, whatever it looks like, and to pay for this infrastructure effort.
On the other hand, I'd like to see, well, I do not like to see things like a /48 would cost X, a /whatever, being four times as much, would cost N times as much. Because this is completely against the tradition that we actually pay the RIPE NCC for the effort to maintain the registry service. And like what we had in the past was IPv4 and IPv6 looking at these many small grains on the beach of IPv4 stuff, that needed quite a bit of registration effort and keeping track of all that stuff. Working Group IPv6 technology coming around, I really do not see any difference in the effort with regard to the RIPE NCC, whether I have a /19 or whether I would want to register a /56. So I dislike this idea that there is a direct relationship between the size of a block and the cost of it. Irrespective of the tax aspect of it, which I definitely do understand. Thanks
GERT DÖRING: So, just asking back on this, so what you would like to see is, there is a base fee that covers all the neutrality work that the NCC does for us and a single fee for each block of numbers given out, no matter how big the block is. That fee would sort of cover database operations and registry services.
AUDIENCE SPEAKER: Wilifried: Registry services, database operations, depending on what the result of yesterday's votes are, sort of digitally signing the holdership certificate and that sort of thing, sort of while I do not like to ?? because it would be too fine grained to actually have a charge per ticket, I'd sort of like to see something which is related to the effort at the RIPE NCC's end, not at the customer's end, the RIPE NCC's end, to sort of keep the registration thing up to date and correct and maintained and ??
SANDER STEFFAN: Do I read from your comment that you also would like the per piece installation fee because obviously the request is the most intensive part of the work?
WILIFRIED WOEBER: Yes, well we are piece insulation pee would be something similar to the setup fee we have right now. It would probably be named differently, but the concept is fine with me, because there is an effort, you can clearly analyse and document what the efforts are, so it should be pretty easy to come up with the price tag for that and yeah, you charge for that, and you add on.
GERT DÖRING: Okay. We hear you. Sascha is next.
AUDIENCE SPEAKER: Okay, back again. I was just, when I see that and is looks for me pretty much like this, which was yesterday, rejected in the AGM because of tax issues, so I am afraid this looks too much like selling IP addresses ??
GERT DÖRING: Okay, down with it. I'm not married to that. It's just a proposal. I am hearing you.
GERT DÖRING: I think Sascha wanted to say the same thing.
AUDIENCE SPEAKER: Again, I just think that how do you take conservation into consideration? So, I think this issue is priced differently so you consider how ?? conservation in the address space which should be also a point, maybe not in the first point, but...
GERT DÖRING: If I go back to this and do the maths, there is one billion 32s available, so, if we demand good documentation for the real big assignments and we have something even as low as 50 a year, if we give out a billion 32s, the 50 a year should really stop these people for requesting for a billion of prefixes. So I think given that there is so many of these prefixes, having even a small fee per prefix, and having documentation required, should take care of the conservation bit. We are not proposing to give out like 16s or so, which are really a few of them, but there is, as I said there is one billion ?? it's just 500 million 21s in the first 001 former prefix..Kurtis.
AUDIENCE SPEAKER: Kurtis Lindqvist. I am actually worried about where this discussion is going and I don't agree with Wilifried at all. Because as an existing LIR I hope that I pay for what the cost I incur in the RIPE NCC today and if I don't, I think we should continue the AGM from yesterday. I think there is a major problem if we actually assume that this has somehow related to ?? we can't express this in terms of the work involved right because in that case there should be a per ticket charge for RIPE and we have a simple billing model, it's simple. But I think that if you compare this what you propose here to the pricing of what the LIRs pay, this is a little cheaper and and it's the same amount of addresses and work, and that doesn't fly. I don't think it should be such a great difference between this and the charging scheme for normal LIRs. It should be the same
GERT DÖRING: Well I didn't say anything about the base price. It's just ?? I just put up numbers for the per piece price to have something to start the discussion.
AUDIENCE SPEAKER: Kurtis: My comment is I think this should be identical to the LIR charging scheme. It's the same amount of work and in a few years we won't be doing v4.
GERT DÖRING: I think we need to get together on the mailing list to sort of like come up with a proposal that's better balanced and better takes into account what you're thinking. And then go to the AGM and start arguing about it.
AUDIENCE SPEAKER: I want to add that I think we should not try to press address preservation by increasing the bill but by making the documentation strict enough to go to address preservation in the end.
GERT DÖRING: The point I was wanting to make maybe that was not clear is, we are consciously very liberal on the 48s and 32s in that model. You come for it, you present the case that you have a different network and you get the prefix for it. With not so much documentation needed. So, there is potential for people using up lots of things. But, having even a small financial per thing fee in the model would actually stop them from using up 500 million of them. That was the point I was trying to make. I'm not saying we shouldn't have documentation, but let's not over do it at that point either. Okay. What I'm hearing is that this charging model is not going to work and we need to go back to the list on that.
The last one, which I think is certainly necessary to have criteria on who can have a second block of addresses, under which conditions. So I am interested to hear your feedback on that.
SANDER STEFFAN: I actually expected a lot of comments on this part.
GERT DÖRING: Which actually suits me well, timing?wise, because then we have time for Kurtis AOB thing. James?
AUDIENCE SPEAKER: James Blessing: The only comment is if you are too flexible on the definition of network, people gain the system to have lots of networks
GERT DÖRING: Do you think this definition is reasonable?
AUDIENCE SPEAKER: James: The problem is I can sit here and go through all the cases. I just think the wording of the documentation needs to be maybe a little bit stricter than the definition there, but not much
GERT DÖRING: Okay. The plan that we have here is actually to take your inputs, then take your inputs on the mailing list, and then ask the NCC to help ?? ask native speakers at the NCC with with the technical writing background to help us write a proper document that is very clear in language, that has very much ?? very few vague parts so there is really clear words on this and then of course circulate that to the list again. So, then we need your view a review of course.
AUDIENCE SPEAKER: Kurtis Lindqvist: So, I don't really quite understand what the opposition against having multiple blocks assigned to one organisation would be
GERT DÖRING: If you tell me, remove all this opposition and ?? remove all the criteria and just pay by the block, fine with me. That makes my life much easier, but from the experience I have expected some resistance against a too liberal policy.
AUDIENCE SPEAKER: Kurtis: I understand that, my point is that no you should get as many blocks as you want. I think that people can justify why they need more blocks, for example if they have reverse location ifs you have a multinational company's that needs for redundancies and discontinue networks, they will actually need to have multiple blocks. In this way, they can't have that. Either I think we need to take that into account our definition of network, that an organisation is allowed if they can argue for it that they have routing requirements or whatever they want ??
GERT DÖRING: So if you have two bits of your networks with different routing policies, I think that might help you. The reason why I have the actual spelled it out is, that policies, where we say yeah, provide reasonable documentation to the NCC, usually the good folks at the NCC are not so happy about. So what are we going to expect from people? What's the reasonable? What's the criteria you want us to apply? So if we make the guidelines too unclear, we get policy implementation that's not exactly what we thought it would be.
KURTIS LINDQVIST: My point is, I never quite understood ?? I have to admitted that I never quite understood what we mean by routing policy because I can imagine that you are a multinational company who might have the same AS number in multiple locations ?? and therefore you need a different policy. Is that a routing policy or not?
GERT DÖRING: If it's disconnected, sort of immediately it's not the same network.
KURTIS LINDQVIST: Then don't call it ?? okay, then it's not a network if you ask me. Than it's an organisation. So call it an organisation.
GERT DÖRING: Okay. We take this to the list and try to come up with something that is clear enough.
ALEX LE HEUX: If there is going to be a limit on the number of blocks that one LIR can receive, the NCC would very much like very clear guidance on what to do because this is only one, this accept wrote networks that kind of thing is only one of the reasons that's in our experience people would want different networks ?? or different blocks, because there is lots of political and economic and all sorts of other reasons that people have for wanting multiple blocks, and without clear guidance, as you said, the implementation of of this is going to be difficult.
GERT DÖRING: Okay. So, actually, you just put an action item on yourself. If I could ask you to come up with a list of things that you have seen that cause discussion and haggling and so on, so we can sort of better evaluate what sort of cases come up. I have a couple of problem cases but I certainly don't see as many as you have ?? thank you ?? newer anney.
AUDIENCE SPEAKER: Nurani from Netnod. I didn't get the last part about limit, I think that would be an artificial limit, you can either justify it or you can't. Why would you say okay an LIR can get max. Four separately routed aggregatable blocks? To me that just sounds like administrative ??
GERT DÖRING: You want the 200 customers rules back?
AUDIENCE SPEAKER: No, what I'm saying is that you either have rules and it's justified or not, if you fulfil those criteria, and you stick to that
GERT DÖRING: I seem to hear that you said a maximum of four or something and that would be introducing arbitrary numbers again and we haven't been very successful with coming up with useful arbitrary numbers in the past. So that's why we got rid of the 200 customers rule.
AUDIENCE SPEAKER: That's exactly my point. That's exactly my point. Why come up with a theoretical limit? You either justify it or you don't. You could say 3, or 4 or 5 but that doesn't make sense
GERT DÖRING: We don't want any numbers in there. I understand you right and I fully agree with that. Yeah... we take that to the list. We take input from Alex and then we see whether we can come up with a definition where people would agree on.
Okay. Thanks for all that input. We know what we have to do next. We have had clear guidance on some of these items, what to change. And now it's actually Kurtis on stage, with some, something the IETF did which we might want to think about. Thanks.
KURTIS LINDQVIST: I am Kurtis from Netnod. If you haven't heard me enough already. So, the IETF has published something called RSC 6382 and I want to point out that this is not my idea. I don't even think it's a good idea. I don't even think it's a bad idea but I did see the RFC being published and I thought you might want to have a small discussion because it does say things about how we should do policy. So the problem that the RFC is trying to solve is that if you do Anycast, you normally use the same source AS for all Anycast instances around the globe or the network and the RFC seems to think that there are cases where you might want to identify or if you are trouble shooting other purposes which source actually talking to and today you can do that folks, if this is DNS, there is host name would BIND and son, there are other ideas that you can use to identify the instance you are talking to. And in this case, they are argue that you want to identify this based on AS origination. You could of course do this in other ways like AS path etc. Which I think maybe is good enough but the RFC doesn't seem to.
The other argument is that if you have a different source AS you can actually have a different ROA if you ever get RPKI deployed for each of the instances and therefore you could publish different policies. So, this is the argument in the RFC and it goes on to say that AS numbers ?? sorry, blah blah blah, if you do Anycast, you should utilise a unique origin ASN per node wherever possible. It's not a requirement, it's a should. However that's what the RFC said.
So, it also points out that if you run critical infrastructure such as route and TLD name servers, this should warrant special consideration with regard to AS number allocation practices during the policy development, which is what we are doing here, and it goes on to say that, defining precisely what institutes critical infrastructure should be done by each of the RIRs in the policy.
So, this seems, when I read it, to that the Address Policy in the RIRs needs to take this into account or decide what we want to do. And I no he what I want to do, but anyway.
The current policy fora signing AS numbers say that you should only get a new AS number if external routing policy is required. And well you have to be in the multihome, which obviously you need to qualify this. But actually not all Anycast instances are multihomed. Some of them are actually single?homed. But they are advertised in multiple locations. So, if seems to me that the current policy doesn't actually allow for people to do what the RFC says. That's my reading anyway.
So, we have three options:
The first one is to tell the IETF that they have nothing to do with address or AS assignment policies. That's up to the RIRs to decide, which is my chosen way. Update the policy and find wording that matches this if you run critical infrastructure, and whatever, you ?? and you do Anycast and you can prove you do Anycast then you can get as many AS numbers as you want. Keep in mind you have to say you can get as many as you want because you don't know how many needs people have, or I have misread the entire policy and we believe that this is not an issue, which is not my reading.
Questions?
ALEX LE HEUX: The way AS policy is currently applied and interpreted which the RIPE NCC means that Anycast instance is likely to be seen as separate network, which will qualify for its own AS number provided that instance is multihomed.
KURTIS LINDQVIST: But they don't have to be multihomed, and many of them aren't.
ALEX LE HEUX: The AS policy says multihomed, so provided each one is multihomed they should qualify for each number under the current policy and interpretation is.
KURTIS LINDQVIST: My point is that the current policy doesn't allow for Anycasts to get separate AS numbers. We have many instances that are single?homed and we couldn't get numbers for them.
GERT DÖRING: I am not exactly sure that I understand that. How does ?? so far I always assumed that these Anycast instances would then be located for example at an exchange points with with lots of different peers which makes them multihomed in the sense of the policy. So if you have more than one BGP peer in different A Yours sincerely.
KURTIS LINDQVIST: We we also have locations inside carrier networks. One of the other route servers, L room is primarily located only inside carrier networks and all other instances are single?homed but the Anycast is still, as such, has multiple upstreams.
ALEX LE HEUX: An instance which is located in one particular network, can that use a private AS?
KURTIS LINDQVIST: Networks because then we'd have no control over the policy.
SANDER STEFFAN: And you can't use the AS of the carrier network to announce it?
KURTIS LINDQVIST: If you ask me, this is not an issue but the RFC do you want to do this to do ROAs because you can't do that and that's also influence the routing policy to the external world either so that's a no go. You have ?? me as an owner of the service needs to have control of the routing policy.
GERT DÖRING: We are not asking me say questions to a now,
KURTIS LINDQVIST: I didn't mean to sound annoyed. That wasn't my point
GERT DÖRING: I am not operating Anycast route servers.
AUDIENCE SPEAKER: REMCO: Address policy hobbyist. I have a question, a thought and a suggestion. That's start with the question first: Is anybody aware that this region already has an infrastructure, a definition for critical infrastructure?
KURTIS LINDQVIST: Yes.
AUDIENCE SPEAKER: We have one. Okay I was previously unaware of that because otherwise I would have suggested that we define one.
KURTIS LINDQVIST: Sorry, Remco what we have is that the policy allows for routes, is it route server and TLD operators and ENUM operators that can get Anycast prefixings so it's critical in that sense. I don't know if it's actually worded adds critical.
AUDIENCE SPEAKER: I don't think we have written it down as critical infrastructure and given that I would suggest that this region, this community writes down critical infrastructure as a node set and let's see what's the suggestion again. I think, yes, err was the suggestion.
AUDIENCE SPEAKER: Wilifred Woeber again. Just a question for clarification about the mind set behind the RFC. At first read, it looks to me that the mind set is that the Anycasted service at the edge is provided by one single box with one single IP address which probably is applicable for DNS type stuff, but not necessarily for other types of Anycast, did I get that right or am I off track?
KURTIS LINDQVIST: I don't think that ?? no, none the Anycast services is one address and one box. There are multiple boxes and multiple prefixes.
WILIFRIED WOEBER: I am thinking about upcoming technology like cloud and that sort of things where you might have stuff which is actually distributed amongst many different boxes or at least many virtual different boxes, hanging off a wire and then I am getting concerned about the potential reading of that stuff, that each and every instance of that, or each and every box or virtual get should get their own AS number. And then it sort of sounds weird.
KURTIS LINDQVIST: Anycast is distribution for DNS. It's used in many many places. Yes, this will be a lot of AS numbers. That's clear.
AUDIENCE SPEAKER: Sascha lock: I was kind of thinking the same that this seems to be designed to help the large content distribution networks to better engineer their traffic and I wonder if there is a risks that this would mean that even the 32?bit ASN space will be snapped up by some large CDNs.
KURTIS LINDQVIST: I don't think that there is any particular user proposes this and actually a very large CDN is behind you next in line and tell us what he thinks about this. Patrik.
AUDIENCE SPEAKER: Patrick Gilmore, Akamai Technologies. We don't care, we are not going to use this for anything like that, so that's just to answer the last question. There is lots of other CDNs maybe one of them would do. In fact many CDNs work based on using Anycast name servers of their own and I don't know how it would affect them to interact both to both.
Anyway I want to bring up an operational point. My esteemed colleague, Mr. Steinbergen, points outs that many people, in fact I think most people have some kind of BGP multipath configured on their routers and this would break that. So, having multicast broken could or could not be considered a feature, but for the IETF to create a policy that has an effect on many operators internal existing routing configurations is probably something we should think about very, very hard before we do and I would suggest against it.
KURTIS LINDQVIST: I think Remco is next, then James and then you.
REMCO: I just remember my suggestion again, since this is mostly about ROAs, how about we add this thought to the work group for certification policy.
KURTIS LINDQVIST: The RFC speaks very little about ROAs as an argument, if speaks mostly about you should be able to identify the instance that ?? the entire perception of this is if there is something broken in the path in Anycast instance, I should be able to filter that out but you can still do that with the same AS everywhere because you know the path. That seems to have been lost in the RFC and the RFC just talks about ?? I don't know. Again, I don't want to defend the RFC because I don't agree with it. That's the writing in the text.
AUDIENCE SPEAKER: So we are not protocol police or routing police so I think all that have is no, the only thing that pertains to Address Policy is the ROA part and if ever we get a certification policy, I suggest we include this.
KURTIS LINDQVIST: Okay. I think it's James.
AUDIENCE SPEAKER: James Blessing: Also a CDN. It wouldn't affect us. We wouldn't use it, because we have a connected network. It's talking about unconnected networks.
A couple of things. You said we can push back on this. Can we actually get them to delete it and forget about it and give it as a really bad idea and just ??
KURTIS LINDQVIST: I'd be happy to co?author a draft and try and push it to say why this is a really bad idea. Anybody who wants to help me.
JAMES BLESSING: Count me in.
AUDIENCE SPEAKER: Google. I am not sure I look the idea so I am curious why it says should. Can we change to to may so people who like it can use it and people who don't like could just forget it it.
KURTIS LINDQVIST: We can't do that but we can go to the IETF and ask them.
AUDIENCE SPEAKER: Probably you can explain why it says should.
KURTIS LINDQVIST: I can't, sorry, I wish I could but I can't.
AUDIENCE SPEAKER: Richard Steinbergen. One suggestion here, rather than break the BGP best selection path process, really what they are looking for, I can see the value in what they are trying to to do to be able to identify knew neck Anycast nodes but probably something like an approximate community, if you picked a range of reserve communities, and used that, and just you know had a reserved for example top 16 bits and then had you know the bottom 16 bits reserved for just sequential numbers, node 1, 2, 3, that would let you identify Anycast node, filter the route and actually not consume global resources and break anything.
KURTIS LINDQVIST: That's true to. You would have the AS path to identify on, yes.
So, I am not really quite sure. The consensus is don't change the policy and we can collect volunteers to help me write text to the IETF
GERT DÖRING: I read it in a different way. I think the answer is a bit of 1, bit of 2, bit of 3 of your slide. What happened I think at this point is the way ?? what this group can do is to actually sort of push it back to your lap and ask the Anycast operators to make up their mind whether you want to follow the RFC so if the operators come up and say yes we want to follow the RFC, then we need to change the policy to take into account single?homed Anycast nodes. If you ask the operators, agree that you do not want that, then we don't have to do anything. But you have to make up your mind first.
KURTIS LINDQVIST: I know what I want. I would ?? I don't think we'll do this, to be honest because changing the AS number on a few thousand peering sessions is not feasible. The other is, I mean I talked to some of the other route servers yesterday and they don't seem to be doing this either. Patrik?
PATRIK FALSTROM: I think the community was pretty clear that this is a bad idea operationally, I said operationally disastrous to some. I have ?? I have no idea why we would even want to have something floating out that there some guy that is got an idea of how the rest of the Internet works can point out and say you are doing something wrong and try and filter our routes completely or something like that, because that will happen. On top of that, the policy is clearly not fully thought out since there are single?homed instance of Anycast that would have to change drastically that would have to fit anywhere near the policy. So I am pretty clear that we write text to tell the IETF that they were wrong and I think it's a very simple text. A big N?O and send it to them.
GERT DÖRING: That's very fine to me because it means less work for me and more work for you. That's what I'm hearing in the room, that there is no work for the Address Policy community right now.
AUDIENCE SPEAKER: My name is Ben Gordon from RIS allowance. I agree with the following speakers. But what I would just remind you is this is a best current practice not suitable for standardization.
KURTIS LINDQVIST: It's neither best or current, but you are right. Remco? Okay. Done...
GERT DÖRING: /HA*PBGS for bringing that up so we know what's going on. (Thanks) I am not going to get up there anyway. I thank you you all for your participation and we are three minutes late, we are perfectly in time for the coffee. Thanks for being here. Thanks for giving the input and see you on the mailing list.
(Applause)
(Coffee break)