Archives

Address Policy Working Group
13 May 2015
11:00 a.m.



GERT DÖRING: Welcome back. To the second Address Policy Working Group meeting. We actually have to do some agenda shuffling due to technical constraints. The plan was to have the presentation from Meno next, but but we will actually bounce to that policy proposal first, because both proposers couldn't be here in person one of the proposers, Alexander Brinkman, has agreed to be here on Skype, and the tech support opened up the session, everything, in the break, so he is sitting on his laptop waiting to be virtually on stage, so, let's not keep him waiting until 12, but have this first, and they reshuffle the rest to make good use of our time.

So, the idea is that Alexander will be briefly on screen on video, and then we put up his slides and by remote audio, he will walk us through the policy proposal and then we have a discussion.

So... I think over to Skype. Welcome to Alexander. Thanks for taking your time to present your proposal. The video looks a bit pixel‑ish, but the audio is amazingly good. So... thanks for being here and off you go.

ALEXANDER BRINKMAN: You can hear me. Hello everybody. I will welcome you from Germany from high upon where I work for a big retail company, for Copeland, Copeland is a Stakeholder company of Lidl, also a very big retail company, and welcome to this presentation. I'd like to give you an introduction to our proposal.

I'm the co‑author of the proposal, together with Matthew Newton from the Military of Defence for the UK. So, the title is clear, so, could you please go to the second slide.

So the motivation. What was the motivation of this proposal? We are working for a very large company, a very large organisation, we have seen that the current addressing policy is not fitting our requirements. It is very, very provider‑orientated, it is from the year 2002, so, pretty old right now, and it doesn't really fit for the need, so the requirements of private organisation or large companies. So, it was difficult if there is a need because of some organisational structures to have a need for larger than prefix than 29, then it's almost impossible to get it currently by the RIPE policy. So the requirements of private organisations differ because we have more need in our, let's say, the internal structure. The internal structure of the network, how networks or IP ranges are defined are completely different than the requirements of ISPs in the public Internet. Private companies need more segmentation, logical segmentation and geography regions, functions and on on. These are some examples and we have seen during our IPv6 planning that makes sense was very helpful in many cases, to have for this different types, nibble boundaries, so always four bits for some kind of segmentation and to make it easier to read and understand.

So, this means that for private organisations, a logical structure is more important than this efficient usage of address space. It is clear that we're talking here about a waste of IPv6 addresses, but for our requirements this is a calculated scenario.

Large public address IPv6 address space. ULA addresses are no alternatives for us, and things also for other companies, because we want to avoid network address translation. Also requirement is said that we need at least a /48 prefix for every location to have the possibility in the future for individual public routing, so that everything location, also the smallest location, could be able to be reached in the Internet later on. So it makes sense just to have the really smallest network available using IPv6, we should have really large block per location.

When we look at the current policy, it was required that the documentation is ‑‑ the documentation of the network structures and the usage is documented, and as I said earlier with the structure that we have for our private networks, it is impossible to fulfil these requirements that we have in this official policy.

Also, is the situation that in comparison to providers and other, especially ISPs, when we have a large block an IPv6 block, only a really small part of it will be public or reachable directly in the Internet. Most of it will be private, like we have it today with this private IPv4 address ranges. So, the structure, how we separate, how we implement a logic, this is a complete private part, only a small piece of it will be reachable in the public Internet.

So, the goal for this policy change, what we'd like to have is, okay, let's say there could be two possibilities from our standpoint, the one is to have modification of the current naming; how to be defined reasonable usage for larger address space. What is exactly meant by this, and how is it possible for a private organisational company to fulfil this. An alternative could be to have an exception. An exception for large organisational companies. I think when we look at ‑‑ on our planet, and there are not that many organisation or companies which are that huge that have really the requirement for such a large network, but some are, and some have it, and how can we or RIPE handle these requirements in the future.

This is currently a showstopper for some organisations that we can't go on with our IPv6 planning because we have no space for a proper segmentation, for proper planning future.

So this is the overview of our idea. This now, of course, is open for the discussion, what could be reasonable, what arguments could be defined, and our point in our current situation, for example, the number of the locations are one indicator. For example, we in our company, we have in summary more than 10,000 locations distributed over a lot of countries. So, this could be a possibility how to define, or how many hierarchy level such a huge company could have or should have. So this is the main idea behind, to open the current standard which does not give us the flexibility for proper IPv6 planning.



GERT DÖRING: Okay. Thanks. Your Working Group Chair speaking again. I think we can go back to Skype, so, people can see who they talk to. To add a bit more background maybe, the other proposer is working for the British Ministry of Defence and has sent a fairly detailed, as far as he is permitted to tell, description of the problems they are facing to the mailing list I think yesterday or Monday, so, it's really not just the defence sector or just the big companies but sort of like a unified in pain, that the current policy, the English location policy really takes into account ISP like things that now we have those millions of customers and now we want to go to v6, which is a bit unflexible. Andrea mentioned this this morning as well, that they have just a few numbers of these very large requests, like 20 in total, that just did not work out with the current policy.

So, what the proposal basically does is to take away the requirement on the number of customers, or the existing network structure, and give very much flexibility to, well the NCC for evaluating this. What I think we as the community need to agree on is whether we want to have a very open initial allocation policy and leave it to the NCC to evaluate requests, which might backfire because the NCC might set up criteria that actually don't match what we expect, or, whether we should have sort of like a list of criteria, like if you have ‑‑ you could either base this on number of users, number of sides, number of aggregation levels and so on and then again have to come back and revisit it because now we cover like five out of the 20 and the other five are still not be able to get the addresses they need.

So, this is what I want to throw into this. Where do we want to go? And keep in mind that this is actually two different very large organisations but basically facing the same problem. Let's do the comments from the microphone and then I'm going to ask some questions to the NCC actually. Please...

AUDIENCE SPEAKER: My name is Leesim Bendam and I configure routers for a living, at least some of my living, so I what worry about is when I hear a /28 and I want to have /48 per location, that it is a will million locations can fit in a /48, but unfortunately it's only 10,000, it still means that there is 50% of the current IPv6 table for just one company. So this worries me a lot and then especially if it's going to be one /8 or even larger worldwide so that means now for instance if a company does this in the United States and I say I don't need to know all these /48s, for all the cities in the US, I can say this is American stuff, send it over the Atlantic and they can figure it out there so they can filter the /48s, if it's a global prefix I can't do that so I would urge RIPE, and the other RIRs, to not give these companies one global forensics for this, but at the very least, keep it per RIR so they would have to have five for this. Also, I think obviously it's nice to be on nibble boundaries but if you are going to use blocks like a /28 I say you are work it with hardware nibble boundaries and don't waste that much space. We have a lot in IPv6, you don't have to be too stringent but just say okay it's too hard, if it's not nibble boundaries I think it's /28, /32, that can be an argument.

AUDIENCE SPEAKER: Alex, I think I understand what you want to do, you want to use bits in the addresses to go your hierarchy because you want to do aggregation on lots of levels. What's not clear to me is why you want to do that, if you have 10,000 locations and no hierarchy you have a routing table with 10,000 entries which is pretty small. Why do you want to do this?

ALEXANDER BRINKMAN: Just, the main reason is to have our internal routing table also proper and that we are able to have routing summaries as good as possible as much as possible. As I said, the main need for this IPv6 addresses is the internal network, only a small part of it will be public in the Internet. It's for our internal structure is similar to what we have right now in our private ten network, and this helps us a lot and as I said, we are together with our ‑‑ so in our special case here, with our Stakeholder companies, we are currently having two companies which are merging together and it has shown that this kind of segmentation helps us a lot and we have to make smaller parts of this, and do not use it as nibbles, then it is for many countries possible, but when we would have for larger company one structure for smaller countries completely different structure, and the idea is to have the same logical structure everywhere with you know the risk that we waste IP addresses, so that is why I have said the structure is for this for us here more important than the efficient usage of addresses.

AUDIENCE SPEAKER: This still doesn't entirely answer my question, because even if you have no hierarchy, you end up with 10,000 routes which is just not very much, and in a /29, regardless of your size, if it's in the 10,000 location range, you do have some bits to make some hierarchy. I think having a flat structure doesn't seem to be a problem to me, perhaps better explaining to the community how this is ‑‑ why you actually need all this structure.

SANDER STEFFAN: I think Matthew's e‑mail gave some good examples. So, he for example said inside in you have the different security zones, different security levels, so it's not just the physical hierarchy, it's also the security hierarchy. It's different locations, it's all those things ‑‑

AUDIENCE SPEAKER: But you do have some space for hierarchy. I'm just wondering why do you need as much hierarchy as possible?

GERT DÖRING: I think that's actually one that we might want to discuss more on the mailing list to basically give a bit more background on things. Well, as the proposer, the onus is on you to convince us that we want to go there. So, if people are sceptical, help us understand.

AUDIENCE SPEAKER: Perhaps I can support the understanding. At that SHA, for German Government, the German Government really supports this proposal, and if you look on the mailing list, the Spain guys also and the guy I work in Switzerland for is also support this. I would like to go a little bit higher and look up on what's happening there, why is this mess there? And with IPv6, something changed, something basically changed. With IPv6, some organisations, large organisations like countries, like big companies, thought okay, it's a good idea to have your own addresses, and then there was a split made. With IPv4 you mainly had address providers which had ‑‑ which are also network providers, and with IPv6, you have now the situation that a huge company's countries becoming address providers but without their own infrastructure. So, the count of users and infrastructure is senseless because they don't have any, they only have a hierarchy, they have an organisation, and they want to provide their own addresses to them, but this is a change in the situation and the motivation to provide addresses, they don't have your own infrastructure, you want to provide it for your organisation regardless of the provider who implements it. This is really important to understand the needs.

And another thing is in the actual policy at the beginning, there is written, this policy has the aim to be fair to every user of the Internet, and big companies and countries are also legitimate users of the Internet. So, from my perspective, it has to be fair for them too, and they simply have different requirements and different motivations to organise their IPv6 address space and hierarchy, and we have a constitution where several organisation parts are completely independent, we can't force them to do something, so they have to be able to act independently, for example, announce their address space and have it worldwide routable and therefore it has to be changed this Address Policy. But the question now is: Should we list all the possible sense making criteria, and perhaps this list would be about 100, does it make sense to list all this little stuff or should we trust into RIPE NCC that they are able to validate it in a good way? This is up to the community. I would trust in RIPE NCC. And perhaps another alternative is not to state the criterias which are positive, perhaps it is another alternative to state the things which are excluded which are not reasonable to justify address space requests

GERT DÖRING: I see Benedikt standing in line but I actually want to take the opportunity, sinceed to brought it up to play the ball to Andrea and maybe mark /OEFPLT how much guidance do you need? Do you think you could reasonably work with this policy proposal or is it too loose, so you have no real expectation what the community wants?

MARCO SCHMIDT: If this proposal would be accepted in its current state, what would left is that an organisation has to provide documentation that reasonably justifies the request. That's it.

GERT DÖRING: Is that good enough for you?

MARCO SCHMIDT: Well, Andrea outlined in his presentation, we have received a number of requests, we also have a dedicated team of IPAs that work with this, so we have built‑up some experience. We also have some ideas what we see, think that is reasonable, but of course we would also welcome some guidance from the RIPE community especially about the main topics like as I say hierarchy level of the period that should be taken into account. Also, to strengthen this proposal and that the in effect proposal can take it into account, because we might think that let's say ten years is reasonable, somebody else might think something else, and if it's just left up to us, there is the risk for some discussion, so we would definitely welcome any guidance before doing the discussion phase than now, so also the proposer can implement it in another version and that we can base or Impact Analysis on that. So we have some experience, we think what is reasonable, but we ask the community also to speak up and help us how many bits per hierarchy, how many years they think is reasonable.

GERT DÖRING: Okay. Thank you. Benedikt.

BENEDIKT STOCKEBRAND: There is something you want to be aware of. A lot of people are not that comfortable doing IPv6 address plans, and what I have seen in one ‑‑ I have seen it in several trainings that people first try to save addresses like they have been used with IPv4 and within minutes, I mean literally minutes, they switch towards okay, we have basically got infinite address space and they start putting things in there that don't belong there. This is a quote, it's not funny, we have a /8 for IPv4, I don't see any reason why we can't have a /8 for IPv6 as well. So the point here is, if we go for this flexibility, which I think is a good move in general, we want to be really careful that people who don't really yet know what they are doing start to allocate or request addresses beyond any sense. And that means there will be some work involved for whoever checks the requests, and we might probably need some sort of guidance for people to do proper address planning so we can avoid these sorts of situations

GERT DÖRING: I think that's good feedback. Last comment from Todd.

TODD: I just want to reply to Benedikt. Big organisations like Ministry of Defence in UK and the Government LIRs I support, we made address requests that took about a year of effort. So, I assume every big organisation which pays for this effort, made up their mind about it and don't just make something that doesn't make sense.

SANDER STEFFANN: Well, IPv6 is still for a lot of organisations very new, so I think we shouldn't assume that an organisation, because they spent a year on it, they did it the right way. So, we have to be a bit careful there. This is not just a policy for you, but for the whole community, so...

GERT DÖRING: Let's wrap it up, because we are running out of time. I think we have heard a number of comments that basically, there are voice that is really think we should loosen up the initial allocation policy, but at the same time, some more guidance would be good, maybe even guidance to the requesters on what models are ‑‑ might not be such a good idea, might be. So we'll see what happens on the mailing list, and at the end, as usual, the Working Group Chairs will work with the proposers to distil this into some text that will then go into the Impact Analysis. So we have something formal for the NCC to comment on. And then we will go to the review phase. But this is definitely, it has enough backing to go forward, caveats have been pointed out. Deaggregation certainly is something we need to be careful about. I have heard I willage and I can share that sentiment. It's a global Internet, so, yeah, be careful what you wish for.

Alexander, thanks for virtually being with us here and the discussion will going on the on the mailing list.

(Applause)

I will actually jump around in the agenda a little bit more. And jump to that one. The idea was to have James Kennedy up here, and present, but he said he lost his voice and doesn't feel like standing in front of people and having no voice. So, I'm just giving a quick run down of the proposal.

James, are you here? If yes, please wave... if you don't feel well, no use in straining.

Could I have James' presentation? I have not seen this yet, so please bear with me if I have no idea what I'm talking about. On the other hand, this is a proposal where I don't really expect a big discussion because that is absolutely record breaking. It was put on the mailing list and I think on the first day, we had more voices of support than in total for any other proposal before. So... and nobody said, no cannot have that, so, yeah...

If it's just me, I would jump to last call right away, but we have to go through the formal proposal.

This is what the current policy says, if you have a PI assignment and become an LIR later, want your PA block, you have to return your PI, which is there because we want to encourage aggregation, keep the routing tables small. But it actually keeps people from properly growing into v6 because they say renumbering this is close to impossible, we actually have deployed v6 now so you are forcing us to do it all again. So... this is not working out really well.

So, the argument brought forward was that this is just harming and not furthering v6 deployment, and cannot do everything with PI that you want, so you want PA space to number your customers, you have already independent space which is getting in the way, so, people are stuck.

As far as routing table size goes, the argument is that it's at the maximum 1, 700 PI prefixes that could end up in the routing table, and be removed otherwise. But that seems to be like a value as an upper bound, which is manageable.

So, basically, the proposal is to just remove that sentence. So it doesn't matter if you are an LIR first before ‑‑ yeah, now I get what this slide is trying to tell us.

If you are an open LIR, get an allocation, then say for routing reasons I need a provider independent block to number my infrastructure, you can have both a PA and a PI block. If you have the provider independent space first, become an LIR, want your allocation, you actually have to return the /P PI to apply for it later on. So this is sort of like loose ends that don't really match up so the proposal is just to remove that sentence that you have to return your independent assignment when becoming an LIR.

And there was enormous amount of support on the mailing list. I willage please.

AUDIENCE SPEAKER: Wilhelm from Benamagin, as you know I'm a proponent of small routing tables but let's not worry about things too much, also because sometimes you can have a rule, but the rule doesn't really affect the real world, so maybe someone from the NCC can comment on how many PI prefixes have been returned under this rule so far?

MARCO SCHMIDT: Luckily I just asked this questioning of my colleagues yesterday, it's around 50 PI that have been returned, I haven't checked the detail of it, sometimes LIR that closed that it was really because getting an IPv6 allocation but it was around that number.

AUDIENCE SPEAKER: How many actually...

MARCO SCHMIDT: In the presentation I heard James said we have right now around 1,700 IPv6 PI assignments of organisations that are not LIR yet, so, theoretically, it's 1,0007 hundred PI assignments holders could become LIR and would need to return them.

AUDIENCE SPEAKER: I was wondering about how many already did become LIR and did return because I will be happy to bet that it's only a small fraction because it's just way too hard, it costs way too much money to re‑number and nobody it going to bother in practice anyway.

GERT DÖRING: These PI holders might be just happy being a PI holder and have never an intention of becoming an LIR. So just some do business without being an LIR.

So, I think with that, I'm not going to spend more time on this because we are running a bit short. People are really happy about this proposal from what I see on the mailing list, so, yeah, thanks to James wherever he is, get well again, and we jump to Enno now. That was the first thing on the agenda actually.

Actually, it's covering the same thing as the 2015‑03 proposal, which was very large organisations having issues with well addressing, routing, things, so, giving us more background to actually make educated decisions.



Enno Rey: Thank you, Gert, and thanks to the chairs for inviting foe for this one. My name is Enno Rey, I have a technical background in provider operations in the 90's, I am on the other side of things to some degree in the interim, which means I'm mostly involved in security and network security stuff in large organisations. And my goal today is to give a bit of perspective what I see, what kind of discussions I see in that type of organisation. And how those might influence their decisions when it comes to becoming an RIR members or RIPE members or applying for an allocation and all these things.

Actually I am going to cover three main topics, that is what I call and generally called out of reach announcements. Those out of reach announcements and their role might have an influence on the decision of certain types of organisation for their RIR memberships, and I have some slides, but those slides are not relevant for the majority of you, so, I will skip them on what are the specifics or pitfalls when it comes to applying for membership at certain RIRs.

We should keep in mind that I think there is two main categories of LIRs in RIPE space in the interim that is say traditional ISP LIRs and in the last years, a new group has emerged that I call the enterprise LIRs. And funnily, I was actually ‑‑ when Alexander gave the presentation on their proposal, I was a bit of, like, smiling as I know all these types of discussions, and just keep in mind let's say these two groups, and I'm, like, today representative of the second group of the enterprise LIRs. I don't really judge on things, I just want to provide inside how they feel and how they act on this.

What we see, and the organisations where I'm involved in IPv6 planning and deployment efforts is pretty much all of them, all large organisations that I know and mainly in Germany where I work, have become a RIPE member in the last years, just to avoid all the hassle involved with applying for a PI assignment, for the sponsoring LIR there is a lot of paperwork involved. There might be discussions if this is, like, legitimate as a kind of end user organisation, or as it was called in the earlier days, to become an LIR, but let's just face the fact, they have all done this. None of them was interested in, like, going through the PI efforts and hassle and actually the cost might even be higher than becoming an LIR.

So let's take it as as a giving that they do so and there are a huge number of them, and to be honest, I don't have the impression that the RIRs are particularly unhappy Working Group this. I mean it's new members, and these members bring in money and importance and weight and whatever. So, while usually Address Policy Working Group is mostly about prescriptive, policy matters, what I'm going to do right now is to give descriptive impression of what is out there. What are other region announcements or use?

To define them it's pretty simple. Look at this picture, and then think about it, once address space an an allocation is requested in the jurisdiction of one RIR, and that space is actually used, where used means not like use it internally but propagate it routingwise in the jurisdiction of another RIR, this is called, or this is what I call and other people call out‑of‑region use. And this is two main reasons for this. When it comes to IPv4 space, a major reason might be, there is policies or there is like initiatives trying to prevent this, but a reason might be an organisation which can't get address space in their own jurisdiction just shows up at RIR and gets space there which then at the end of the day is going to be used in another part of the world.

When it comes to IPv6, there is mainly technical requirements, think about such an organisation that Alexander laid out. Retail organisation, they have like as you say said, 10 K sites, somewhere in those sites are not necessarily connected by one consistent backbone network but many of those sites might have their own Internet uplinks in country and region, and now if they want to use a consistent addressing scheme within their organisation with global addresses as opposed to like RFC 1918, addresses in IPv4, and they want ‑‑ they don't want to use NAT, it means announce, like ‑‑ I will be scared about this ‑‑ announce a high number of specifics, more specifics in some part of the world where the subsidiaries actually sit. So there is, I can tell you mean of the organisations they think about doing exactly this.

What can go wrong? I mean from an RIR's perspective ‑‑

GERT DÖRING: If you say high number, are you talking about one per country? One per city? One per office? One per office would definitely scare people. One per country, one per region is actually not as bad.

Enno Rey: It's probably one per site. If it's 10k sites it's 10k announcements. I would say, I mean, the example that Alexander gave that 10k is a huge number. But say a typical organisation like a manufacturing or automotive or so, they have several hundred sites worldwide and this is what they usual, or what I think about is what they call a local Internet break outs. So I would say several hundreds, that's what the space where I work would be seeing.

So, what could go wrong with those out of reach announcements from an RIR's perspective? Address space is poaching, like people from one region showing up in another region, they can't get spare in their own and apply to another RIR. From ISP perspective, always leave the stuff that like I willage mentioned in the sense of many, more (I will /WAPBLG) cluttering of routing tables which is even more bad maybe, if it's not just within a region, but these are other regions, like more specifics from, like, some part of the career a, cluttering in the routing table in Munich in space net, just to give you an example, and from an enterprise perspective they are wait a second, this is clause routability not guaranteed? Will it work at all? If we strife for such an approach, be it good or bad from your perspective here in the room, will it work technically? Especially keeping in mind some of you might know that in London at the RIPE 69, I did the Routing Working Group I gave a presentation with research data we had from the routing information service on the filtering of /48s, more specifics from LIR space, and actually it happens it's not much, but still it happens, so it gives this bad feeling to the enterprise organisations, well, if there is ISPs out there doing this, what I personally think is not a good idea but this is just me, a silly thing of a prefix filtering, this might even be worse strict prefix filtering if we announce part of our RIPE address space in Uruguay, Korea wherever. So the question is actually, will it be routed? This is what RIPE see in many discussions in many enterprise LIRs right now. If we do this, can we use the address space in other parts of the world? Which then, again, I mean the question, or the answer is: Well, who knows? It depends.

There might be two sauceers for a response to this question, will be routers: There could be what's guidance from an RIR's perspective? Is there any policies on this and what is the actual reality happening out there? And when it comes to the RIRs, some like, positions, policies, just to give you a quick overview. ARIN, they had a policy proposal which was just recently abandoned by the Advisory Council. To the best of my knowledge in RIPE NCC, there is some statements here and there, but there is no really like official position on out of reach in use. I would give a quote from Andrea in a second. APNIC and LACNIC, I couldn't identify anything and AfriNIC, they have a policy proposal which is very much orientated towards the one from ARIN.

ARIN, in ARIN's proposal, which was again, it was abandoned three weeks ago, the intent was like, okay, if an organisation wants to do this, they still have to prove that a certain part of the allocation they applied for is used within region. When it comes to RIPE NCC, Andrea gave a statement during the discussion in the ARIN policy mailing list, which I highlighted the main part in red, which is, well, we don't really care like, or we don't really prescribe or policies on this it's just we expect a member organisation to have at least one active network element within region. So there is not much from that angle, like, which could answer the question will this work or not.

When it comes to actual reality, I discussed it with some of my old bodies in ISP space, they said we don't see this very much, we can't really ‑‑ I mean it's difficult to say whether it's from an AS number, where it actually originated, you could dive into this, but we don't see vouch of this. There is some, in some discussions, there's always like Cisco does it, but again, looking at routing tables, you don't really know where they announce the space and how much of that is actually announced out of region.

So from that angle one can't really answer the question of the enterprise organisations, will this work.

So, to quickly summarise this: There might be organisations who want to go this path for whatever reason. It's not really clear if this will work from a governance or from a technical level, which then means that most organisations again that I'm involved in, they follow the path of applying for RIR membership at several RIRs. I can give you at least five names of the like 30 German largest organisations which have ‑‑ which are in the interim RIPE members, APNIC members and ARIN members, and all of those, they have, again, this will scare some people here in the room and it might rightfully do so, scare them, they apply for the routing space and they plan to use it in some way in the future which is not really clear right now.

So, it's actually, this has thinking about this and not having a definite answer leads to certain consequences as for the actual actions of organisations out there.

I have put together some slides what are the specifics in relation to applying those, I will mostly skip them as they are not relevant for most of you here in the room right now.

Just one thing, given I have been involved in many of these procedures and pretty much all of them, I haven't done AfriNIC, I have down all the others several times. The crucial point is about payment. Getting the fees paid by corporate people recollect that is the actual difficult part. Again, I will skip all this and jump right to my last slide here.

Which actually ‑‑ I mean the conclusion is getting, I expect to see a growing number of out of region announcement for whatever reason, it might be an IPv4 space, it might be an IPv6 reason there might be certain reasons like the ones that Alexander and Taha laid out.

I would like to ask a question instead of giving a definite conclusion on this. Do people here in the room, do you, do we as a community expect this to be a problem in the future? And if so, how would we tackle this? And, well... we might even ask if Address Policy is the right place to tackle this or if this should be discussed in the Routing Working Group group? These are the questions I would like to discuss. Thanks for your attention.

(Applause)

GERT DÖRING: Thanks for bringing the background from a different user community basically. Of course the easy way out for this community is just to point at the Routing Working Group and say, oh, it's their issue to solve, but it tackles, as we have seen in the policy proposal from Andrew, from Matthew and from Alexander that it's actually touching on Address Policy, so, it's good to have background information to make educated decisions. Welcome. I haven't seen who was first.

ERIK BAIS: So what I found interesting in the whole presentation that you gave is that the networks of those companies and specifically to their locations, they are not interlinked. So basically, they are assigning a portion of the acquired allocated space, and assigning it to a location and just announcing there as if it was PI space. So basically my question at that point is, why not use the space from the ISP that you have at that location and basically request them to basically provide you with the ISP space that you have? In that case, the ISP locally can actually do the deaggregation and if it's basically because somebody is too lazy to do their own firewall policy because this is very easy to just do, you know, a /28 in a firewall, to actually do the whole management, I think he has different issues, because that won't work. So, if the networks and the locations are not interlinked, why go this route? Because I'll filter the /48s or smaller, whatever you try to announce, for any prefix which basically comes from a 32 or larger. Ray an I'd like to just answer this in several steps.

ENNO REY: First of all, usually the networks are interlinked, they are like a global MPLS backbone, or MPLS network, not a backbone, but for, like, say bandwidth, saving costs whatever, they still ‑‑ I mean, this local Internet break out thing, there is organisations which call this public Internet off loading, so they are actually not fully independent those sides, but still there is like reasons why they decide to go with ‑‑ have a local proxy and to just put all the HTTP Andrea HTPS traffic from the local link, whereas there is still this global inter‑connection so, from a technical perspective, we have this. On the other hand, please consider I am just liking ‑‑ speaking as a representative observing certain trends. I can assure you that those, like Taha did, these are very large organisations for network teams who mostly know what they are doing. So, I would be cautious like qualifying okay these guys have no clue what they do and they shouldn't do it this way. I am just observing a certain trend and as for the last one that you mentioned, filtering every /48, or filtering 48s which come from an allocated /32 space, this brings us to the very fierce debate of strict filtering ‑‑

ERIK BAIS: It's not a debate. It's actually best practice.

ENNO REY: It's not.

ERIK BAIS: We'll disagree on that.

ENNO REY: I mean I gave a presentation at the RIPE 69 on the actual research data, how many organisations still filter on /48s, and we looked at data from five IXs throughout Europe. I can tell you, I did ‑‑ we collect this data once a quarter. On the 1st January 2015, this year, there was, when it comes to /48s, announced for the first time the number of /48s announced without a covering aggregate was bigger than the number of /48s with a covering aggregate, all from PA space, I'm not talking about PI, initial allocation policy not talking about 2001, 6, 7 and 8. So there is a growing trend towards not doing strict filtering out there and as Randy Bush would call it, if the market decides, the customer is paying for providers transporting the traffic, so I think strict filtering will go away, but we'll agree to disagree on this, so...

GERT DÖRING: Let me just inject something that you explained to me, but didn't explain to the group. Very easy example. Like you have this global multinational company that has their own backbone and they have Europe and the US. They want to offload the traffic to their peers in the region where they are, so they have a big Internet pipe in the US, a big Internet pipe in Europe, but these are not ISPs, so they don't ‑‑ for the ISPs it doesn't matter where the packet is coming back. For an enterprise there is a state identify wall so you have ensure the packet is coming back where you send it out. Given the Internet is what it is, the only way to enforce packets you send out at the US link to actually come back at the US, is to have a more specific being announced in the US and a more specific announced in Europe. So, if they insist on having multiple inter‑connection points as having stateful firewalls, some tradeoff has to be made. Just, explaining a bit more background ‑‑ that's technology as we have it today. I'm just explaining why this is coming up. Okay, you might explain to us how to do it? Awed

Enno Rey: I can only state that as I said the number of more specifics without covering, from January this year, for the first time exceeded ‑‑ this is like research data.

AUDIENCE SPEAKER: Sorry, I willage again, a quick point regarding the a symmetric routing and the firewall F you put one firewall in Europe and one in the US and you expect all the traffic that you receive in Europe and go through the firewall first and then Transatlantic, then you have made an insane network design and we at RIPE shouldn't consider those people.

GERT DÖRING: It's the other way around. I have a 29, a use 32 of that for American network a 32 for the European network, I expect traffic I send from the American network to the American Internet to really come back in America and not have the response packets come in in Europe, because somebody else's routing policy says Europe is much better.

AUDIENCE SPEAKER: This is the Internet, it happens

GERT DÖRING: Yeah, but ‑‑ well, do we want to have people to use IPv6 or do we want to have them use NAT? With NAT you can get around all this easily. There's a tradeoff to be made. I'm not saying what is right. I'm saying that there is no perfect solution today. And David has been standing there patiently for too long.

AUDIENCE SPEAKER: Hi, David from Microsoft. This is very good, thank you. My experiences completely mirror what you have said. So you do you consider this a problem? The only thing I found in your presentation that's a problem is that organisations feel the need to go to multiple RIRs for their IPv6 needs. As an operator who operates in all five RIRs, one of the things I respect and like most about the way the RIPE Address Policy Working Group group has developed over the years is an authority of liberalness that says let's just give the numbers where they're needed whereas little crap as possible, and I would love for this Working Group to say very strongly to the world and to the NCC that if you are based in Europe and you need IPv6, you come to us and you can use it wherever your network takes you. That's very important. Thank you

GERT DÖRING: I thought we do that.

AUDIENCE SPEAKER: Milton Miller, ARIN advisory counsel in Syracuse University, for a few more months anyway. I was very pleased with the presentation because we did indeed go through a very tins debate about the out of region use policy. I was a Shepard for that policy an we went through several iterations of it and in effect, we didn't really abandon it, I mean we did abandon that specific policy, but there was a significant amount of support for the idea of the policy. But we discovered we were bumping into high level principal disagreements about what RIRs should be doing and that those issues maybe should be discussed in a broader context, so, what you did was you set the stage for something I wanted to do here anyway, which is raise the issue of whether the number space is in fact global and RIRs are facilitators of linguistic differences and geographic distance are they facilitators of the distribution addresses or do we conceive of RIRs as territorially exclusive distributors of resources and you have to go to each one of them and the usage is supposed to be somehow conformant to the so‑called jurisdiction of these RIRs? And we are not being to resolve that issue, but one of the issues that you didn't mention that came up in our discussion was the so‑called ICP 1, which is an ICANN statement of policy about criteria for the establishment of new RIRs. We were told by some of our staff members, incorrectly I believe, but we were told this very, very mental that the out of region use policy conflicted with ICP 1, (vehemently) in other words, if ICP says a few words about if you create a new RIR it shouldn't overlap with an existing one, that we're moving towards a model of territorially exclusive RIRs. But if you read, you know, what ICP 1 actually says it was really created to facilitate AfriNIC and establish some general criteria for when you would want to establish new RIRs.

So, I think the community has to have a broader discussion about the reason for the regionalness of RIRs, and whether the number space is global, whether we want to facilitate global use of addresses or not, and I hope that you have helped to stimulate this discussion.

SANDER STEFFANN: I think one thing is very simple, complete territorial exclusiveness cannot exist because networks do not stop at borders, so, it can never be absolute.

AUDIENCE SPEAKER: Well, one of the impetus for one of the failed policy efforts in this area came from law enforcement agencies in the US that would very much like for addresses to be territorial and to map to jurisdictions, and you know, if you are going to do that as one person in our debate said, why not just have NIRs instead of RIRs, so, that's another consideration.

AUDIENCE SPEAKER: Jenna, just a network engineer. I could not get my head around the idea of a regional use of IP address as /TKPWHROEFPBLT my backbone is global. I can't understand how can I limit the usage of address space to a particular geographic region, you said network does not stop at borders, and Internet work like at that way, is it the only way for a network to do traffic engineering can ensure that I receive traffic through the link I want is to advertise more specific sometimes. I that it might be evil, in some cases here you deaggregate, but sometimes the only way you can do if you want to be homed, and use your own address space, so, I think as soon as we apply some common sense, I think that's okay, that's not a problem, right, a big problem at least. We do see this in v4 and we IPv6 it's in reverse because people don't want to use NAT so cannot do this crazy policy based routing using ‑‑ newer network through different address space. You want to use your v6 address space and advertise it in many allocations, so, I cannot see why it's a problem why we are even talking about out of region use. Neither is one big thing

GERT DÖRING: Thank you. Three for quick comments please, because we have two more agenda items and otherwise it will all be your lunch break.

AUDIENCE SPEAKER: My name is Thomas Smith, I'm from Continental, an automotive supplier and we are exactly such a global acting enterprise and I am LIR in ARIN, epic and RIPE and exactly for the same reasons Enno pointed out and of course we have an internal MPLS backbone and act as an ISP internally but we have also all kinds of Internet access, sometimes because it's faster to gain access via the Internet than become owner of a leased line, and we have also some failover requirements that we have sometimes output in the States and the income again in Europe or epic.

So, I fully agree that the community should face these questions and focus a little bit more on enterprises which not acting as a normal ISP carrier

GERT DÖRING: But actually, it's ‑‑ well the own onus is not just on us, it's on you as well to teach us on what you do and what you need. So, this is very good to haven owe here, it's good to have you here to actually speak up and state your issues.

We tend to use things, look at things through an ISP perspective, because well, at least me, that's what I have been doing for 20 years, so, I don't know all the other sides, it's good to have you bring it up. Please keep doing so. Hans Petter. Hold hold I seem to remember we had this discussion sometimes in the nineties, it wasn't v6 then but it was kind of the same discussion, and the consensus here then, which was not shared with our colleagues from the other side of the Atlantic, is the IP addresses you get them from RIPE and you can pretty much use them in your network wherever that is. So if you build a global network you are more than happy to come here and get your addresses for that network. On the networking plan, well it's many years since I did a hands on networking or planning, but this seems to be exactly the same things that I was dealing with back then, large corporation makes a huge, nice, pretty internal addressing plan, and then figure out that oh, we should have made this according to our network topology and not according to our org chart, because they end up with having three or four islands which are not connected internally anyway and then you need to redo your plan. And I mean I have done this too many times that my grand plan of the universe lasted half a year. So, I don't think there is any one size fits all, and there is a lot of experience here from past mistakes. So, maybe some of that can be taken into account here.

AUDIENCE SPEAKER: Hi, my name is.....and my comment is really more when a large corporation, we have about 70 people, but I do facing this problem outreaching with IPv4, so, basically it's having a debate in almost every continent about if it's right to use IP address out of the region. And it was said two opinions, my peers would support it when, it's one global network, so we shouldn't have a problem of using IP address anywhere really, but because in consequence of v4, number 2, there is different exhaustions in having one continent and the other continent. So, I believe at this point in time, we have opportunity to make things right at this time to make v6 truly global, so because it's infinite, number two there is to treating value in v6 at least in the foreseeable future. So, I think I think we can at least at this time for v6 would allow people to use it everywhere, anywhere they wanted as long as there is a network need, and that will, you know, to get rid of the hassle we had with out of reach user with v4 for past many years. Thank you

GERT DÖRING: Thank you. Sorry for cutting the discussion a bit short. But we are cutting into Erik's time actually. So, give an applause to Enno for actually starting the discussion.

(Applause)

Please keep bringing back issues that affect you, because you feel unrepresented, whatever. We might not just not know about it. Erik brought a new, well he promised last time to bring a unified transfer policy, and we are taking him on his word, so, here he is.

ERIK BAIS: So basically, the reason why I stand here was not because I was so kind to actually say I'll clean this up, the actual reason was basically I make the mess and now you clean it up.

So, what I'm going to do here is, we have a draft for the documents. Marco and I discussed it, and said, well, let's go through the Working Group first, display a bit what is going on, what we're planning to do, what we hope to achieve and basically from there, create a draft in the next two weeks and propose it to the mailing list.

So currently we have on ‑‑ in the various documents, policy documents, we have transfer texts which relates to transfer of number resources in various different documents. There are transfer texts for IPv4 PA, PI, AS numbers, IPv6, and you know, there are specific text about inter‑RIR transfers, and basically, if somebody actually wants to do you know which basically applies to whatever I need, you know, you need to look up four, five, six different documents. And a lot of the text is redundant, I'm guilty for most of that. And the reason why I did that is by creating the other options and actually getting the same text in the policy, will make it easier at this point where we are currently where all the policies are actually accepted to actually consolidate the whole thing and actually in a single document.

So, it's a full mess, I know, sore are arey, mea culpa.

So... basically, we're ‑‑ these are the documents that I found basically where we are say you know this is where all the documents are with the specific text in there.

And if we go looking to the actual drafts, there is some flavour text here. You know, skipping the introduction, it says "Any legitimate resource holder is allowed to transfer complete or partial blocks of address space or number resource that were previously allocated or assigned to them by the RIPE NCC or otherwise through the RIR system.

Resources may only be transferred to another resource holder who is also a member of an RIR that allows transfers.

So, to get some input, maybe not everybody at this point at the mike, but at least I would like to get some input on this. It specifically says "a member." Here, now that might actually work if we look at inter‑RIR specifics, because you know, members in other RIRs might actually have a different meaning as what we have here with PI pace and direct assignments. So, there is some words Smithing that we need to do which will make sure that it will actually envision and basically grab everything that we want.

There is several different policies that says basically, you know, you can do a temporarily transfer or a permanent transfer and one of the things that I'm actually moving into this document is, as you can see, here in the document it says: "Reallocations, reassignments, reassignments, transfers,"and basically to generalise the whole thing, the suggestion here is to basically say transfers must be reflected in the RIPE database, this transfer may be on either a permanent or a non‑permanent base. So basically, that will envision everything.

Transfer policy restrictions: Now we already had a very nice debate on this this morning, there are some differents in here. There is actually something that I would like to alter as the actual change that this unified transfer document might actually give, and I would like to have some feedback on this.

During the policy discussions for IPv6 and AS numbers, somebody actually noticed that I removed the actual transfer policy restriction because you know, it's v6, why have a 24 month waiting period on it? And then somebody said well you know, it's also not in the AS numbers. I said good catch indeed. But ‑‑ and the general consensus was, all right, proceed but basically have a look at doing this for the 24 month waiting period, you know, before you actually retransfer that for the 16‑bit AS numbers, but you know, skip it for the 32 bits.

So, that was actually how the actual discussion went last RIPE meeting, and basically, the proposal that I want to do for generalisation is a 24 month waiting period for the pleaded resources and we need to define how to say that or how to do that (depleted) but the go is, PA pour, parks IPv416‑bit /SA*S numbers, general lies them as the depleted or almost depleted resources after receiving of the resource. And that means that this will include any IP address you get regardless how you got it, through mmm A, through new allocations from RIPE as a new LIR or through a transfer or through an inter‑RIR transfer, which basically means I don't care how you got it, but if you get you keep it for 247 months before you can retransfer it.

STEPHANE BORTZMEYER: So this is a fundamental change, because this is actually one of the first times that we actually, in a transfer policy include N MAs. (MNAs) so we need to have a check with the RIPE NCC, can we actually put it in this (nothing coming up here) and this needs to be in the actual ‑‑ Impact Analysis, can we actually you know, write it as such and still have companies that want to do a merger and acquisition, that they'd still be able to do it because that's the intent that people will still do MNAs, however, they should be able to do an MNA and not transfer after it, because that's the intention we are trying to achieve here.

So, inter‑RIR, I have asked Sandra to make sure that once we have the drafts of the policy, basically look into this, make sure we didn't miss anything, and basically I just complete the whole thing from the inter‑RIR, I hope I didn't miss anything, I'll work with Sandra to make sure that that is actually included here perfectly.

Therefore statistics. There are actually transfer statistics listed in all the transfer policies. We may need to do some wordsmithing for the AS number resources on you know how those things are being presented in this generalised document. Basically it means that you know if there is a transfer from a resource, you know, it will be published on the website, Marco and I will work on that specifically to make sure it actually covers everything.

And then we have some final remarks, basically, you know, that's in most of the transfer, or the current transfer things, that you will find in the documents. There are some final notes about that the actual current legitimate resource holder is still responsible during the entire process of the transfer. Transferred resources are in no way different than the allocated, allocations made directly by RIPE and basically RIPE will record all the changes after the transfer.

So, after the, this whole initial discussion, please let me know are there any things that we missed? Basically we need to know exactly are we on the right track? They are not big changes here. There are some, I pointed them out and would like to have some feedback on what you think of it and if not, we'll ‑‑ Marco and I will start working on this and we expect to have the first one to the list in two to three weeks.

GERT DÖRING: Apologies to you and the Working Group for my bad time management, we should have time for a bit of discussion on this, but we don't, we actually have another one up for discussion on that.

So I'm taking a short‑cut. I state that I like the approach you do, and I put the phrase to the room, if there's something in there that you absolutely cannot live with, let us know right away. Otherwise, we will have enough time for discussion on this on the mailing list anyway, because the final text goes to the list. But it's the ideas, if there is something in an idea that you think is completely absolutely unacceptable, let us know now, because it will save time. So, with that said, nobody coming to the microphone ‑‑

ERIK BAIS: Can we declare consensus then?

GERT DÖRING: No, we don't have consensus, I think the chairs can give you have guidance to continue this on the mailing list. Thank you for your work in preparing for this, and again apologies for my bad time management. We do have a discussion item from Elvis here, who proposes to extent the size of the /22, so please... you have three minutes for the presentation, and then I will formally leave people to go to lunch or stay here to discuss, whatever they want, but our time is over in three minutes. So, again, my fault, apologies, I should have cut the discussion a bit shorter but it ‑‑ the other discussions were important as well, so ‑‑

ELVIS VELEA: Hi everyone, Elvis again, I have Radu here with me. Basically this is somehow an open policy discussion. During the discussions of 2015‑01, I have seen that a lot of people are talking about running out the /8 pool faster. Now, that's not the reason why we're here. The reason why we're here is because we have noticed that the last /8 pool has become the last /8 and a bit after three years of running it, so, we have noticed that everything that is in the last /8 pool now, it's actually not depleting or not being used as fast as either space is coming back to the RIPE NCC pool on one side. On the err side, we have seen quite a few signals on e‑mails, and I have also talked to lots of customers, people that are saying that the last /22 is not big enough but they would be very happy with a bit more. So, that's all from me. I'll give the mike to Radu, who has actually wrapped up three slides and if we still have time we will talk a bit about it.

RADU‑ADRIAN FEURDEAN: I'm Radu, so the main idea is ‑‑ okay. So, the main idea is to revisit a little bit the allocation from the last /8, so, that would mean change the allocation size. On one hand, there are companies that became LIRs just in order to get one /24 that that he need to announce to different ISPs, and since they can no longer get PI space, they choose to become LIR and get an allocation.

Sometimes it's more than what they need. Another idea is to Ryan state some form of need base I will come to this later, I can't provide you the details because it seems to be a very complicated and controversial issue, when I say need base, I don't mean as much as you have need. I just mean validated somehow that you do need some space. And well the question is: If you allocate less than a /22, how do we handle everything? But this is more an NCC stuff.

On the other hand, it's all that's seeing is the last /8, which is a bigger ‑‑ which is today bigger than a /8, so this is the status of what we have in the RIPE region and in the other regions, as you can see, RIPE is, I can say it's the more, the most rigid region where you just have one /22, no more, no less, and that's all. Everywhere else, there is some flexibility.

And now, coming back to the issue of changing the allocation size, there is also the idea of having the possibility to offer more than one /22. Probably separating pool 185 and the recovered address pool, maybe, probably. Going in several steps, so, like in LACNIC area, so you get one first /22, and sometime later, probably two years, in order to keep things in sync with the other policies, you can get another /22 if there is more space in two years. And well at some conditions, do we give the second /22 to everybody? Do we just give it to small players? Do we put restrictions so we don't give a second /22 to somebody who did an out bound transfer? And probably do an old‑fashioned audit of the address space to verify one more time that yes, you do need this second one, this second one is just a premium allocation. And there was some ‑‑ there were some thoughts about why do we need a second allocation, because well all that stuff was deploying IPv6 is nice, but it's not the way it works in real life. Customers barely care about IPv6, so you have to give them some IPv4. There are some ‑‑ there are some situations where no IPv4, no customer point. There are situations where cannot do CGM especially in corporate markets when you sell to enterprises, you can't always afford to do a CGN for the customer does it internally, but you can do it for them.

And, well... those are the ideas for the discussion, I suppose it will be ‑‑ you can contact me directly on the mailing list, or in person, I'm here today and tomorrow. And I'm open ‑‑ I wanted to see what was the community's ‑‑ like, what the community thought about those things in order to know how could we advance or not on a possible policy. Thank you.

SANDER STEFFANN: We are already running into lunch. So, are there any strong opinions on this? Anybody who says no, we should definitely keep the last /8 policy as it is, one /22 and that's it? Or are there any strong opinions on ‑‑ we need to loosen it up in some way? Everybody just hungry?

GERT DÖRING: I actually do have an opinion, but I'm not entitled to one. Well, not with the yellow badge, so I'll turn it around again.

I think this will be actually tricky to get right, because well, everybody wants all of it, and we have certain goals, but it's worth discussion in any case.

ERIK BAIS: I think the tricky one is how much is going to be enough, because ‑‑

SANDER STEFFANN: It will never be enough.

ERIK BAIS: This is the problem we cannot fix by just increasing your fix for next month with another /21 or another /22 or in two months or in 12 months or in ‑‑ you know, you need to detox from v4, that's basically what we need to do. And the v4 from the final /8 is for new entrants, not for us. That's it.

SPEAKER: Well, it's not about, it's about easing the pain, because we did a run‑up policy which is painful, as a new entrant, I see it very painful. We are practically throwing people out of the market and besides we are giving a signal that well, IPv4 is not going to be depleted because at the current rate it will take more than ten years to deplete everything. That signal has to be stopped on one hand and if at the same time we can ease the pain of the people who are, who didn't enter the business recently, it may help.

ELVIS VELEA: We do have more than a /8 right now, which is ‑‑ yeah ‑‑ showing that the wrong signals I think. It shows that the NCC is recovering more than it can allocate, and we do have a few thousand new members, okay, some of them might just do it for the money but some of them do really need it, so for those that do really need it, giving them another /22 might actually mean the whole difference. They might not afford to pay it, buy it from the market but they might actually get their business up and running with the second /22, or I don't know, you know, it's just ‑‑ this has ‑‑ there has been so much noise on the mailing list about all of this, about how much is actually in the pool, about some people actually wanting to deplete the pool completely, as soon as possible, and about all kinds of ideas, and actually Radu has actually made a few slides with some really great ideas, and the plan was to discuss it here.

AUDIENCE SPEAKER: I willage /TRE men a.m. One thing seems fairly obvious, if I come to the NCC and say can I please get a /24 and they say no, no, no that's not going to happen, you have to take a /22, I don't think that makes sense, and then the other thing is, it doesn't help if you are going to bring your used car to the scrap yard, or you are going to squash it with a full tank, right, so, how long do you need to, for a final /8 to last? It looks like, at the current rate, it's going to last 15 years, which is probably longer than we need, so I think we can go a bit faster, be a bit more liberal and maybe ‑‑ but I think we need a target, how long do we want to make this last. I think that's the big question.

AUDIENCE SPEAKER: Had you hang. I just have two comments. I'm not completely objecting to the increased double size burning rate. But number two, I totally agree with Erik, what is enough? We have to face a reality that v4 is over and it's just like, the landing, I mean the first come get it cheaper and the later come get it nor expensive and everybody has to face v4 is an expensive cost and if you miss ‑‑ it's for your cost, you can't says because I can't afford it could you carry me 200 megabits of free bandwidth, you can't ask that right, you ‑‑ or you can get sponsor ship somewhere or tell your investors, but I mean from now or from this point on we are very, very early stage of exhaustionnd as from this point on, people should consider IPv4 is a cost and you have to bear this in your mind in your business plan. But of course on the other hand, if the burning rate is slow and I'm not objecting to double it of course. Thank you.

MARCO SCHMIDT: I just want to point out something that you also mentioned in the Impact Analysis, if you look at the burn rate of the last six months, that includes this increasing of /22s transferred, we estimate current will be enough for around five and a half years.

AUDIENCE SPEAKER: I think five and a half years sounds like shorter than the current estimate on how long we still need IPv4 to be running before we are all fully transferred to IPv6. Of course you can move faster. This will probably help some companies now, but it will surely hurt companies that want to start in three or four years and basically can't do anything any more except for starting IPv6, well we all already know that in five or six years, we'll still need IPv4 because IPv6 will just not be fully rolled out at that moment. Erik and I had a discussion last night, where he basically said at least seven or eight years will be the the time that you still need IPv4 here in Europe or around the world, so I don't see a reason why we would hurt people in four or five people just because we have some people that want an early fix now. I'm sorry

RADU‑ADRIAN FEURDEAN: Regarding the burn rate, the current burn rate also includes the abuse we have been talking about earlier, so, I hope this is something that will be dealt with in some way or another. And on the other hand, if we don't end up burning everything, sooner rather than later, everybody will ‑‑ not us ‑‑ everybody else outside the community will say, well, there is still IPv4. You can still get IPv4, you can use NAT, why deploy IPv6? This is why ‑‑ this is how the corporations think. They don't care. They just want something. And IPv4 or NAT for them is enough.

SANDER STEFFANN: I think our homework now is to look at the different scenarios and the different burn rates and make some estimates so we know what numbers we are talking about and what time frames.

AUDIENCE SPEAKER: Just two very quick comments. One, corporation will be four years expensive, now it costs money and if they grow v4 it costs a lot of money compared to v6. Number two, and I think I really like the scenario in this continent rather than in some other continent, which is running out of IPv4 completely. This continent will last IPv4 which the future totally ‑‑ especially in different countries, so we don't know what's going to happen in the next ten years, everybody fails to predict the last ten years at least. So, I think lasting longer is always better than lasting shorter, I mean, even one day we complete v6 ready and we have some v4 ready and, I think that's not really a big problem, right, why we have a problem with that?

SANDER STEFFANN: I think, the microphones are empty now. Thank you guys for the presentation. And for making us think about this. And before everybody runs off, we have a very short 60 second announcement from David. So, please bear with us for a little bit longer.

SPEAKER: David: Really really fast. Some of the largest growing economies in the world are in South America, and as a result, I have authored policy proposal 2015‑02 in the LACNIC region. This is a proposal to introduce an inter‑RIR transfer policy to LACNIC which doesn't exist today. For those of us who operate networks on many continents this makes a lot of sense, v4 is going to be around for a little while we need to move v4 from ARIN or RIPE or APNIC and we need to move it into the LACNIC region where it's being used. Unfortunately the LACNIC region seems to be afraid of this. There is a lot of resistance to this. So, if you operate a network on multiple continents or if you think you might wish to sell connectivity or products or content in the LACNIC region, I strongly ask you to get on the LACNIC Working Group mailing list which is in English, Spanish and Portuguese, register your support. Thank you.

Thank you

GERT DÖRING: With that I close the session. Thanks for your patience for my time management. Next time I will do better and enjoy your lunch and see you in Bucharest. Thank you.



LIVE CAPTIONING BY MARY McKEON RMR, CRR, CBC

DOYLE COURT REPORTERS LTD, DUBLIN, IRELAND.

WWW.DCR.IE.