RIPE 74 Address Policy Working Group Minutes

Chairs: Gert Doering, Sander Steffann
Scribe: Antony Gollan

Session I – Wednesday, 10 May 2017 09:00 – 10:30
Session II – Wednesday, 10 May 2017 11:00 – 12:30

Session I – Wednesday, 10 May 2017 09:00 – 10:30

A. Administrative Matters

Gert welcomed attendees and ran through the agenda. There were no changes.

B. WG Chair Selection Procedure.

Sander said that it was easy this time as Gert was the only candidate standing. However, he said that next year he would be stepping down and would not be volunteering again. They therefore needed new candidates.

Gert was re-appointed for another term as Chair without any objections.

Gert said this process might look a little silly when there were no other candidates, but there was a serious purpose here – it gave them a chance to decide if they wanted to re-commit, and gave new candidates a chance to stand.

C. Current Policy Topics

Marco Schmidt, RIPE NCC

This presentation is available at:
https://ripe74.ripe.net/archives/video/78/

Randy Bush, IIJ, said that he, Phillip Smith and others were the original authors of the last /8 policies in the RIPE and APNIC regions. They hadn't given /22 as the allocation size but rather had said “the current minimum allocation” – which would be the general minimum allocation size – not just for the last /8 but for all allocations. He suggested it was time to discuss dropping the minimum allocation size. LACNIC was raising the question and he thought it was a good one.

Gert said this was a reasonable question to ask. He suggested they have someone from the RIPE NCC look at the numbers and see how long their stock would last with the current minimum allocation size and see if they thought it was reasonable or not.

Marco Schmidt, RIPE NCC, said they published a graph of their remaining IPv4 pool and if the current trends continued, they had address space for another four years or so.

Geoff Huston, APNIC, said the RIPE NCC's free pool would last until 5 February 2020.

Randy said he didn't think someone would be able to start an enterprise without an IPv4 address in front of it four years from now. The reason they had set aside a /8 was for new entrants to enter the game. In four years, they might be talking about a /29 as the minimum allocation – because at the end of the day this was about starting NAT64. He thought it was time to start talking about this.

Gert said it was good to have a reminder that ultimately this was about starting NAT64.

Randy said some people might have thought the reason they had a last /8 policy was so they could have 38 further discussions about modifying it.

Gert said it was reasonable to discuss this. He said someone should volunteer to write a proposal.

Peter Koch, DENIC, referred to Marco's slide on mailing list participation. He said this was a good snapshot but asked if next time Marco could differentiate between substantive policy engagement and “+1s” or other low-quality comments.

D. Feedback from RIPE NCC Registration Services

Andrea Cima, RIPE NCC

This presentation is available at:
https://ripe74.ripe.net/presentations/85-FeedbackRS-RIPE74_final.pdf

Gert thanked Andrea for the detailed feedback and said it was important to see what the consequences of the WG's decisions were.

Maksym Tuliev, NetAssist, asked what it meant if an ASN was not visible in the global routing. He asked what the RIPE NCC's criteria was.

Andrea replied that they would not reclaim ASNs from organisations who claimed they were using the resources. If they received notification that an ASN was in use, they would stop there.

Enno Rey, ERNW, said he had a question on the status of the clean up of ALLOCATED UNSPECIFIED and ALLOCATED PI. They held several blocks of mainly ALLOCATED UNSPECIFIED for two LIRs. One LIR had contacted them and they had resolved the issue. The other was not replying to any queries. He asked what they should do in this case, as the blocks were in use and they didn't want to risk them losing connectivity.

Andrea said that if the blocks were in use, they wanted to make sure they didn't cause any issues for the people involved. He said he would follow-up with Enno offline about what they could do in this specific case.

Randy asked if the reason they were trying to recover unused ASNs was to hold on to 2-byte ASNs, as some people still couldn't handle 4-byte ones.

Gert said it was really housekeeping. They had a stewardship role to know where ASNs were and if they didn't see them, they might have been lost.

Randy said that was a good reason. He asked if the RIPE NCC was still getting a significant number of requests from people who couldn't use a 4-byte ASN.

Andrea said it was around 50/50 when it came to 2 vs 4-byte requests, but he'd have to check the exact figure.

Randy said in that case there was an issue, as this was a significant number of people.

Andrea said they didn't ask people why they wanted the ASN, so it could just be a general preference for 2-byte ASNs.

E. Outdated References in Policy Documents.

Marco Schmidt, RIPE NCC

This presentation is available at:
https://ripe74.ripe.net/presentations/82-Outdated-Policy-References.pdf

Erik Bais, A2B Internet, said he preferred a lightweight approach – track and trace if references were outdated. Marco as the Policy Development Officer could provide suggested updates, with a short period for comments before making the update. He didn't think they needed a PDP process if it was basically just RFC numbers being updated.

Tahar Shar, Consultant for the German Government, said normally he would say this should be as informal as possible, unless the change in RFC had an impact on the meaning of why it was referenced. In these cases, there should be a process.

Randy said they didn't want to ask someone to judge if there were significant semantic differences between two versions of an RFC. The IETF was pretty formal about when an RFC was updated or obsoleted. In the header, it pointed to the new RFC. So the option of ignoring this did not mean they were pretending it wasn't a change or a problem – it could mean relying on the forward pointers in the header. The IETF made sure these pointers were updated.

Marco said currently the references in RIPE policies linked to the FTP server that didn't show whether they were obsolete or up to date.

Peter Koch, DENIC, asked what Marco had meant by “orphaned references”.

Marco said this was where there was a reference at the bottom of the document that was no longer mentioned in the content of the policy. It was essentially a useless reference.

Peter said he had complained previously when they updated a document and the changed redline version didn't mention new RFCs – 3330 was a prime example. He thought that the least they should do was carefully look at references and evaluate them when they updated a document for another reason. This wasn't a clerical task like replacing one RFC with another, as there might be changes in the content. He disagreed with Randy – there were no forward pointers in RFCs, because RFCs were immutable. There were pointers in the RFC editor's representation of this by means of linking, but that presented the same problem. Just saying that they were now referencing to the RFC or any subsequent version depending on how important the content was – it depended. It also depended on whether it was a normative or informal reference (as the IETF would say). He thought this would be a case-by-case decision and there wasn't a general process they could apply.

Elvis Velea, v4Escrow, said they should just present-comment-change. When an RFC reference was changed, this could be presented to the community without a formal PDP process. They were not in a rush, so maybe they could just present these changes at a RIPE Meeting and have a show of hands.

Gert said he didn't think they should do this by a show of hands at a RIPE Meeting. The underlying philosophy of the WG was that it was open to everyone and you didn't need to go to RIPE Meetings to participate. Having a lightweight process was good, but they should definitely send a short note to the list with the proposed edit, four weeks of comment time, and then the Chairs could decide if there was support for it. If it was a more substantive change, they could decide to use a formal process on a case-by-case basis.

Hans Petter Holen, RIPE Chair, said he supported lightweight approaches, but they should be clear on what they wanted to achieve. If they were going to make changes to the policies, these needed to be formally documented and tracked. The PDP process took 19 weeks – they had the four weeks in the discussion phase to determine whether there were substantial changes or not, and the latter phases would ensure that everyone was informed. A shorter process could save Marco some work and if it was urgent, he could see the point. However, in that case maybe they needed to develop a different PDP process for urgent cases. However, he didn't see the big benefit of inventing a new lightweight process to make these changes.

Gert said the PDP was a heavyweight process that required active support at every stage except for last call. If they brought ten changes into the PDP, nine of which were clerical and one that was substantial, he knew what would happen; they would have no participation and it would grind to a halt. He thought the PDP should be reserved for true policy changes. Dropping an outdated reference was an editorial change. They had done changes to “shoulds” and “musts” before without invoking the PDP. There was a precedent for this.

Peter said he was sceptical of the lightweight religion. If something was urgent then it was likely important. He said Gert had mentioned they would report this to the relevant list and then make the change. He asked if they would issue a new document number.

Gert said they would – the text would have changed and that meant they needed a new document number.

Peter said in that case it would have updated timestamps and other aspects. He agreed that they needed a new document number. It was a case-by-case decision – circumstances changed over time and it might not only be the references but also the content that was out of date. Defining a “lightweight” process might take more effort than simply using the PDP and if the PDP was seen as being so heavyweight that it was avoided, then it became a self-fulfilling prophecy. Marco had come up with seven documents that needed updates after all these years. Trying to deal with one of the less controversial changes shouldn't be hard for them – they should trust in their own processes.

Erik said the biggest issue he saw was that if they used the PDP, they would need more authors/editors to take the updated documents through the PDP process – because they would not be able to use Marco.

Jordi Palet agreed that they probably didn't need the formal PDP process. In LACNIC they had done another review of the policy book and had used a small design team to make a review and bringing a single proposal to modify that to the PDP process. If they needed to use the PDP process, they could do that, and if they took that approach, he would be happy to volunteer.

Gert said Marco should send an email to the list with his findings and they as a WG would decide how to proceed. There was no clear path forward and so they would take this to the list.

Hans Petter noted that so long as they could convince the RIPE Chair that this was done in an open and transparent way, then this would be fine.

F. Discussion of Open Policy Proposals

2017-01 Publish Statistics on Intra-RIR Legacy Updates

Elvis Daniel Velea

This presentation is available at:
https://ripe74.ripe.net/presentations/72-20170510-2017-01.pdf

Erik said Elvis had mentioned it was difficult for buyers or sellers to see if a block had been hijacked. He asked if Elvis knew you could look at the history in the RIPE Database.

Elvis said this was true, but you couldn't know if the person shown in the RIPE Database was the legitimate holder or not.

Erik said as part of due diligence, if the person saw a change, they could simply email the RIPE NCC and ask if the update to the reference was confirmed.

Elvis said he wasn't sure the RIPE NCC could provide this information.

Erik said you could ask the RIPE NCC if the information in the RIPE Registry was current and matched with the RIPE Database.

END OF FIRST SESSION

Session II – Wednesday, 10 May 2017 11:00 – 12:30

2017-01 Publish Statistics on Inter-RIR Legacy Updates (continued)

Erik said he had spoken with the RIPE NCC's Registration Services Department in the break, who informed him that a buyer couldn't request confirmation from the RIPE NCC. The buyer could see the actual changes in the RIPE Database that was dated, which gave an indication as to how/why this was changed. The issue with getting the contractual change as an optional decision didn't change the issue in the end – because if you wanted to do this you needed to do it for everyone.

Elvis said the way he saw this being done was from the moment a legacy object was updated, a remark would be added that this was updated but not yet approved by the RIPE NCC. They would verify this by having the buyer and seller sign a kind of template agreement, after which the database remarks would be removed. At this point you would know that the transfer had been approved by the RIPE NCC.

Erik said he was basically asking for the RIPE NCC to approve changes to non-contracted space that was outside of the RIPE NCC. This would be exposing the RIPE NCC to a massive liability issue that would turn into a big problem.

Gert said the way he saw it, the RIPE NCC did not have a mandate nor did it currently validate legacy holdership changes.

Ingrid Wijte, RIPE NCC, said that when they received a request to help with the change to a legacy object, they performed a verification at that moment to check that they were dealing with the legitimate holder. If the current holder listed in the RIPE Database was not verified, they did not know, as they were given the ability to maintain the space. If their help was not needed or requested to change the registration of some space, then they were not a party to the change and did not know about it.

Elvis asked if changes to legacy objects where the legacy holder had a contractual relationship with the RIPE NCC would require verification.

Ingrid said that once space was brought into the RIPE Registry, they had already done their verification. They needed to be informed if something was changed later, in order to maintain accurate records.

Sander said the RIPE NCC sometimes performed verification to allow someone access to their objects. He asked if the RIPE NCC assumed liability as they were now certifying that the space was correct.

Ingrid said they asked the person to show that they were the legitimate holder. But if they were not comfortable that they were the legitimate holder then they did not allow them access. But it was up to the requesting party to convince them of the legitimacy.

Sander asked if a buyer knew that the RIPE NCC had looked at this, whether they could then have some kind of confirmation or reassurance that it had been researched.

Ingrid said there was often a very high amount of research done, it depended on the amount of access they had to give the resource holder.

Elvis said this had started with the question of whether there would be a legal issue – if the policy was approved, would the RIPE NCC be able to update legacy objects saying it had been updated without doing any due diligence?

Andrea Cima said this was something that should be checked in the impact analysis by their legal team.

Hank Nussbacher, IUCC, said he was a legacy holder who had gone through the process for about 16 resources, each taking a number of months to get registered properly. He didn't see any value in this proposal. Legacy holders had already jumped through a lot of hoops to get their resources registered and they didn't want to go through more simply for statistical purposes. People could already do a diff to see changes in the RIPE Database. He didn't see any benefit to doing this, either for the legacy holders or the buyer or the seller. People had already decided whether to go into the system or to stay out of the system.

Elvis disagreed. He thought there was high value on this – especially guaranteeing to the buyer that the block had actually been transferred to them by the legitimate holder and not any other party that may have gotten their hands on the object.

Hank said he had no problem with the RIPE NCC adding another flag if they saw something going on. But he wanted to minimise the work that legacy holders had to do in terms of preparing documentation.

Elvis said all the legacy holder needed to do was sign a document.

Hank said Elvis had obviously never done this before. He had dealt with several universities personally and the documents that needed to be approved and gathered to meet the RIPE NCC's requirements took months.

Elvis said he had experience with hundreds of transfers and in his experience, it was not so complicated. In one case, he had gotten power of attorney and it had taken six months to get this. He agreed with Hank that it could be complicated in some cases, where there were large companies or universities.

Hank said if it was complicated simply for statistical purposes then he didn't see any value in the proposal.

Carlos Friacas, from the Portuguese NREN, said he was also a legacy resource holder and he worked for universities that were legacy holders. He had started this process with some Portuguese universities two years ago and some still had not signed – so it took time. He wasn't interested in buying or selling, only protecting his universities. If some of these universities were interested in selling their assets, they would have to find a new sponsoring LIR. He could support Elvis's proposal if it was optional for those legacy holders who wanted to sign something, but not if it was mandatory.

Elvis said this proposal would keep this as voluntary, and if people wanted this to be mandatory, it would not be done in this proposal. If the wording in the proposal needed to be changed to make it clear that this was optional, then they would do another version.

Andrea said Elvis had discussed some points with Eric earlier where he mentioned an automated remark that would be added to the object, stating that had it been changed without verification by the RIPE NCC, and afterwards the two parties could sign an agreement and inform the RIPE NCC about this. If the object has been updated, the transfer had probably been completed. So, by the time the RIPE NCC received some documentation, it had been completed. However, the RIPE NCC would still need to perform due diligence to ensure that the offering party was the legitimate holder. He asked what they expected the RIPE NCC to do if they found in the paperwork that they couldn't prove that the transfer was justified. Would they want the RIPE NCC to do look the other way or decide that it was a hijack and revert the transfer?

Elvis said this was a good question. If an object had been updated, the remark would have been added, and the RIPE NCC would remove this only when they had verified that there was a new holder. As long as this remark was there, it would mean that this had been updated and not all the documentation had been provided. The RIPE NCC might request documents to verify the transfer and this could take time. He didn't think they should consider this a hijack while people were trying to provide the right documents. On the other hand, after hearing from Andrea, he wasn't sure that they shouldn't consider this a hijack either. He said this was something to think about further.

Geoff Huston, APNIC, said part of his job was to analyse the network and its behaviour with addresses and report back to policy communities to help them make policy. He said they had one set of transfers that were listed, and when they looked into the routing system, they saw a much bigger set of changes, in some cases up to nine times as many. When they looked at the database, some of these were transfers, but some were other kinds of changes. It would be helpful to eliminate some of the guesswork – by providing some explicit guidance to show which were definitely transfers. The brokers could also do this, but they had decided not to. They therefore turned back to the registry to see if they could mark it there. He wasn't part of the discussion with legacy holders, but if they could shine some light on this, it would help them to see the impact of their policies.

Randy said they were here about records – he asked Andrea and Ingrid if this would improve their records at a reasonable level of effort for all parties. He asked where the gaps were, and whether there were things they could do about them. He said this was an echo of Geoff's statement – would this policy help significantly?

Ingrid said one of the issues around the accuracy of statistics was the optional part. If it was not mandatory to report every change to a legacy object to the RIPE NCC, then they could only publish what people told them.

Randy said he was less interested in the accuracy of statistics, he was more interested in the accuracy of the records.

Ingrid said when they received update requests for legacy resources, transfers did not formally exist. They did their due diligence and asked for some disclaimers to be signed and after verification, there could be more certainty of the accuracy.

Randy said he was a legacy holder, he did not buy and sell address space, and he was willing to do a little more work to improve what their principle goal was.

Ingrid said at this point it was difficult to say how accurate their records were, because they had not been verified.

Elvis said that by making this optional in the proposal, only those legacy holders that actually took the option would improve the accuracy of the registry. The rest of the records might remain less accurate.

Wilfried Woeber, Vienna University – ZID/ACOnet, said he was very much in line with Carlos and he was very grateful to Geoff for bringing up his point about seeing the reality in the database. He didn't have an answer to Andrea's question, but he did have an observation: irrespective of optional or compulsory procedures to label resources, it didn't really make a difference in reality. If the RIPE NCC received any indication that something fishy was going on, he would also hope that they started an investigation. Whether this was a full-blown investigation for a suspected hijack, or a more lightweight investigation trying to correlate registry data with the routing reality, he thought they could and should get support from the community as a mandate for the RIPE NCC to do this on a general basis. He felt that it shouldn't matter if it was PA or legacy space – the RIPE NCC should investigate when they saw something strange.

Andrea said they didn't proactively check whether something was happening to legacy resources that were not under a contractual relationship, as there was no framework for doing so. However, they did investigate resources that weren't covered by a contractual relationship in specific cases. For example, if someone contacted them and tried to take space by submitting fraudulent documents, they would try to inform the real resource holder and protect their resources. But they only did this when they were approached. For most legacy resources, this was between the resource holders themselves and didn't involve the RIPE NCC – this was how the current framework worked and what the policy allowed.

Gert asked Andrea and Ingrid to send some numbers to the mailing list about how far the legacy project had progressed.

Andrea said they could send the exact number later, but around 42% of legacy address space in the RIPE region had been brought under a contractual relationship. This was after the legacy policy had been brought into place, so he thought the policy had been quite successful.

Gert said he wasn't sure what conclusion to draw from that, but more data was always good.

Sander asked what the difference was between a legacy holder choosing to enter a contractual relationship and the optional verification in the proposal. What was the benefit of what Elvis was suggesting compared to what they already had?

Elvis said when a legacy object was updated that was under a contractual relationship, the RIPE NCC was informed and would verify it by default, but they didn't publish the statistics. However, if the resources were not under a contract, the RIPE NCC wasn't notified and the registry and database were not in sync.

Sander said it seemed like they already had an optional way of verifying this, without the policy.

Elvis said the proposal gave you the option to not have a contractual relationship and still have your update verified by the RIPE NCC.

Erik said if you did a transfer of legacy space, you could inform the RIPE NCC to update the registry without a legacy contract. So that option was already in place for anyone who wanted to inform the RIPE NCC of any transfers that had been done. It was only mandatory if you wanted to break-up a parent object, as you couldn't do this as a legacy holder. An interesting part of Andrea's question was whether that would trigger an investigation by the RIPE NCC. If it was a transfer, typically by this point the escrow would have been paid out already. This meant the fraudulent activity has already been completed, the payment completed, and the resources would be reclaimed later. So, as an escrow person, you might use this to only pay out after the RIPE NCC had completed its process. He said it was a fully secure system already, if you wanted it to be like that.

Sander said he was trying to work out what the proposal added that they didn't already have.

Wilfried said if this went ahead you got a free ride, but otherwise you had to pay an annual fee per resource.

Elvis said if the policy was approved and a hijack happened, you would be notified immediately. The object would be updated in the RIPE Database but with a remark that it had not yet been reviewed by the RIPE NCC.

Sander said if the RIPE NCC did the verification, it would be a free ride.

Wilfried said in the current proposal, you already got a link to the sponsoring organisation. Anyone who was a little knowledgeable could already get this link and find it out. He didn't think they needed to spend the RIPE NCC members' resources to give these people a free ride.

Elvis asked if you paid a fee to enter into a contractual relationship for legacy resources.

Wilfried said that you did. In his own case, they didn't pass on the invoice, but some LIRs did. There was no structural difference – it was about EUR 50 per resource.

Gert said he thought they had exhausted all points of view. He said they hadn't reached consensus in the Discussion Phase. It would be valuable to have the impact analysis from the RIPE NCC.

Elvis said this had come up because there was a gap in the statistics.

Gert said it was complicated. He could've just said: “If there is a legacy transfer in the system, put it on the page.”

Elvis said he had worked with Marco to find the simplest solution.

Gert said they might end up with a simple line like this. The current proposal was adding a lot of obligations onto people.

Sander said the big question was whether they wanted to put a burden on legacy holders to fill in the eventual gaps.

2016-04 IPv6 PI Sub-assignment Clarification

Maximilian Wilhelm

This presentation is available at:
https://ripe74.ripe.net/presentations/90-RIPE74-IPv6-PI-Sub-assignment-Clarification.pdf

Gert said that as a matter of formality, this was not the formal text of version 2.0 now – they needed feedback before they brought this into the system.

Elvis said he liked it. He asked what the difference was between the Point-to-Point links to customers and DSL cable customers.

Gert said you were supposed to give a customer a subnet and not a single address. Back in the day when they did the IPv6 PI policy, people were afraid that they would be giving DSL operators an incentive to give customers a single IPv6 address (as they did in IPv4) and force them to use NAT. He didn't think this danger was so great anymore. They had functioning IPv6 providers out there that gave subnets to their customers and they didn't have CPEs that did IPv6 NAT by default. So, a DSL provider that wanted to do single IPv6 addresses to customers, and would find a CPE that worked for that, would be at a market disadvantage because everyone else would be doing something else and there was a BCOP document that said not to do that. He didn't think there was a need to try and fix this by policy that there might have been ten years ago.

Elvis liked the idea that you could use it for public WiFis and liked that you could use it for hosting or housing servers. However, he wasn't sure about the PTP things, as that might open something that they didn't want to open. For example, in Romania 50 or 80% of more customers didn't use CPEs – they had a fibre connection to their house that went into their router or computer directly.

Gert said he wouldn't worry about Romania – they had such a large IPv6 rollout with subnets and were actually showing the rest of them how it was done.

Sander said in the past they were worried that people were so inexperienced with IPv6 they needed policy with strong guidance to lead people in the right direction. His gut feeling was that they had now gone far enough and set enough standards that they no longer needed to use the policy for leverage anymore.

An audience member said he liked this idea much better than the previous version. His concern was about the PTP links, because if you had customers then you had to assign out of your PA space – so why did you need to use PI space for the link itself? He didn't see the justification for this.

Maximilian said if his customer had their own PI space, he could route it and have his IP space for the PTP link and announce the PI space of that customer, for example.

Gert said it wasn't that you were encouraged to use this for PTP links, but if you came to the RIPE NCC and said you had a lot of customers with their own address space and you wanted to number the interconnections with that, you couldn't do this under the current policy. So this was just to clarify that this could be done. It wasn't encouragement, but it could be done under the new text.

The audience member continued by saying that there should be some generic document specifying what was considered a sub-assignment and what was not. Maybe also for IPv4, because there were some differences. For instance, he had just noticed that some ISP was assigning /64s from PI space to its customers. And the ISP's response was that these were so-called ISPs that had just one upstream were not willing to pay to become an LIR, and so were operating IPv4 PI space for their customers, and when they deployed IPv6 they went the same way, which was wrong. But the other option was not deploying IPv6 at all, which was also negative.

Sander said that what he was describing was not allowed under the current policy and it would still not be allowed under the proposal being discussed, and this was intentional.

The audience member agreed, but said maybe it would be good to clarify whether using IPv4 PI space for broadband pools was okay or not.

Gert replied that it was, because in the IPv4 PI policy there was an exemption for infrastructure, which this was considered to be. This had been there since the beginning of time. They had discussed this many times in the WG – that IPv4 and IPv6 were different in this respect. No one had ever tried to change this in the IPv4 policy, but that topic was finished now anyway. They had wanted to provide guidance to IPv6 roll-outs to not use the same model of single addresses and forcing customers to use NAT, which was why the IPv6 PI policy was stricter. If people were lying to the RIPE NCC because otherwise they wouldn't have gotten the address space, that was different. This proposal was about encouraging people to not lie to the RIPE NCC to get guest network addresses approved.

Maximilian said he was proposing the policy change because he was honest.

Jordi Palet, Consulintel, said he needed time to process the new proposal. His fear was that, one month after the proposal was accepted, they might realise they'd missed something. Even though he was partially responsible as the initial proposer of the PI policy, he had been thinking for some time now that they needed to do away with the difference between PI and PA.

Gert said they had previously done quite a bit of work to figure out what the consequences of removing this difference might be. The result was so complicated that the WG had told them to go away. They might look at this again, but they should do one piece at a time. If they couldn't do away with the difference between PI and PA in a year's time, Maximilian would still be waiting for his addresses.

Elvis said he understood the PTP links aspect a little better and he now thought this was an acceptable idea, especially because he understood that Maximilian wanted to use it so they could route the customer's PI space, for example. He said this was fine. Elvis added that he was happy to work with Jordi on a PI/PA unification proposal.

Marco said yesterday they had a meeting with some experienced IP Resource Analysts from the RIPE NCC's Registration Services Department to go over the proposal text. Their current understanding was that any subnet up to a /127 would not be allowed, because no subnets could be sub-assigned, but a single IP could. There might be some confusion on subnets vs prefixes. He also wanted to clarify that the strict interpretation the RIPE NCC had been using until now was something that they had checked with the community several times in the past to be clear that this was what it wanted. Times had changed, and if the community felt that the RIPE NCC should be applying a new interpretation, they could provide them with feedback explaining this.

Sander suggested they could add a line in the text to emphasise that this was about assigning whole subnets. He said they would help Maximilian to phrase that.

Maximilian asked Marco if this phrase about “whole subnets” would make the RIPE NCC happier.

Marco said they would need to analyse this before they could speak definitively. However, anything that would make this more precise would be welcome. They would need to look at how it fit into the policy to see how it could work. He said they could work together to come up with something that was as clear as possible and as usable as possible.

Elvis noted that he didn't see WiFi anywhere in the text.

Gert said it didn't have to be there.

Elvis suggested they add text with examples of what was included/excluded.

Gert said he didn't think they needed to exclude it. In 3G they had standards that said every mobile got a /64. He didn't think they needed to worry about this – as there was good precedents in the market that this was an accepted practice. So, what he was hearing was that this needed to go into the rationale – so the intended use after the change was clearly explained and discouraged uses (because there were better approaches) was also mentioned. But they didn't give an exhaustive list of what was and wasn't allowed, as this was done by the policy text. Having a rationale that explained what the underlying thought was would help the RIPE NCC to interpret the policy.

Elvis asked what the difference was between assigning a /64 to your cable customer and a /56 to your virtual machines customer.

Gert replied that you were allowed to do neither. You could give a hosting customer a single address if you ran the network that it was connected to. You were not allowed to give them a /56, period.

Elvis said you could use a /64 for the link to each virtual machine of that customer.

Gert said you did the IPv6 assignment and the customer just ran the machine. If you gave them a subnet and told them to organise this however they liked, this was an assignment and this was very clear in the policy.

Sander said the text said you couldn't give someone a /56 and let them run their own network. And if you gave someone a /56 to run their own server, the second part of the text kicked-in, where you couldn't assign subnets to third parties.

Wilfried, said he liked the idea of having a section that explained what they wanted to achieve. He supported the goals of the updated proposal version but was a little concerned about the choice of words – as even a /127 was a subnet. They might want to change the wording around subnets. He was less happy with the use of the term “responsibility”. In many environments, the responsibility to operate the network was the with the holder of the address space, but the responsibility of what was done on a virtual machine was with the operator of that machine. Delegating this responsibility to third parties was too fuzzy from his point of view – it should point to the fact that the receiving organisation was not supposed to do their own address space design and planning, and was not supposed to take this subset of PI to do more PI and have it routed from somewhere else.

Gert said what he was hearing was that Wilfried and Maximilian needed to have an email exchange to sort this out.

Sean Stuart, speaking for himself, said the easiest way to interpret between host vs subnet was that if he gave you a /127 to connect to a network, it was a host. If he gave you a /127 connect a VM to another VM, it was a network.

Gert said what he was hearing from the room was general support for the direction of the proposal, some concern around the side-effects and the wording, and they had sorted most of this out. He thought they were mostly ready to go ahead with this.

Y. Open Policy Hour

The WG agreed to talk about Randy's proposal to change the minimum allocation size.

Randy said the original last /8 policy aimed to allow people 10-20 years from now to reach IPv4 networks. Most of his customers needed to use NAT64 to move to IPv6 – so they needed at least a small amount of IPv4. Currently the smallest routable prefix was a /24. In a few years, this might be a /29. The problem was that they were going to run-out at the current rate. That meant that someone entering the game would not get a IPv4 address. He didn't want to raise the boogeyman of the regulators, but someone might call this “restraint of trade”. He was looking for co-authors for a proposal to address this.

Raymond Jetten, Elisa, said IPv4 was going to run-out and they shouldn't try and extend its lifetime.

Ana Wilson, HEAnet, said she felt uncomfortable telling people in the future that because they had done a bad job managing IPv4, newcomers would have to deal with the consequences. She supported Randy's idea.

Elvis thought it was good to extend the lifetime of IPv4. But he didn't think they should do this with the current /8. They had a million addresses reserved for whatever they would think of in the future. He suggested they use these IP addresses for the /24s that Randy was talking about.

Ana asked why those addresses should be used.

Elvis said they already had a policy for /22s, and if Randy made a proposal for changing the last /8 policy, there would be a lot of opposition.

Randy said he wasn't proposing to change the last /8 policy. The last /8 policy said, “use the minimum allocation size” – he was proposing they change the minimum allocation size.

Elvis said this was almost the same thing. He was suggesting they set up the /24 goal for that one million IPv4 addresses.

Sander said one million IPv4 addresses would only be 4,000 /24s. It wouldn't be enough.

Elvis said that by the time a /24 proposal was passed, they would still only have a tiny bit of address space in the last /8 pool anyway.

Marco said only one /16 of these one million addresses were set aside for unseen circumstances. The other addresses were reserved for things like temporary assignments – so hacking into this pool would affect other policies.

Rob Evans, Jisc Services, suggested they could have a sliding window that was based on the amount of address space remaining, so they didn't have to keep updating the policy. He said there were two bits to the policy –there was the allocation size, and there was also a maximum amount of address space allocated to a customer after the September 2012 being a /22. He asked if both of these would need to go down in tandem.

Randy said the reason he was talking about a /24 now was that it would take longer for smaller blocks to be routable in the Ops community. Changing to a /24 now would send the message that it was going to change further.

Carlos said he was worried about the routing table size. He asked if other regions would play along by doing the same and going even beyond a /24.

Randy said he believed there had already been experiments regarding this in the ARIN region.

Rob Seastrom, ARIN AC (speaking on his own behalf) said he wasn't sure that updating routing to route successively longer prefixes served any particular purpose.

Wilfried said he'd been hearing concerns about the routing table size for 10 or 20 years. He said this should certainly worry about the potential explosion of the routing table, but it shouldn't be their key consideration – they had more than enough slack for a couple of years and they could always come back to address this.

Randy said the agreement on the /19 minimum allocation size had been from 1995 because sprint routers were falling over. The restrictions of routers had caused policy in the past and he ran routers. But he had grandkids and he wanted them to be able to get onto the Internet.

Elvis said the last time they had tried to modify the IPv4 policy there had been a lot of opposition from special interests in the community. He said it would be a long and complicated process.

Gert said this shouldn't stop them.

Thomas Schmid, DFN, said that from an operator perspective, if they were to open this can of worms, they should restrict it to some well-known prefix ranges, as this could swamp routing and cause sessions to be dropped.

END OF SECOND SESSION