RIPE 62

Address Policy Working Group Minutes from RIPE 62
Status: Final

Co-Chairs: Gert Doering, Sander Steffann

Scribe: Saloumeh Ghasemi

Session I – 5 May, 09:00 – 10:30

A. Administrative Matters

Gert Doering (co-Chair) opened the session and reminded people that the session is webcast. He presented the agenda. The agenda was shuffled a bit and there were no comments from the audience.

Gert said the minutes from RIPE 61 in Rome were sent to the mailing list and there were no comments. They were approved and are now final.

B. Current Policy Topics – Emilio Madaio, RIPE NCC

The presentation is available for download at:

http://ripe62.ripe.net/presentations/152-CurrPolTop-RIPE62.pdf

There were no questions.

Gert Doering (WG co-Chair) thanked the scribe after the presentation, since he had forgotten to do so earlier.

D. On IPv6 Registration - Marco Hogewoning

Gert Doering explained that Marco Hogewoning had introduced a change to the way IPv6 assignments can and should be documented in the RIPE Database. He mentioned that Marco, as a trainer, had figured out that the registries didn't really understand what that means for them, so he had volunteered to explain the issue.

Marco stated that he worked for the RIPE NCC and also as a Working Group co-Chair. He said that he had also been a proposer of this policy change.

Marco gave a short presentation on the policy change 2010-06 and use of AGGREGATED-BY-LIR.

The presentation is available for download at:

http://ripe62.ripe.net/presentations/159-AGGREGATED-BY-LIR-20110304.pdf

Gert thanked Marco for bringing it up and for having the change in the policy text and the database implementation. He said that the old one was workable but unclear, however the new one is very clear and quite useful.

Marco thanked the community for their support on this proposal. He commented that reaching consensus is much harder than writing a proposal.

Andreas Polyrakis (GRNET) asked if there was a policy to prevent an ISP from registering /56 assignments that it makes to the End Users. He asked if that was considered abuse and if it caused too much information in the database.

Gert Doering (WG co-Chair) replied that it was possible, however if they have residential customers, the data protection laws of the local country may not actually permit them to put the personal information in the database, in that case, having all the /56s is not so useful, therefore the aggregation is preferred . He added if they have business customers and they want their data registered, they can do that.

Marco clarified that the policy text stated that it must be registered, it didn't say they must use this form. He said if they wanted to create all those different assignment objects, they can. He remarked that database object itself was described in ripe-513.

Y. Open Policy Hour

Gert Doering (WG co-Chair) explained that in the open policy hour they only discuss the issues that have come up in the last few days and that it's not yet in the formal machinery of the Policy Development Process. He added that open policy discussions usually go to the last bits of the Address Policy Working Group time, however that was in parallel to EIX and they had shuffled it around and they have agenda item “Y” quite early in the agenda.

New IXPs in a Post Ipv4 world – Andy Davidson, EIX WG chair

Andy Davidson (EIX WG co-Chair) gave a report on the work that the EIX Working Group had done the day before to gather feedback from the Address Policy community and the ideas of the audience before they turn this into a formal policy.

The presentation is available for download at:

http://ripe62.ripe.net/presentations/154-Post-ipv4-ixp.pptx

Remco van Mook (Equinix) supported the idea and referred the audience to a similar discussion held at the ARIN meeting a few weeks back where the subject was discussed but it was folded into the critical infrastructure which was already in ARIN policy but not in RIPE. He emphasised that he supported this proposal and would help push that forward and edit it with the proposer if needed.

Aleksi Suhonen (Axu TM Oy) suggested that ccTLD anycast services might deserve similar special treatment and if it is the case, they could be combined and they may share different sides of the same pool.

Gert Doering responded that he would rather not do that. He said he wouldn't object to having a second policy proposal in the system for ccTLD anycast, however from the experience with previous domain name related addressing policies, this inevitably seemed to cause quite lengthy discussions, however the current issue was sort of a special case, easy understandable and there was no room for misinterpretation, therefore they would keep them separate. He added that it didn't mean they couldn't have the other one, but in case they lump them together, it would cause even more problems in the process.

Aleksi Suhonen (Axu TM Oy) agreed.

Kurtis Lindqvist (Netnod) also supported Andy's idea. He stated that he didn't have any opinion if the IPs should be taken from the last /8 or the existing policy, but according to his observation a /16, with 256 future changes, assuming /24s, was more than twice the number of exchanges that existed in Europe then and three times the number of exchanges have been managed to build in the last few decades and he found it quite a lot. He said he believed the minimum assignment size should be smaller than /24 and it should be justified like all the other spaces. He also commented on ccTLD anycast issue that there was already a policy for the ccTLDs to receive anycast and there was no need for a new one.

James Blessing (Limelight Networks), on chat, supported the proposal and said it should be from the existing address space.

Mohsen Souissi (AFNIC) mentioned that he worked for a TLD and had no problem with EIXs taking this space and that it should go faster and they should go through with the proposal no matter what length it would be. He didn't fully agree with Gert. He clarified that the lengthy discussion was there due to the fact that there had been no agreement on what a critical infrastructure was. He explained that at that stage they had many examples and could define some kind of infrastructure that anycast might be for. He added if TLDs wanted to reserve a space it should be easier than having lengthy discussions. He emphasised that he didn't object to getting this very fast without any connection to any other community asking for the same thing.

Aleksi Suhonen (Axu TM Oy) commented to Kurtis on the number of IXPs this block can accommodate. He said it's also for growing existing ones. He explained if an existing one already has a /24, it's not going to be grown into a /23 but into a /22 or more that drastically reduces the number of IXPs that the /16 can support.

Andy Davidson (EIX WG co-Chair) suggested looking at previous trends of IXP growth when they evaluate this policy and look at what was intended to happen and if that was desirable and if they would do it the same way again and would shape it. He said they may have an implementation rather than the policy, based on past performance if it seems to work.

Randy Bush(Internet Initiative Japan) commented to Kurtis that they were going to be dealing with IPv4 for a long period, therefore 256 may prove not to be enough.

Alex Le Heux (RIPE NCC) also commented to Kurtis that the last /8 policy says the RIPE NCC should only allocate /22s to LIRs, one per LIR, and there will be no more PI and anycast assignments in IPv4.

Gert added that this was the reason Andy had brought it up.

Brett Carr (Nominet) remarked that the discussion was about IXP and ccTLD related issues and the growth of IXPs. He added that since ccTLD space was not going to expand, it shouldn't be included in that conversation unless they were talking about gTLD.

Gert responded that there was no plan for any new ccTLDs to show up soon however there were lots of them that didn't have anycast yet and there might be some room to growth there. He asked the audience to not mix two issues and stop the discussion on ccTLD.

Melchoir Aelmans (KPN Mobile) supported the proposal over chat.

Kurtis Lindqvist (Netnod) explained what he intended to say. The amount of space to fit into the /16 depends on what the minimum assignment size would be. He said further he hadn't quite followed Aleksi's counting. He clarified there were two things happening there, one was that they had the existing space and people might had to expand it and reminded that there has been a discussion on that the day before.He assumed that space would be returned to this pool or some other pool to be used for either IXs or something else and they can be taken out of this space. He said further, it all comes down to what minimum assignment size would be. From his point of view the important thing was that it shouldn't be a /24 but a smaller space depending on how big the exchange is. He added that they have to compromise between lack of space and hard work.

Gert ended the discussion by saying that they would do a formal proposal and send that to the mailing list. He also reminded the audience that the Address Policy Working Group doesn't make decisions in the meeting; they discuss ideas here and get feedback and bring the discussion back to the mailing list since the formal process runs via the mailing list so it's open, documented and transparent.

E. Feedback from NCC Registration Services – Alex Le Heux, RIPE NCC

The presentation is available for download at:

http://ripe62.ripe.net/presentations/160-apwg.key

Alex Le Heux (RIPE NCC) presented a global overview of the ASN 32 assignments. He mentioned that someone had raised the point to the RIPE NCC Registration Services (RS) that assigning so many 4-bit ASNs could be seen as putting organisations in that region at a competitive disadvantage since some equipment still has problems with it. He asked the audience whether it is a competitive disadvantage or if it would be a competitive advantage in a few years.

Remco van Mook (Equinix) said it was a competitive matter. He said it is really indifferent, if you still have all the equipment, you won't be able to use it. From his opinion it doesn't provide a disadvantage when you are building a new network.

Wilfried Woeber (Uni Wien/ACOnet) said most of the people running old equipment would have their 16-bit AS number anyway and if anyone upgrades the network or reconfigures stuff, there is a very good chance that pretty new equipment is involved.

Aleksi Suhonen (Axu TM Oy) explained a few cases he had been involved in when a 32-bits AS was returned for a 16-bit one, the reason was that the transit hasn't upgraded its backbone and transit provider couldn't handle a 32-bit ASN. He said the issue is not the organisation itself installing the new network, but where it is getting the transit. He said it was a competitive disadvantage between the different transits that are at different stages of upgrading their backbones however it is the organisation's own business decision.

Alex commented that they had observed both reasons appearing for wanting a 2-byte ASN: either the equipment doesn't support it or the transit provider doesn't know what to do with it. He emphasised that they were not forcing people to get 32-bit ASNs. He added further they still have 2-byte AS numbers and they assign them if anybody wants them.

Alex Le Heux (RIPE NCC) then discussed the the planned implementation of the last /8 policy. He mentioned that according to the last /8 proposal, when they hit the last /8, they shall be making only /22 allocations to LIRs, one per LIR. He clarified that some address space will still be returned to the RIPE NCC after that, however the policy doesn't have any guidelines on how this space should be dealt with. He asked the audience if after the last /8 policy comes into effect if the address space returned to the RIPE NCC should be treated the same way as the last /8.

Remco van Mook (Equinix) said he thought the RIPE NCC was taking too much liberty, though he sympathised. He said he prefered that the RIPE community come to a verdict in a proper way.

Alex replied that this was the reason he was presenting it to the community.

Remco agreed.

Gert Doering (WG Chair) said that the policy text on this topic was not clear enough. He said that it was a valid interpretation, however other interpretations would be valid as well. He added that this was RIPE NCC's interpretation and proposed using it and getting feedback.

Remco remarked that even though it might be seen as a valid interpretation they should still make sure that it gets cleaned up as they had cleaned up other pieces of policy in the past.

Alex commented that a policy text that clears this up would be even better.

Gert asked Remco if he would volunteer to help clean the text up.

Remco agreed.

Randy Bush (Internet Initiative Japan) stated that they have had the same problem in the APNIC region, and he had been a coauthor on a number of the proposals. He agreed that the issue had to be cleaned up as it had been done in APNIC region, that once they cross into the final /8 time, that is an irreversible transition.

Wilfried Woeber (Uni Wien/ACOnet) said he supported the proposal. He said he found it a good idea to consciously do that and it should be documented in whatever form: a policy extension proposal or an extended cosmetic surgery. He added that they should consider the fact that this actually has an impact on the other discussion about global policy that involves address space being returned to an RIR. He asked whether they should keep it within the region or put them pack into the IANA pool for redistribution.

Aleksi Suhonen (Axu TM Oy) said it was a nuance issue. He suggested that since the last /8 was not going to be assigned directly to End Users, it should be called something other than PI and PA.

Alex explained that in the current policy there will be no PI, however there will just be allocations to LIR and by definition they are PA allocations.

Aleksi confirmed Alex's clarification and said he made that suggestion since they were not expected to behave like PA. He asked if the policy had anything about transferring that address space between RIRs.

Alex replied that he didn't think it did.

Gert commented that there was no inter-RIR transfer policy.

Nina Bargisen (TDC A/S) supported the proposal as well. She said after they cross the time where they enter the last /8, the only way of getting any IPv4 space that was not for their own transition would be to buy it on the market. She added that if there would be any RIR address space that could be obtained in the usual way, not the market place, it would be a difficult situation to handle.

Alexander Isavnin (Media Alliance) asked if there was any means to reserve address space for particular End User needs, like getting an IPv4 address for some protocol like email that pools information and that couldn't handle IPv6.

Sander Steffann (Address Policy WG co-Chair) said there had been discussions on IPv4 for a long time and there was consensus on that. He remarked that they didn't want any special rules for special purposes. He said running out of IPv4 is going to effect everybody therefore they can not get consensus on making exceptions like that.

Nurani Nimpuno (Netnod) supported the idea that once they have the last /8, people will get addresses according to that policy. She said they could not apply both policies to different situations at the same time.

Alex le Heux clarified that the last /8 policy was worded in such a way that it could be interpreted that it only applied to space coming from that specific /8, and the address space be returned to the RIPE NCC would be from other /8s. He added that was the reason of the discussion.

Nurani said that once they have the last /8 policy, it should be apply to all addresses that the RIPE NCC allocate.

Alex replied that they were going to get a policy proposal to clear this up.

Hans Petter Holen commented to Nurani that they should be careful on their interpretation of the policy and to not make this an implicit policy which makes it impossible to return space to IANA unless that is really their intent. He said he supported the proposal and added that they needed to be careful.

Remco van Mook (Equinix) responded that as the future proposer of this proposal, he would take it into consideration in the proposal text.

Gert ended the discussion by thanking Remco and Alex. He said there were now clear guidelines on what needs to be done next.

*Policy for upgrade of “initial /32 allocation” assigned to large carriers to “something large enough for their needs” .*

Alex continued his presentation covering the policy of the “initial /32 allocation” assigned to larger carriers. He explained that RIPE NCC had been allocating IPv6 space for a long time. In the beginning, a lot of LIRs requested an IPv6 allocation without having a detailed deployment plan and they could receive a /32 allocation. Later they were actually making their deployment plan and came back with a large customer base that they would like to give a /48 subnet, therefore they requested a lot more space. He elaborated further that the RIPE NCC deals with this in two ways: if they do not want to return the current /32, the normal policies apply and they can fill it up to their HD ratio and send in additional allocation request, or they can return the current /32 and start the process as a new first allocation request, since, for example the evaluation back in 1999 maybe didn't go the way it should have gone. He asked for audience feedback.

Nina Bargisen (TDC A/S) said she remembered when an LIR came back for an additional allocation, the current /32 would be extended to a /31 then a /29.

Alex replied that they did not have so much experience with this, since few LIRs had filled up their first allocation yet, however the fact was that the /32s are inside a /29 reservation, so they can be expanded to a /29 without allocating additional prefixes. However in many cases, for the LIRs, the actual need to number all their users is going to be larger than a /29 and they have not actually used the /32 they got many years ago. He said it's better for aggregation and easier for everyone to just do a new first allocation procedure.

Alex continued his presentation on RIPE NCC experiences with the IPv6 PI policy, and then he gave some background information on the discussion about the IPv6 PI.

Gert reminded that the second session would be pretty much dedicated to discussing IPv6 PI issues.

Leo Vegoda (ICANN) asked for elaboration on the reason of an artificial distinction between PA and PI.

Gert said it would be discussed later.

James Blessing (Limelight Networks), on chat, commented that there had been two definitions used for PI space since the community decided that IPv4 and IPv6 have different definitions. He said they needed to harmonise the definitions or change the naming to make it clear that they are different. He said personally he'd go for harmonising the IPv6 version.

Gert commented that they would go far deeper details after the break and thanked Alex for bringing up the background. He invited the audience for further discussion after the break.

Session II – 5 May, 11:00 – 12:30

Gert Doering (WG co-Chair) welcomed everyone back to the second session and presented the agenda. He reminded the audience that the Address Policy Working Group doesn't make decisions in the meeting, they get feedback and bring the discussion back to the mailing list. He added that people coming up to the microphone should state their name for those participating remotely, as well as for the scribe.

L. IPv6 PI Policy – Gert Doering ,WG chair

Gert brought up a slide that was shown at the last meeting explaining some of the problems with IPv4 and IPv6 PI and the differences. He said at that point there had been no comments however later they had received a huge amount of emails discussing the issue on the mailing list. Therefore he agreed on the necessity for further discussion on that topic.

He also replied to Leo's comment by explaining the differences between PA and PI. He said PA space was given to Internet providers who used it to number thousands or millions of customers from that space. These blocks tended to be big and the allocation policies were not very strict since ISPs tend to grow, specially the IPv6 policy is fairly liberal. He said you also have End Users that need globally unique address space that is not tied to one ISP at a time. So there is portable or Provider Independent (PI) address space for this.

He explained further the PI blocks are smaller because it was meant to just number the ISP network and was not meant to be a replacement for a PA allocations. He said what was causing the most friction those days: ISP-like businesses with PI address space are not supposed to give numbers to the customers from there .

He stated that the price was also very different. If you want PA, it's assumed that you're an ISP and a RIPE membership payment will be attached, while PI is a much smaller price and comes nearly for free. He said it led to business models where people run ISPs on PI which was not how they envisioned it to be. He said the distinction was arbitrary but it didn't work anymore, at least that way.

Then he started his presentation on how the IPv6 PA/PI policies can be reworked in a fundamental way to better fit the needs of all IPv6 users.

The presentation is available for download at:

http://ripe62.ripe.net/presentations/148-wg.pdf

Gert explained that the goal was to receive feedback and later a formal policy proposal would be made. He said working group co-chairs are supposed to be neutral and steer the process, however sometimes the chairs need to push the process forward, therefore Sander would be the formal proposer of the change and Gert himself would be the neutral chair and validated that consensus has been reached. He asked the input from the audience.

Hans Petter Holen (Visma IT AS) remarked that that was an old discussion in RIPE meetings as he could remember, and considering all those discussions he was in favour of simplification. He suggested making it simple and not have different colours of IP addresses. He asked if they were trying to create number portability, the way that phone companies have done it, since the RIPE mechanism for that in the Internet is DNS but not numbers. He emphasised the necessity to figure out possible criteria to get addresses rather than just asking for some numbers.

Gert replied that they had been thinking about it for a while, so there was some small criteria like: you have to have a contract with people and be willing to pay the yearly fee for that and so on, it was not going to be free in any case. He said his sort of reality check was always looking at his parents network at home and he saw no reason his parents would want a portable address at home and they don't know what a PI address is but they don't want portable addresses because that's not what they need to run their DSL network. He clarified further a certain risk is that smaller enterprises that might have not used PI yet, might want to get portable numbers, so they would see some shift between formally PA and formally PI. He added that he didn't expect that the large mass of DSL or cable or mobile customers will apply for this because at the same time their providers will not route it. If you're billing to pay business ISP to route these numbers for you, there's a hurdle in it. It's a monetary hurdle to pay for the NCC, to pay for business ISP.

Gert brought up the slide on the numbers from ARIN that has a very liberal policy and said they had not seen demand explode so much. He said he didn't think they would see an explosion in this region.

James Blessing (Limelight Networks), on chat, asked if you had to be an LIR to hand out addresses to other parties.

Gert responded that you could, however they should see what the benefits are on that. He said they would discuss this on the mailing list further.

Hans Petter Holen stated that he was not as optimistic as Gert was. He said he had seen so many bad networks and software designs in history. His concern was that opening up such a mechanism can have a much larger impact on the Internet than they imagined. He said they were used to making good designs like those that are present in this room and the rest of the world doesn't necessarily share that but they optimise on their own financials which is shortest time to market and shortest hassle if they change providers. Independent addresses reduce their cost and they do not have to pay their upstreams and other providers. He added that this reminded him of the NANOG discussion before there had been PI space in the ARIN region. He recommended another option to set up a separate entity that would provide this service because an LIR could provide this service and you could contractually guarantee routability since you would have to make arrangements with the other ISPs and you would have to provide tunnels as the last resort.

Gert replied that there was a PI policy in place that permitted them to do exactly what had been explained to get PI space, put their own server on it and have the ISPs routed. He said more enterprises will go for PI space however the number of enterprises would be manageable. He added he was sure that there would not be a great mass like millions of DSL and capable users go for PI but he wasn't sure about the smaller enterprises. He said the financial incentive was not to go for PI because of the recurring yearly fee.

Ruediger Volk (Deutsche Telekom) warned that any statistics about IPv6 that had been collected so far allows any useful prediction about what's happening when IPv6 is actually taken up. He said regarding the PI,it was not easy to define a good criteria to protect and it didn't look very reasonable.

Gert said they were not introducing PI since it already existed, but the purpose was to actually getting rid of the weird strings attached to numbers. Then he asked Sander to steer the discussion.

Sander Steffann (Co-chair) emphasised Gert's point that they were talking about organisations that actually consciously run a network and need addresses for that and that they just aimed to make it clearer and easier.

Rob Blokzijl (RIPE Chair) stated that he supported any proposal that makes things less complicated. He said that the policy comes out of the discussion for managing the IPv6 space, and that there was a need to keep the registry requirements absolutely clear, otherwise solving one problem would create another one. He said that they had been triggered by the introduction of resource certificates for IPv4, that historically had not only two flavours or colours of addresses but more. He said they saw that it was fine to introduce certificates, it was relatively easy for the part of the address space that had been handled by the RIPE NCC. He added that it was extremely difficult to find a workable model, for instance for the IPv4 legacy space and for the PI space.

James Rice (Jump Networks Ltd) supported the idea of simplifying the system and the idea of having a financial burden on the one who announces a prefix rather than on the rest for setting up the prefix. His concern in the commercial side was what would happen if this gets too popular, since the RIPE NCC cannot have a mountain of cash. He said if there could be a simple system where mass audiences could get a bit of PI space and a few ISPs support this, then there would be a product and there would be a need either to increase the price of doing this, so that less people want to do it but then you also end up with earning more cash, or reduce the price until everyone can do it and that will be very popular.

Sander replied that the RIPE NCC would take this into account when designing the charging scheme.

Randy Bush (Internet Initiative Japan) remarked that he had never understood the PI and PA terminologies and he preferred to get rid of it. He mentioned that the RPKI was completely neutral on this. He also stated that no technology is going to resolve the issues over legacy and PI space. In reference to what Ruediger said, he added that predicting the routing table based on IPv6 statistics is the right thing, however it is not unreasonable to predict it based on IPv4. He also pointed to a paper that he and his colleagues had published earlier in which they had analysed the difference between fragmentation, i.e. increase of the routing table due to multihoming, traffic engineering, security and chopping /16s into /24s for some arbitrary reasons. He added that the latter had stayed flat as a percentage of the address space for the last 13 years, however multihoming was increasing. He reaffirmed that too much consideration on how the policy is going to affect that kind of fragging may be less productive than they thought it would be.

Gert asked Randy if he was agreeing with him.

Randy confirmed his agreement on the policy proposal idea.

Remco van Mook (as Treasurer of the RIPE NCC) reminded the room that RIPE NCC is a not for profit organisation and tries to run a balanced budget. He added that if that means that with 50,000 members the membership fee is negligible, then it was.

Sander asked him if he meant that the address space could become very cheap if that happens.

Remco replied that no matter how many members RIPE NCC would have, they still have to run a balanced budget.

Wilhelm Boeddinghaus (Strato AG) suggested to make it as simple as possible to get IPv6 space to companies if they need it for their critical infrastructure. He said many companies today outsource their IT and get IP numbers from someone else. If you get this PI space and do BGP, you have to pay the third party to run BGP routers and this is more costly than what is charged by the RIPE NCC. He said he didn't feel the explosion as these companies don't want to pay personal consultants for this and it would be too expensive if they don't need this PI space very very badly.

Gert brought up the slide on the numbers presented by Alex. He pointed to the IPv4 numbers and concluded that PI was behaving much better than PA. He said he had always been a skeptic about PI and had tried to put hurdles in the way, however people were still interested. He clarified further that numbers still didn't give an indication that being liberal was going to cause everything to explode.

Benedikt Stockebrand (freelance IPv6 related) mentioned that from a technical point of view, the actual problem of IP space was the explosion of the routing tables in the default zone. He said he wondered what would happen if there were millions of people who needed highly reliable Internet access. In addition, when you need PI addresses you will need somebody to run BGP AS which is for some people quite a problem. He suspected if there is a significant cost for the routing table problem, eventually people will have to pay for that. He said it's not only a matter of the RIPE NCC membership fees, but of the cost that generally occurs. He added that the Internet is like a box and some corners you put money in and some sides it goes out. If you drain more money out than you put in, eventually it will be empty and there will be a sort of suction effect and people will eventually start to behave sensibly.

He also pointed out that it is possible to provide people with highly redundant PI Internet access without PI addresses and without their own BGP AS. He said it's a radically different approach but it is possible and it will put more workload on the providers. He said this was a good approach for smaller customers since they put the work on the people who know about BGP, but it doesn't work for the big enterprises. He added that he might give a talk on how this can be done in the next RIPE meeting and that might be a business opportunity for some people.

Hans Petter Holen had a question about the figures from the slides. He asked about the meaning behind them since it seemed there were 3.8 times the number of routes for the first category and 1.1 for the last category. He asked if there was more multihoming in the first category or if it was more fragmentation, or both.

Gert replied that they didn't know and 3.8 routes showed up for a single block of PA space on average.

Hans commented that the answer to the question should be known and it would be interesting to know.

Gert responded that they hadn't investigated on that level and that was just counting. He said that the number of PA slots goes to that number of routes and they didn't know if it could be five of them completely misbehaving and announcing /10s as /24s. He said that according to the experience, it was a mixture of people multihoming and deaggregation for any reasons, traffic engineering, fear of hijacks, etc. He said it just showed many more routes for the same amount of allocations.

Randy Bush (Internet Initiative Japan) pointed to a paper: JSSAC, last October,“Evolution of Internet address space, deaggregation, myths and reality”. He said Pierre Francois was a coauthor and has the numbers and the pictures.

Sander asked the audience to raise their hands on the basic idea, if the distinction between PA and PI was no longer important and they would make policy for numbers or if the distincion between PA and PI was useful and they should keep it.

There were about five times more people in support of a new policy proposal than people in support of keeping the PI and PA distinction

Gert remarked that they would bring this as a formal proposal to the mailing list and thanked everyone for their contributions.

Mohsen Souissi (AFNIC) commented that he didn't have a strong opinion for or against the proposal, however he found it very important to educate people who will read the proposals and any evolution of them. He said the communication should not be only on the RIPE mailing list. He added he was not blaming RIPE for not communicating but the effort to make people understand things in a very clear way is important, otherwise, people will stay confused. He said there were many operators that didn't know that some policies even existed. He added that the cost should be considered, as well as the technical and the administrative aspects.

Gert commented that he would like to put that action item on Emilio and the RIPE NCC. He said that they were doing a good job with the outreach already and if somebody is not listening it's a bit hard.

James Blessing (Limelight Networks), on chat, said that the question was more complicated than that and it is good if the policy for getting addresses makes sense.

Gert pointed out that they hadn't voted. The purpose of this discussion at the meeting is to tell them the way they should be working on this topic.

Raymond Jetten (Elisa Oyj) asked if just numbers would help the customer understand that they may have routing problems in the future.

Sander Steffan asked if Raymond was assuming that customers will have routing problems in the future with this.

Raymond replied it may be the case.

Sander responded that they try to keep some routing issues in mind but routability is not something they can decide on.

Gert remarked that they saw people that could not get PI easily because of the policies that had been somewhat convoluted. He thought that was going to be more problematic for routing and that a new proposal might make it easier to look at a route and check the registry and see whether this has been given out or whether it's more specific.

Raymond commented that in v4 PI you are warned that you might have problem with routing. He said he didn't see the difference in v6 if you have small blocks, and that the routing table will grow and at a certain point there will be filtering and routing problems. He asked if they were to just sell numbers, would the customer be aware that he's having a block which may have problems in the future.

Gert suggested putting a warning sticker on the form that says “I have considered using address space from my provider, and I think this is going to work for me”.

Raymond agreed.

M. Discussion of open policy proposals – IPv6 related

Gert introduced the next subject to be presented and discussed. He explained that a long-term approach was already discussed and since they didn't have it formalised yet, they have a short-term proposal to change the rules for the existing PI. He said Eric Bais had brought it up and would explain it and get feedback from the room.

Proposal 2011-02, Removal of multihomed requirement for IPv6 PI – Eric Bais , A2B Internet B.V.

Eric mentioned that this was the first policy he's presented. He explained that one issue that he found interesting and was hard to explain to his customers as an LIR, was the reason that there is a difference between IPv4, IPv6, and also additional requirements specifically the multihoming requirement for getting PI. Then he started his presentation and at the end he asked the audience to give their input on the mailing list before 13th May.

The presentation is available for download at:

http://ripe62.ripe.net/presentations/171-2011-02_ripe62.ppt

Ruediger Volk (Deutsche Telekom) commented that the multihoming requirement is essentially the one technical and valid reason: by saying if you need to multihome, you will be forced to take up an additional routing slot in the global system. If you don't, you can aggregate into your upstream provider. He added that the cost and requirements, being able to renumber or not, comes into the picture. He said that people complain that paying the fees as an LIR is a cheap way to work around that criterium and it is a really bad idea to raise the barriers for people to become LIRs if they choose to pay that money. He said he was not really happy about that money flow however the technical background is actually fairly strong in this part.

Eric replied that there was a lot of discussion on the cost of PI on the mailing list. He said that he thought PI in itself is too cheap and it has to go more into a price range, however the cost-related issues were out of the scope of the proposal. He mentioned further the change from getting the technical requirement out and introducing a financial hurdle is not something you can do within a single policy.

Ruediger responded that he assumed Eric was talking about charging to hand out the numbers, not the cost of technical system.

Eric confirmed.

Job Snijders (InTouch NV) supported the proposal. He mentioned that the policy didn't specify if it has to be BGP multihoming, with LISP you have also a sort of multihoming. He said it's very nice to have your PI prefix and take it from place to place and reuse it but what they did was cheating. In reality it is proxy routers catching the traffic and forwarding it to the real place.

Mohsen Souissi (AFNIC) asked if this topic was related with the previous topic. He asked if the current proposal would make the previous one obsolete, and if so, would it replace it.

Eric replied that hopefully yes, however, in his expectation the previous topic was not something that would happen within the next year since that was a long-term issue.

Mohsen asked if Eric thinks it is a real opportunity to get through this and if there is enough motivation for the previous topic to go forward.

Eric responded that it was an intermediary solution, basically to get to the same requirements for both.

Fredy Kuenzler (Init7) supported the proposal and said he was interested to see the percentage of the audience who supported the policy change.

Sander asked the audience to raise their hand to see who was in favour of removing the multihoming requirement for PI space and who was against this change. There were no strong majority either in favour or against, so he agreed to keep discussing this.

Ruediger Volk (Deutsche Telekom) commented on Job's remarks. He said he supported the idea of lowering the price of PI even to zero and and having no multihoming requirements for PI space. He agreed with Job that it will never show up as a separate route in the routing table.

Sander remarked that they talked about that at a past RIPE meeting and at that point the opinion was if people pay enough money, the filters would be removed and it would show up in the routing table. He added if the current feeling was they can do that, then they should make a policy proposal on that.

Job commented that there was no need to make it free. He also said he thinks that it's doable that they don't use more specific prefixes in the DFZ, if they have a big aggregate. But not showing up in the DFZ will create a separate Internet and he is not in favour of that. He suggested that they may research on that area.

Sander replied that he is looking forward to any future input. Sander ended the discussion and thanked Eric for the presentation.

N. Transfer Guidelines – Dave Wilson, HEAnet

Dave Wilson introduced himself and explained that he was going to bring up non-obvious problems with IPv4 transfers and collect feedback to produce guideline text.

The presentation is available for download at:

http://ripe62.ripe.net/presentations/157-davew-addr-transf-guidelines.pdf

Dave suggested three questions for discussion. First, if there is room for the document to mention the general risks and ways to mitigate those risks of dealing with addresses that you are handing or taking from someone.

Second, how could they make sure they don't accidentally and unintentionally create responsibilities or liabilities, for example if the people acquiring the address space should check if it's on spam blacklist.

The third question was if the categories were the right kind, if some were missing and what kind of details should be brought up and how far.

James Blessing (Limelight Networks), on chat, commented that any documentation that can include guidelines on dual location and blacklists fixed are good and should be explored.

Rob Blokzijl (RIPE Chair) fully supported Dave's initiative. He said there was already a transfer policy in place and any document that explains all the technicalities that should be kept in mind when doing the transfer, was highly welcome. Rob suggested that Dave speak with the RIPE NCC legal department when he was done with the draft to discuss the responsibilities/liabilities issues.

Todd Underwood (Google) said he thought all of the RIRs, if they intended to survive in a post-IPv4 runout world, will need to become something like real estate or resource title agencies where they provide a clear title of the history of the ownership of any particular numbered resource, for instance who has had it, how long they had it,and anyone purchasing or transferring it can be aware of it. He said it seemed like a solid move in that direction. He asked if any work had been done in to look at bootstrapping the RPKI work into doing this. He explained that the theory would be: I take a resource, I sign that resource and the signature of my resource has the entire chain of authenticity of the allocation of signatures all the way back and I post that on whatever I'd like to post it and you look at that and able to validate the signature, and you send me an intent to purchase which I can sign with the signature that also has the signature validations which means I'm me and can sign other things and we execute the purchase by me signing the new allocation, at that point RIPE NCC can validate that and sign the new person, so it gets rid of the need for synchronisation and careful coordination between the buyer and seller.

Dave commented that it was very clear to him that one very strong candidate for paragraphing this document at the very first release was if you follow the policies and keep the registration database up-to-date you may have the benefit of RPKI pointed to current state. He added that it could be problematic in other ways and he didn't want to give an opinion on that. He mentioned clearly they were open to this and definitely would need to discuss it in detail over the time.

Geoff Huston (APNIC) responded to Todd's comments. He said certainly it was pretty clear that there was a potential to use digital signatures and certification with the RPKI to allow parties to a potential transaction to understand each other, otherwise the addresses are just numbers. So there were some potential roles, however the community should consider carefully what roles they would like to see an RIR participate in, in terms of such a market for these numbers. He explained further there are roles such as facilitators, etc. and that they need to give the RIR some very clear guidelines as to what their role should be however it should be a relatively passive and neutral title office. He emphasised that the opportunities, benefits and liabilities of various roles is something they need to consider as a community. It potentially includes the RPKI on the assumption that the community allows RPKI to mirror accurately the content of the authoritative database association between people and resources. His key message was: the RIR can be many things in such a environment from contacting blacklists of resource holders through to a title office. Benefits and liabilities of the different roles should be considered as a community.

Sander commented that Dave explicitly had mentioned he didn't want to change policies. He said if we start discussions about what we want the RIPE NCC to do we should do that in a separate discussion about a policy proposal and not here.

Nigel Titley (as coauthor of the transfer policy) remarked that the transfer policy in the RIPE NCC service region already required transfer blocks to be signed. He said it was a requirement, not an option.

Lu Heng (OutsideHeaven) asked if the market for transferring IP addresses was really happening, whether it could cause the cost of the IP addresses greatly rise after that year. He was worried that it might have an effect on their business. He suggested that people who don't need IP addresses simply return them to the RIPE NCC rather than transferring them in the market since it causes a lot of cost for them.

Gert replied that this is out of scope of this document. He said if their survivability on the market depends on the availability of IPv4 addresses, it will not end up on their favour. He explained that IPv4 addresses are going to be expensive until a certain point and then they'll lose their value because nobody is using them anymore. He reaffirmed that the document is not about a pricing market.

Gert closed the session by asking to continue discussions offline on the mailing list. He said that all comments are welcome and he thanked everyone for attending the WG sessions.

Session III – 6 May, 09:00 – 10:30

Gert Doering (WG Chair) opened the session at 09:00 local time by welcoming the audience and presenting the agenda.

C. Cosmetic Surgery Project - Emilio Madaio, RIPE NCC

The presentation is available for download at:

https://ripe62.ripe.net/presentations/153-Cos-Surg-Proj-RIPE62.pdf

There were no questions.

T. Discussion of open policy proposals

The presentation is available for download at:

http://ripe62.ripe.net/presentations/186-ripe62-apwg3.pdf

Proposal 2010-01, Temporary Internet Number Assignment Policies – Gert Doering (WG chair)

Gert explained that the discussion on the policy was in the mailing list and they had agreed they would go forward to have the pool in place for temporary Internet Number Assignments even if there were some disagreements on specific wording in the text of the policy at that stage. The second last call was going to end after a week and they had not received any comments until then. He said by common practice they take that as an agreement and expected this to become policy after next week.

Proposal 2006-05, IPv4 PI Assignment Size - Gert Doring (WG chair)

Gert stated that the wording of the proposal was supposed to be modified by Christmas 2011 by its proposer Nick Hilliard, however due to some health issues he couldn't deliver the new proposal text. He added further that Paul Hoogsteder who had been active in the community for a while volunteered as co-author to work with Nick to bring a new version of the text soon.

Proposal 2011-01,Global Policy for post exhaustion IPv4 allocation mechanism by the IANA - Gert Doring (WG chair)

Gert remarked that originally Phillip Smith planned to give the presentation, but he couldn't be there due to some visa issues. Later he encouraged people to read the proposal and to comment in the mailing list. He asked the opinion of the audience on the proposal since it was a new proposal that had not been discussed before.

Wilfried Woeber (Uni Wien/ACOnet) asked what the reason was for the artificial delay with the fixed period of just two times a year. He said that in this situation they might receive a /16 or lower and hold a /8, he didn't see any reason why they should wait for six months before redistributing that block. He was wondering if it would be more useful to have a minimum size accumulation at the IANA backyard and as soon as that is reached, we just treat it as a redistribution.

Gert replied that he would not be able to answer the question since he was not the author of the proposal but he guessed that it was to avoid fragmentation, so if you pool the returned addresses, after six months you can give the RIRs something bigger.

Gert encouraged the people to ask their question on the mailing list because the proposals are really in the list so they can give a proper answer. He mentioned if they start to modify the proposal, then it will not become a global proposal since the rules have to be the same in every region even if some words differ, however it's easier on the NRO if there is the same text in all regions. He said unless other regions change this, he would take it as it is or refuse it at all but not fiddle with the words as it would cause some problems.

Brian Nisbet (HEAnet) had a question on 2006-05 proposal. He asked if there was any chance that policy reach implementation before they hit the last /8?

Gert replied that it depends a bit on the community.

Brian responded that there are timelines in the PDP and run-out predictions to consider.

Gert asked Emilio to clarify what the fastest way was if they had a new text next week and they all agree that this text would be useful.

Emilio Madaio (RIPE NCC) said that the assumption was the community had a very clear idea and was going to publish them in the mailing list. He clarified that there is a four-week review phase that could be shortened depending on the input they receive and there is then a fixed four-week last call period before implementation. He added in this instance a couple of weeks is needed to run the impact analysis on the proposal and that should be quick since the RIPE NCC knows the proposal text and there was the interest in the community to speed the process up.

Gert summarised that it would take almost 10 weeks.

Brian said it sounded fair enough. He said looking at what had been predicted and what Geoff was saying about what happened in APNIC, with ten weeks, there might be one allocation given to this if we are very lucky. He supported the policy to follow the normal process.

Gert thanked Brian for bringing it up and he said he might have mentioned it himself since the time was running a bit short on this since they had been discussing it for five years.

Geoff Huston (APNIC) commented that even if the last chance rush happens in the RIPE NCC service region, the most pessimistic estimation in terms of how long until the RIPE NCC's IPv4 address pool is depleted is about four months from today and the most likely is around six months and everyone gets very excited and they all immediately queue up to the RIPE NCC and request huge amounts of space. From his idea if everything goes very fast, the proposal can be scribed with a week or two to spare.

Proposal 2008-08, Initial Certification Policy for PA Address Space Holders

Gert explained that there hadn't been many discussions on this on the mailing list, however there had been some positive feedback, so they had moved it forward for the last call. Nothing had been on the mailing list, so they took it as consensus but suddenly in the last week the there were more than 100 emails on that topic. He said that was the reason they had reshuffled the agenda to have enough time to discuss it.

Sander reaffirmed that some concerns had been raised on the mailing list about the certification proposal and the risks associated to building this. They had tried very hard to address as many of the issues raised as possible.

Sander mentioned that one of the issues was that if some law enforcement agency or company starts a law procedure or forces the RIPE NCC to revoke a certificate or reassign a certificate for instance. He said the RIPE NCC has legal counsel and asked some external lawyers on their opinion of this. He brought up a slide showing the response of the legal counsel that was also published in mailing list.

http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00434.html

He said that based on this analysis and Dutch law, the RIPE NCC cannot be ordered to revoke resource certificates.

He said some of the other concerns were about introducing a tree structure, or a hierarchy and whether they wanted this for the Internet.He added that the Ruediger Volk would give a presentation that addresses those issues and would give some feedback on the other topics.

The presentation is available for download at:

http://ripe62.ripe.net/presentations/204-RPKI-risks-20110506-final.pdf

Ruediger Volk gave a presentation to clarify some points about RPKI implications and how the implementation discussion historically evolved in the RIPE community. He finalised it by emphasising that there was a need to put more effort into better organising and handling the certification issues within the RIPE community.

Sander explained that one of the first things Ruediger had mentioned was making sure that the RIPE NCC issues certificates in a way that they want them to and have a good policy for that. All the other things are technically outside the policy proposal. He invited Stephen Kent to give more information.

Stephen Kent (BBN Technologies) clarified that after the discussion that had taken place in Lisbon, they had developed a technical description and mechanism for empowering relying parties in many ways of the sort that they had talked about there. He said there is a CIDR Working Group draft on this called "Local Trust Anchor Management" and the BBN relying party software implements that capability. It gives a relying party the ability to take old information that was part of the relying party software in open-source form that they were releasing and continually updating. He added that there would be an informational RFC in the future on that. He emphasised that it was not just something that one could do, it was something they had already done.

Sander said it was good input.

Randy Bush (Internet Initiative Japan) added further on Stephen's description that actually the Local Trust Anchor document merely tries a way of using what is already in the specifications. He said that all relying party software, including the stuff that Alex had described in his futures talk on Wednesday, would have that capability automatically.

He added that he had some doubts on the technical details of RIPE NCC's current certification capabilities, however they are essentially on the right track. He said he thinks it will be important for the NCC software set to do relying party cache as soon as possible because that cache is the customer of the current publication.

He also supported Ruediger's suggestion of having an exception mechanism. He explained that the exception mechanism was on the NANOG mailing list. He said he agreed strongly with Ruediger that they had chosen a path and unlike DNSSEC, the chosen path had been shown to be technically sound and they didn't have serious doubts about it. He agreed with Ruediger to limit their discussion to the reality of what they have.

He said further he would like to apply the same pragmatic criterion to threat analysis: can we deal with real threats and what is really been seen and not what might occur in science fiction. And those threats include what occurred in Egypt, etc. Can we stick to as close as possible to realistic scenarios, not what things might be in an alternate universe.

Sander gave the talk to Malcolm Hutty, the first person that had posted many concerns on the mailing list and asked him if everything was already covered.

Malcolm Hutty (LINX) thanked the WG co-chairs for taking this discussion seriously and for reorganising the agenda to take his concerns into account and then he thanked Ruediger for the presentation and thoughtful analysis. He said he fully supported the ultimate underlying intention behind this policy proposal. He said more secure routing will protect against certain kinds of attacks on routing however if it creates more layer 9 attacks than it solves at a lower level, and it's a net loss unless the routing table is a good place to conduct law enforcement.

He disagreed that this can be called science fiction and with Ruediger that those attacks in his estimation would be very rare. He believed that was very real, clear and present. He said he knew the sources where these attacks would come from and that they are very real. He gave an example: the Internet Watch Foundation, a single organisation that acts to prevent access to a single type of content, child pornography information, has over 400 URLs in its database at any given time but under various bits of legislation being advanced at the moment around Europe there is a consorted effort to require network intermediaries to prevent access to sites that are seen to have copyright infringement and that kind of material is very prevalent and flits around all the time.

Sander commented that it is something for the future. He said Ruediger also had assumed it as a real threat in his presentation, and either it happens often or rarely is not really the point.

Ruediger said that according to the legal statement that was shown, as long as the Dutch legislator doesn't change the Dutch laws, there is no attack vector on the RIPE NCC.

Malcolm replied that there was a misinterpretation of what the legal counsel had said. He added he had posted a more detailed explanation to the mailing list of what the counsel had said that they did not believe that the RIPE NCC could be ordered by Dutch courts under the current legislation to revoke a certificate, however there existed a forthcoming legislation that would require member states to ensure that Internet intermediaries prevent access to Internet locations.

Sander said that they were running really short on time and suggested assuming that these threats are real and can occur.

Malcolm referred to Ruediger's statement that was supported by Randy that they should exclude what they might have done differently and just focus on the proposal on the table. He said that this means that they should not consider what the Certification Task Force might have come up with if they had said to them very clearly, they need a solution for securing routing that does not allow a single party to revoke certificates and enable these layer 9 attacks. He said it was a misjudgement. He added that these are significantly serious that it would be worth asking if there are fundamentally better architecture that could be pursued on this.

Sander commented that looking at different solutions, they should talk to the IETF regarding this since the IETF are responsible for developing standards, not the RIPE community.

Malcolm replied that it might be the case, however the working group was being asked to approve it and he was not going to agree to go ahead with the proposal until they have seen some real evidence that they have investigated it according to a requirement statement that they should be looking to avoid those level 9 attacks.

Sander responded that Stephen, Randy and Ruediger had shown that in the system they had, there were protections against the threats. He asked Malcolm if any of his concerns had not been addressed by Ruediger's presentation.

Malcolm responded that Ruediger talked about mitigations that they could put in place but he didn't address the idea that we should try something that is against those risks. From his idea they should instead try something that is fundamentally more proof against that, rather than trying to ignore the risks.

Malcolm also suggested that the APWG should not agree on community consensus in support of this until they are able to weigh the risks with the mitigations in place, against the risks that are foreseeable.

Shane Kerr (Internet Systems Consortium) responded to the last point that policies can be changed and they have to use the policies that are best at the moment. He said they don't need to achieve a perfect policy before they agree to do anything. He added that they were talking about being concerned about a system that makes it difficult to enact local policy and it would be better to think of it in those terms rather than thinking about threats and attacks.

Shane asked Ruediger where the conversations about the additional work on this policy should occur.

Ruediger suggested that people who were very seriously concerned consider how they could contribute. He said the whole thing had taken quite a while and it was a large effort and it should not be taken for granted and whatever some community says would be nice to have just happens because that notion is mentioned.

Hans Petter Holen (Visma IT AS) said if this is a mechanism that we need operationally to secure the Internet and good enough as the first version to work with and also if it is possible to improve that in the future then it's very simple accept and implement it.

Randy commented to Malcolm that he may be unaware of the open fora for working on the policy since this policy had some fairly long history and the current design had been done by qualified security operations and legal people in the Internet game and people with a lot of knowledge. He encouraged Malcolm to participate through the mailing list if he has technical questions. He said that they all have to support how to go forward as a community.

Dave Wilson (HEAnet) remarked that he was not going to emphasise the risks of inaction but in his opinion that was the most optimistic he had ever seen in the community regarding the universal deployment of a new security technology. He said if they take very long about it, this may end up in a future where IP addresses may already have been monetised in a way they hadn't seen before, in this case they would have even more interests railed against securing the infrastructure in that way. He was very anxious to see them implement something that they have confidence in with a view to changing rather than waiting for perfection.

Gert ended the discussion by asking Randy to send a pointer to the technical discussions to the Address Policy mailing list so that people that are not so good in IETF things can easily find it in the context of the discussion.

U. IPv6 Allocation policy and 6rd – Jan Zorz , Go6 Institute Slovenia and Mark Townsley, Cisco

Jan Zorz (Go6 Institute Slovenia) explained that he had been approached by many small operators, that could not deploy 6rd since they didn't qualify for more than /32 IPv6 addresses. He said from another side there had been some concerns from RIPE NCC staff regarding receiving the 6rd requests. Therefore they decided to put this issue forward. He invited Mark Townsley, one of the authors of 6rd FC, to explain the techniques and technology and the reason why deploying 6rd was missing in the policy.

The presentation is available for download at

http://ripe62.ripe.net/presentations/193-zorz-townsley-6rd-ripe62-may-2011.pptx

Mark brought up some issues at the end of his presentation and mentioned that Jan will present the possible solutions.

Jan clarified that some real issues existed and he was wondering whether people wanted to deal with them or just to deny them. He said if they wanted to deal with the issues, there were three possible solutions. He explained that they had removed the first one because asking IANA to allocate special space for 6rd was hilarious , the second one would be to make 6rd special as either a transition or permanent technology, he said in this case they need to reclaim it back then after three years or later . The third possible solution was to raise the minimum allocation size for IPv6 space to /29 by default in favour of small companies.

Jan asked for the audience's input and asked to hear about other possible solutions or suggestions on how to make a policy that works with this transition technology.

Ragnar Anfinsen (Altibox AS) said that was a real problem for them and he supported a minimum allocation size of /29.

Wilfried Woeber (Uni Wien/ACOnet) asked if they would actually need two /29s, one for the 6rd and another one to deploy IPv6 natively.

Mark replied that you would need two /30s, one for 6rd and one for other stuff which makes up the /29.

Wilfried responded that with the /30 you could give 2 bits or 4 bits for the subnet.

Mark explained that /27 yields a 60 for the home and that's actually what's commonplace amongst the few million carriers. /29 yields a /62. Because there are two /30s here and you actually working the 6rd within one of the /30s.

Mohsen Souissi (AFNIC) asked to bring back the last slide. He said he thought that the second solution, special space for 6rd, is the most reasonable choice. It gives a guarantee to the RIPE NCC to reclaim back any prefix which was on purpose for 6rd and it doesn't apply any longer when the ISP goes for native IPv6. From his opinion the third solution didn't really save resources since many ISPs don't even need more than /30 or /31.

Jan commented that currently /32s have been allocated with a reserve space of /29, so they could easily extend the legacy IPv6 allocation to /29. He said that space would never be used since it's reserved for those LIRs to extend.

Gert remarked that they were running short on time and that they are not arguing that point. He also pointed out that they had discussed this for a long time and at that point in time, they had decided that they were not able to actually find criteria that something was over now and that was something that they needed to consider very well. He also gave the audience some numbers that they had something like 7,000 LIRs in the RIPE NCC service region at that moment and they had 130,000 /29s, so that waste would be possible.

Shane Kerr (Internet Systems Consortium) thanked Gert for the numbers and he believed that the conservation was not really that important there and allowing a /29 seemed more straightforward. He also asked Gert if there was in the past technology specific address policies and that he thought that had been kind of resisted in general.

Gert clarified that there had been some text about cable and related things however most of time Wilfried had stood up and said we should not have policies that cover specific technologies because other technologies might evolve that also should benefit from addresses, so, it had been mentioned but usually not taken up very well.

Shane said it was a good general guideline. He said everyone is going for 6rd no matter what their actual requirements are once that's the way you get lots of space.

Benedikt Stockebrand (Freelancer) said he was in favour of the third solution, minimum allocation size of /29. He commented that IPv6 is not IPv4 so wasting addresses might actually be a good idea at that point.He added further that their goal should be to make people deploy IPv6 as quickly and easily as possible. On the other hand, they shouldn't build up another pile of legacy technology and the easiest way to deal with that is to keep the functionality reasonably low, so people have a reason to move forward to proper IPv6 later on.

Ari Keränen (Ericsson) was fine with either the second or third solution, special space for 6rd or minimum allocation size of /29. He had a clarifying question on approach number two. He asked whether they would apply some conditions in the future policy or not, like if you are running on net 10 space, you don't actually need any special allocation, or if you have an aggregated block, you don't need it in this case either.

Gert replied that to actually be able to define criteria, where that applies and when that stops applying is hard.

Jan asked if the RSP goes off 6rd and does some native stuff in that space, how would they reclaim it back.

Ari responded that in his idea the questions of allocating a space and reclaiming that space, are separate. He clarified that he was only talking about the allocation action.

Jan commented that he thinks they are tied together somehow, because in the second option, they must reclaim the space back since it is a special case, hence, he was not in favour of that.

Jordi Palet Martinez (Consulintel) was not in favour of temporary policies and in his opinion reclaiming any resource afterwards is not going to work. He said he didn't like 6rd since using it with existing policies would bring customers only a single subnet. He suggested to actually making sure to make the policies flexible, for example if an ISP wants to deploy a /48 and that means needs a /16, can get a /16. He added further that one of the important principles in IPv6 is fast deploying rather than conserving a space that they are never going to use.

Mark asked Jordi if he was saying that he went for number two, special space for 6rd, with variable allocation size.

Jordi clarified that he meant to make sure the existing policy works for 6rd and also other technologies that may be in the same situation. He agreed with the statement that, a special policy for special technologies doesn't work very well.

Gert remarked that actually there were not enough /16s to do that.

Lorenzo Colitti(Google) partly agreed with Jordi on clarifying in the existing policy that if an ISP justifies a larger allocation based on the use of 6rd, then the community believes that this is a worthy goal and therefore should be taken into account by registration services when allocating space. He mentioned that they should try to conserve where it's reasonable and not assign separate space for this. He also found 6rd transition painful for the industry as a whole and said we should also allow any new transition mechanisms.

Mark asked if Lorenzo was in favour of the second option, special space for 6rd.

Lorenzo agreed.

Jan asked Lorenzo how much traffic there was from 6rd.

Lorenzo replied that the only access network that uses v6 on large scale was based on 6rd. It was basically the totality of any access v6 deployment at any scale at the moment.

Hans Petter Holen (Visma IT AS) commented that they shouldn't make policies that prevent good technologies.

Gert found it a very good closing remark.

Mark asked Gert on what they should do next.

Gert said it was what he had planned to get at.

Jan asked if they can have some input from RIPE NCC staff.

Gert explained that at that stage Jan and Mark needed to work with the Working Group co-Chairs, as well as Emilio and possibly Alex Le Heux to draft something that would be sent out to the mailing list to get input, and then form a policy document. He said the draft should be something that everybody agrees on.

Mark said that since support was voiced for option two and three, they should clarify them and initiate a discussion on which is better.

Gert commented that they should just look at the policy documents and see how they can make things fit together. He said voices from this room tend to give input, but can be usually convinced to accept the other option if that's more reasonable.

Gert thanked everybody and closed the session.