RIPE 77 Address Policy Working Group Minutes

Chairs: Gert Doering, Erik Bais
Scribe: Antony Gollan

A. Administrative Matters

Gert Doering, Address Policy WG Co-chair welcomed attendees and noted that this would be the first full session with Erik Bais as co-chair.

The minutes from RIPE 77 were adopted without comment.

B. Update on 2018-04 PDP Clarification to the WG

Gert noted that consensus had been reached on this proposal, which allowed chairs to extend the Discussion Phase in the Policy Development Process if they needed to allow time for more comments.

C. Current Policy Topics

This presentation is available here:
https://ripe77.ripe.net/presentations/51-PolicyTopics_MarcoSchmidt_12Oct2018.pdf

Jordi Palet Martinez, The IPv6 Company, said he had authored an additional proposal in LACNIC that Marco hadn’t mentioned. This was equivalent to the PDP change in the RIPE region and aimed to solve the issue where if a proposal didn’t reach consensus within the defined time frame, the author was forced to re-submit a new version – even if there were no changes to the text. Everyone had supported this at the meeting, they were now just waiting for consensus on the list. 

Jordi added that he had also submitted an abuse-c proposal at APNIC. However, one hour later someone else had submitted a similar proposal. They had since combined these into one proposal. Regarding the abuse-c proposal in LACNIC – they had wanted the same time frames as APNIC, which was why this had gone back to the list.

D. IPv4 End Game and Afterlife

This presentation is available here:
https://ripe77.ripe.net/presentations/71-Andrea_Cima_RIPE_77_APWG.pdf

CarlosFriacas, FCT/FCCN, asked how the RIPE NCC was getting returned IPv4 address space. He asked if people were returning these willingly or it was due to policy violations. 

Andrea replied that it was a mix.

Carlos said it sounded strange that people would return IPv4 addresses, especially since some people were making a lot of money out of them.

Andrea said addresses might also be returned because a company had gone bankrupt or didn’t exist anymore, or they could be de-registered because of policy non-compliance.

Carlos said he’d like to see some percentages around this.

Andrea said they could share some of this information.  

Sander Steffann, Retevia, said moving addresses to the IXP pool was a good thing, as the expected four years before this was exhausted might be a bit short. Regarding the allocation size, he supported reducing this to a /24 as it lowered the potential for abuse. If they did this when the waiting list kicked-in, there might be less resistance than the last time this had been discussed.

Erik asked if Sander supported enlarging the IXP pool from a /16 to a /15 or moving the IPv4 dust there.

Sander said he supported both ideas.

Sherif Khalifa, Tedata, said many upstream providers wouldn’t accept /24s because of the impact on the BGP table and hardware resources. He asked what Andrea thought about this.

Andrea said this was a good point and this was why they had raised this – the people in the room were network operators and they knew better than him how this worked in real life.

Sherif said in real life most upstreams were not accepting /24s – there were asking for /22 or /23s.

Erik Bais, Address Policy WG Co-chair, said it depended on whether it was de-aggregated or allocated space. Typically, if it was allocated space from the RIPE NCC and there was a valid route object, they would route it for you – because that was what you had. Many providers filtered anything smaller than this by default. If it was a series of /24s announced from a /18, then it was a valid to ask if you could aggregate this and route it as a /18.

Sherif said in that case you needed to give him /24s from the same range, so he could aggregate them.

Andrea added that the RIPE NCC had assigned many thousands of /24 PI blocks over the years and had never received complaints that these could not be routed.

Nurani Nimpuno, Asteroid, complemented Andrea for preempting the discussions that would come as they approached full IPv4 exhaustion and providing statistics. She thought most of what he had said made sense. Replacing the contiguous /16 that had been reserved for unforeseen circumstances with /23s and /24s made sense, as did the waiting list. She didn’t know if it was too early to look at the IXP pool size, but this was a valid question. When they had discussed the minimum allocation size last year, the arguments had been around making the IPv4 pool last longer. They had agreed then that they weren’t gaining a lot of time by doing this. Andrea’s point about the waiting list made sense – a smaller allocation size would allow them to serve LIRs faster. It might be too early to reach a final decision, but perhaps they could converge on a /24 allocation size as they drew closer to run-out.

Gert asked if Nurani expected the growth of IXPs to continue or if would it soon reach a saturation point.

Nurani said she worked for an IXP that also deployed IXPs – so she would be speaking from a self-interested position. Nevertheless, she thought there were many places in the RIPE region that needed IXPs. There was still a lot of space for smaller, local interconnection IXPs and having more than one IXP in a mature market was desired by operators because it offered diversity and kept the incumbent honest.

Gert asked if this meant that they should make the IXP pool bigger if they modified it.

Nurani supported this idea. 

Erik asked if Nurani thought the smaller IPv4 dust would be useful for IXPs, because IXP VLANs were typically not routable on the Internet anyway.

Nurani said she would need to think about this once she’d had a coffee.

Aftab Siddiqui, speaking in a personal capacity as an APNIC community member, said they had 623 requests on the waiting list in their region and this number would only grow. They were now talking about abolishing the waiting list because it didn’t make any sense, given that addresses would not magically appear. He said some people might return addresses to the RIPE NCC, but the only other space they would get would be from IANA’s recovered pool. He didn’t think it made sense talking about a waiting list at this stage.

Andrea said there were two waiting lists in the APNIC region – so the situation there was a bit more complex there. He asked what the RIPE NCC should do with returned addresses, as there would be networks that needed them.

Aftab suggested a cut-off date, after which there would be no waiting list. He asked how many addresses the RIPE NCC had received from IANA last time.

Andrea said they had received practically nothing from IANA, but they were more concerned with the ~500,000 IPv4 addresses that were returned to the RIPE NCC each year from other sources (de-registrations for policy non-compliance or non-payment of bills, etc). He added that they expected to receive fewer returned addresses in the future.

Aftab said if the allocation size was a /24, then this might be negotiable. If they had a /22 size it wouldn’t make much difference.

Andrea agreed and said this was why he had wanted to show the difference a /24 allocation size would make.

Sebastian Wiesinger, Noris Network AG, supported the idea of replacing the contiguous /16 for unforeseen circumstances with separate blocks. He didn’t see any harm in a waiting list, though he would like to see some kind of expiry date or a requirement that people had to re-confirm that they needed addresses, so the list wouldn’t just keep growing. Regarding moving smaller blocks into the IXP pool, he said it would good to see some data from IXPs that were requesting addresses to see if this would work for them – as it might mean an IXP couldn’t grow beyond 200 members. He mostly supported changing the minimum allocation size to a /24 if it was for a waiting list. He thought people might be more willing to agree on this approach.

Erik asked if Sebastian imagined people could simply re-confirm that they wanted to stay on the waiting list.

Sebastian said he wasn’t sure. He essentially wanted some function to make sure people didn’t stay on the list forever.

An audience member via remote participation asked how long it would be until they could live without IPv4 as and IPv6 would be enough for smaller organisations. They added that it made sense to use smaller blocks for IXPs.

Andrea said he would turn this question over to the room as they were the experts.

Nick Hilliard, INEX, said there was no clear answer to this. He said he understood that the unforeseen circumstances pool would expire at some point. He supported removing this clause and keeping these addresses, as they never knew what might happen in the future.

Andrea said this would require a policy proposal.

Nick agreed with Aftab’s point that there was no sense in having a waiting list that stretched towards infinity. It gave an illusion of fairness but the longer it existed the more unfair it was to new entrants and others. He was supported not having a waiting list or otherwise having a very strict cut-off policy.

Andrea asked how the RIPE NCC should handle returned addresses if there was no waiting list – as they would still get addresses. They could put these addresses aside, but it would be wasteful as people might need them.

Nick said if there was a waiting list, there needed to be some other approach – maybe they made random allocations, maybe people would expire off the list. From a policy optics point of view, an infinitely extending waiting list was probably the least contentious but this would create the worst outcome.

Andrea said a first-come first-served policy would be the natural continuation of the current policy.

Nick said they needed to decide what they wanted. Any policy would be contentious, but an infinite list would not provide any level of fairness. Regarding the IXP pool, it would be problematic if this expired first. He supported adding more addresses to this pool if the community agreed, as IXPs were generally thought to be quite important. Regarding blocks smaller than a /24 being used for IXPs, this was complicated, and it came down to the issue of whether IXPs liked to route their prefixes (there were good reasons both for and against). Prohibiting IXPs from doing this on the basis of their assignment size was a difficult thing to swallow and he preferred that blocks smaller than a /24 be put aside as dust and organisations that were using the rest of a /24 could relinquish their blocks over time.

Erik asked how blocks smaller than a /24 would affect rDNS for IXPs.

Nick said this could be solved with CNAMEs and PTRs. They had run INEX with several /28s, /27s and 26s before they finally just went with a /23 – it was doable, but it was a pain. It was not a huge amount of address space in the scheme of things and from a strategic point of view, it was better for IXPs to use /24s as a minimum. He supported moving to a /24 allocation size only once they had exhausted the free pool.   

Juri Bogdanov, IP4MARKET, suggested that the IPv4 dust could be connected to the closest /24. There was not enough address space in these blocks to be significant and there were other blocks in the database that these smaller blocks had been cut from that were not routable for the people who owned them. Connecting these blocks would make the RIPE Database simpler and clearer.

Aftab asked what the current size of the IXP pool was.

Andrea said a /16 had been set aside, though half had already been issued for IXPs. If they took the current assignment rate, they expected this to last a further four years.

Aftab asked if Andrea had any data on the number of requests.

Andrea showed the IXP graph (slide 12), noting that the scale of the graph was a /16. He said IXPs could request a maximum of a /22, though some could get smaller blocks. He said the allocation sizes varied according to the size of the IXP.  

Aftab said they hadn’t set aside IPv4 for IXPs in their region. He asked where Andrea would get the IPv4 addresses to grow the size of the IXP pool.

Andrea clarified that this would come from the regular IPv4 pool.

Aftab asked why they didn’t simply avoid the waiting list problem by moving all of this address space to the IXP pool.

Peter Koch said a /16 looked appealing to launder the prefix sizes but he thought this deserved more consideration, as there were too many “unknown unknowns”. Regarding a waiting list, there were different ways to read “first-come first-served”. By having a waiting list you simply moved the race to an earlier point in time. Here they would be waiting for the RIPE NCC to get addresses from IANA and then have people rush to get them. First-come first-served didn’t mean that if you went to a closed restaurant you had the right to eat there the next day.

Andrea added that under the current policy, the /16 for unforeseen circumstances would be given out as allocations once the free pool was exhausted.

Gert said his intuition was that Peter was right. Burning through the /16 for unforeseen circumstances simply to create more convenient /22s was not a good solution. He didn’t see any appetite to reduce the IXP pool, so that was off the table. Enlarging this pool seemed to have support, but this would require a policy change and they would need a volunteer for this. He heard that people didn’t want the dust to be assigned to IXPs. Allowing IXPs to decide whether or not they routed their address space seemed like a good idea, but making assignments of dust according to whether they wanted to route it didn’t seem like a good idea, given the clause in the IXP policy.

Nick volunteered to create a policy regarding the IXP pool.

Gert said there seemed to be support to change the allocation size to a /24 once they reached the waiting list, but this would need a volunteer as well.

Sander volunteered to create a policy regarding the minimum allocation size.

Daniel Stolpe, Resilans AB,asked where this dust had come from.

Andrea said this was mostly from PI assignments where some people could only justify a /27 or even a /29. It wasn’t common, which was why they only had a few thousand addresses. He said they could just sweep it under the carpet, but it needed to be a conscious decision.

Gert said he had been thinking they could just give the dust to whoever held the adjacent block – but it might not be worth the trouble and would also require a policy proposal.

Erik agreed that this didn’t seem to be worth the trouble.

Carlos said for ten years they had been trying to run a new IXP portal that was 300 kilometres from the capital. A /27 was more than enough for them and perhaps others were in this situation.

Gert said he was hearing different things from the IXP people, so they should talk with each other and make up their minds.

Radu-AdrianFeurdean, Coriolis, asked if they didn’t also have something like IPv4 dust with the temporary assignment pool. He asked if they needed to do something with this at some point.

Andrea said they had a /13 set aside for temporary assignments. They could add the dust to this if they ever found they needed to use the entire pool. At the moment they had only ever assigned less than half of this pool at one time.

Radu-Adrain asked if they needed this pool.

Andrea said they did get a lot of requests for temporary assignments – for conferences and events. He thought it was very important to keep this. They could discuss the size of this pool, but he expected to be getting more requests for temporary assignments once people could not get IPv4 addresses another way.

Gert noted that had gone over time, but it had been a very useful discussion.

 End of first session.

E. Country Codes in the Extended Delegated Statistics and RIPE DB

Ingrid Wijte, RIPE NCC 

This presentation is available here:
https://ripe77.ripe.net/presentations/65-CC-extdelstats-database-IW.pdf

Dmitry Kohmanyuk, Hostmaster Ltd, said the country and the country code were not the same thing. He knew of people in Kosovo that had .EU or .AL in the database, and there was the issue of Ukrainian territorial disputes with Russia and likely other cases such as Iranian sanctions. He supported the database having one place which was the legal address while the extended statistics could signify multiple allocations (for example operations). This made sense to him, because the database was never intended to assume the true country code, while the extended statistics were more flexible and open to modification.

Ingrid clarified that she was talking about the country code that was registered, which identified a country – rather than defining what it should be. Given his comment, she asked if Dmitry thought the RIPE Database be more restricted for updates, because it was currently open and could be changed at any time, but if this was defined as containing the legal country, it would imply changes to make this more controlled.

Dmitry said he didn't have a strong opinion. There were cases where it would be counterproductive for the ISP to identify the country they were actually located in, for example in Kosovo or the Crimean region – but these would need to be the exception rather than the rule.

Ingrid added that the RIPE NCC had always taken a flexible approach to the countries Dmitry had mentioned – they aimed to make the the database useful and allowed them to make these sorts of updates.

Alex Le Heux, Tucows, said from a purely operational point of view – despite whatever the RIPE Database manuals said – in reality people used this information for geolocation and other purposes. As an operator, he wanted this attribute (in both the database and the delegated stats) to show what was useful for his network. If there was a legal requirement to display a certain type of information, he wanted it to be included as a separate entry.

Erik said the file that they were talking about only concerned allocations – not assignments that people put into the database.

Alex said he was aware of that, but both levels were used by various geolocation services. Everyone did something else, so as an operator he wanted the flexibility to do what worked in his situation, which might be different from someone else’s situation.

Carlos said he wanted to thank Ingrid for this work because he liked statistics. He noted that some time ago he had spotted something about Portugal in the delegated statistics that that looked strange. He had contacted the RIPE NCC and this had been corrected, and he thought this was useful.

Geoff Huston, APNIC, said he was a consumer of data from the RIPE NCC and the other RIRs. A lot of people wanted statistics about countries, so they had to somehow take data that reflected IP addresses and ASNs and map this to countries. However, the depressing fact was that he was more likely to rely on data from Maxmind than the RIRs. There was probably a good reason for this – he was interested in the legal locality in terms of nation states that a particular IP address was being used (rather than where the allocation had gone). If he wanted the RIRs to curate this information, it couldn’t go into the stats file and probably couldn’t go into the database – it was a different level of granularity. So, he had to wonder what they meant when they put the country code into the stats file – Ingrid had said there were five different interpretations of this data and she was right. Sometimes it referred to the country of the entity that had been given the allocation in the distant past and what had happened since was none of their business. They spent a lot of time tracking their locality, but at a level of granularity that was irrelevant. He didn’t know how this could be fixed, but he didn’t think they understood what the country statistics were in the five collective stats reports – what might make things clearer would be to define one meaning and stick to it.

Jaap Akkerhuis, NLnet Labs, warned against the use of country codes in general. A lot of people understood different things about what counted as a country. If you followed ISO 3166, you saw that Kosovo didn’t have a country code, which was why the EU was using XK for the time being. The ISO couldn’t make decisions about these kinds of things – they had actually received calls from three or four offices claiming to represent Kosovo, and so were waiting for the UN to decide. They needed to be careful here, because otherwise they would quickly have a political battle on their hands. If they needed to use a country code and were using ISO 3166, then should really adhere to this and not invent things on their way.

Carlos said he thought geolocation was a mess. He asked for the RIPE NCC to engage with geolocation providers and try to get them to RIPE Meetings. From his personal experience trying to fix geolocation issues for his members, these companies offered a process to report issues but then chose not to reply or fix any issues that were reported to them.

Ingrid said one of the few things that was clearly defined was the fact that these statistics were not a reliable way to map to countries. People often updated this information as a last resort, hoping that maybe the geolocation would change if they changed the country code there.

George Michaelson, APNIC, said he wanted to give some of the history around these statistics files to add context. The files had never come out of any policy process or engagement with the community. Instead they had come from an obligation to provide statistical reports about resources that the RIRs felt they had. APNIC had taken the original file into a conversation with the other RIRs and emerged with an agreement on the field structure of the file. This included the decision to use the vertical bar as a separator, to count hosts in IPv4 but prefixes in IPv6, and the decision to include a field with the economy code. He stressed that, even though the field said CC, they really needed to start thinking about economies rather than countries (for reasons others had mentioned). Not all of these codes in the file referred to countries.

George continued by saying that he thought the meaning of these fields was something that needed to be negotiated. Possibly, the text in the readme files and the meaning of these fields was the important goal here. Stating clearly that this was a field that aligned with ISO 3166 two-letter codes and that its exact application to actual addresses was a little looser – this was interesting. It would be nice if it was simpler, like legal entity, but there were reasons it wasn’t. He added that Ingrid had said some things that went to the extended file (as opposed to the stats file), which included unallocated addresses, reserved addresses, and additional fields like a unique entity code. The process of defining additional fields and field positions in a CSV file was difficult. The minute an entity in a common file added a new column, there needed to be agreement on how people would use this field. Otherwise, the moment people diverged, you would have chaos. If they were going to add new fields, they would need to have negotiation between the RIRs to reach a consistent outcome. It would be unfortunate if the file format diverged.

Ingrid said she was aware of these concerns. She added that there were already some differences – as she believed APNIC were the only ones to publish opaque IDs.

George replied that all RIRs now published this, but the exact format was unspecified. Some RIRs used a UUID, but APNIC used a self-generated unique code from a database trigger.  The file was quite careful to state that although you might have a consistent value between generational versions of a file, these could only be guaranteed as unique within an individual file. There were also inferences about the date that had to be understood – some people regarded this as the “birth date” when the resource came into public view, while others saw this as the last transactional moment when a change was applied. When you had blocks being split and rejoined, this has a massive impact and so there were already issues with the file.

Gert said he wanted to add a comment as a participant to this discussion rather than as chair. They could muddle this a bit more – as the allocation object had a point where it was an organisation and the organisation object had a country code as well. So, if they wanted to define it that way, they could have the organisation be the legal country and the allocation object be the operational country. This reflected Alex’s earlier comment, where the allocation object could be used for operational purposes. The country code field in the organisation object was not curated either, so if people wanted to put any country code in there at the moment, they could. This was just something they might want to keep in mind.

Carlos Martinez, LACNIC, said he wanted to point out one thing regarding Ingrid’s slide that had referred to LACNIC. Their intent for the delegated stats and their database was to only declare the information that they could vouch for – which was essentially the legal address. That said, they were trying out two new things. The first was that as a result of a policy proposal, they were publishing a different file from the extended delegated stats with more granular information on sub-allocations. Both the country code and the sub-allocations could be configured by the user. The second was that they would be publishing a different file using a format called Geofield (which was defined in an expired draft). This would explicitly contain information that was declared by the users, and so it was not was not information LACNIC could vouch for. LACNIC would simply provide an interface for the member or user to publish this information.

Geoff said he wanted to respond to Gert’s comment, because there was a subtle distinction between the stats files, the extended stats files and the database. The stats/extended stats files showed a snapshot of the entirety of the holdings of the RIPE NCC on a given day. If you started to put pointers into the database, you had a referential problem – only certain people could pick up the entirety of the database and it wasn’t the same as the stats file. If they were looking for a solution around the country code issue, it would be helpful to find one that was self-contained in this holistic stats file rather than pointing to other pieces of data that were curated and published using different mechanisms and different access procedures. They shouldn’t make a snapshot that pointed to a query-based system.

Gert said he hadn’t meant to suggest that. He simply wanted to highlight that they actually had three different country codes that were already interlinked in funny ways. If they declared that both the legal and operational country in the database had a well-defined meaning, it might be necessary to extend the stats files to include the legal and operational country. He wasn’t saying they should go there – they were discussing the meaning of these fields and trying to work out if they had a common understanding of what they meant (or at least what they expected them to mean).

Geoff said in his experience, his increasingly-depressing understanding was that he couldn’t use what they published in the stats files and extended stats files as a reliable geolocator, even into economies. Maybe legal presence was perfectly fine, and geolocation was a separate problem. Maybe they could simply admit this and move on. But he used it one way, Alex used it another way, and the RIPE NCC as secretariat maintained it a different way. This was where the madness crept in. Perhaps there was value in this discussion bringing it out, even if they couldn’t actually solve the problem.

George said he wanted to expose two conversations that seemed informative. The first was with a large CDN operator when he had discussed the mismatch between assertions they had made about IPR and how they associated IP addresses with locations to constrain television content IPR – intellectual property rules that were bound in geography. The operator’s assertion was: “I am a CDN. I am at over 200 points of presence in BGP. Why do you believe your assertion of locations statically is better than my measured presence in BGP of an IP address, arriving at an end‑point and other actions I can do?” George had replied that he didn’t think his assertions were better, but the CDN didn’t expose its model for the wider public to consume. The operator had replied that it was not to his financial advantage to do so. The point here was that this information was financially valuable for companies and in the absence of a public framework, this information was an economic element of competing entities.

George’s second conversation was with a large dominant player in their collective universe. They said they had moved to a model based on of proof of possession. When they received requests for peering and requests for changes to geolocation, they looked to the registries, which had an authority model which said who could change public data. This company would say to the asset holder: “Here is a hash string that is unique to you – make this visible in a number of public repositories that demand you have proof of possession. When we see this, we will believe that you have control of the asset and then we can discuss your geolocation problem.” He said this model really intrigued him, because in this case they didn’t want the RIRs to publish the geolocation – they wanted them to prove possession, which would allow them to discuss geolocation with the resource holder. He didn’t know what he thought about that, he just thought it was very interesting.

Erik thanked the WG and said they would take this discussion back to the mailing list.

Ingrid added that she would be giving this same presentation in the Database Working Group.

F. Discussion of Open Policy Proposals
2018-02, Assignment Clarification in IPv6 Policy

Jordi Palet Martinez

This presentation is available here:
https://ripe77.ripe.net/presentations/78-RIPE-2018-02-v3.pdf

Maximilian Wilhelm, Freifunk Rheinland / Freifunk Hochstift,said that while the proposal didn’t break the initial case that had caused him to make his policy change a few years ago, it broke something else: hosting and housing. This had been explicitly agreed on by the working group.

Jordi said he believed this was in Max’s introduction rather than the policy text itself. He said this raised the question of what was more important – the policy text or the rationale.

Maximilian said Ingrid and Andrea had previously stated that the rationale in policy proposals was also taken into account, and his rationale had made it clear that hosting and housing should be allowed. He thought this meant that hosting and housing was be allowed – but invited the RIPE NCC to correct him if he was mistaken.

Jordi said he understood that when Maximilian said “hosting and housing” he was referring to a different case than IP surveillance, as you were actually hiding address space for others to have their own systems. He said they could adjust the text to cover this case, but he thought the community might want to decide whether it should allow a company offering hosting and housing should be allowed to use PI, as this was a big decision.

Maximilian said he thought they should distinguish between big data centre operators (such as Digital Ocean) which should be an LIR – and community projects which offered housing for cheap projects or whatever.

Gert said they came in all sizes and shapes and the fact that you couldn’t start as a garage provider was an argument against the previous policy. If you wanted to start a small shop and didn’t want to become an LIR right away, there might be an argument for using PI. If the WG was fine with this, he was fine with it as well.

Jordi said he was fine with this, but he wanted to know if the WG was fine with PI being used to provide services.

Peter Koch said if this was the clarification – could they please have the confusing part back. They now had a list of exceptions, but still hadn’t addressed what the definition of sub-assignment was. What they had at the moment was confusing and complicated. He suggested they decide what they wanted before looking at the wording itself.

Jordi said they needed to fix the definition of sub-assignment and he was not really happy with the text they had at the moment. When he reviewed the policy text, he thought it was confusing.

Peter said he wasn’t questioning the intent or the need for clarification. He was simply saying that by adding more exceptions they were making things more complicated and this text was more complicated than before

Jordi said sometimes you needed more text to clarify things.

Peter said this might be where they disagreed.

Marco Schmidt, RIPE NCC, said he wanted to provide some clarification regarding whether a hosting service was allowed with PI. The policy text quoted a couple of examples and one was connecting a server or an appliance to the assignment holder’s network – so this was allowed. He also wanted to make a comment on the example of a sub-contractor using a device on the resource holder’s network. He didn’t think this would be an issue under the current policy – a sub-contractor installing a surveillance system would be considered a part of that network. He said they hadn’t received such detailed requests before and he didn’t think a request like this would be an issue under the current policy.

Gert said they needed to discuss version two and see if they had agreement. From what he’d heard, they hadn’t found much traction on the problem statement. They hadn’t gotten enough feedback and he didn’t see enough agreement on whether this needed to happen.

Maximilian asked what version they were looking at.

Jordi clarified that this was version three.

Erik said, looking at the lack of feedback on the mailing list, even after an extension and asking the WG for comments, his personal view was that there wasn’t much interest in making the policy change. He agreed with Peter that maybe they needed to go back to the drawing board and have a good discussion on what a sub-assignment was. One thing he wanted to know from the RIPE NCC was how big the typical PI assignments were. If it was a /48, for the majority of ISPs they would run-out eventually and have to become LIRs anyway. He wondered if they were looking at this too strictly. 

Jordi said he didn’t think an ISP having a /48 and providing services was allowed at any point.

Nikolas Pediaditis, RIPE NCC, said in response to Erik’s question – the majority of requests were for /48s and if bigger they could be a /47 or a /46. There had not been many requests since the policy was updated but there was no evidence that people were trying to abuse the system. They had only received a handful of very large PI requests. The requests they had received so far were not due to ISPs providing services, but due to unique routing requirements such as multiple sites.

Erik suggested they have a look at what problem they were trying to solve and were they happy with the experience they had. Maybe they needed to be more lenient on what a sub-assignment was and have faith that once they needed more space, people could transition into an LIR. This would make everyone’s lives easier, and the RIPE NCC could monitor this.

Jordi said they needed to think what they wanted a sub-assignment to be as a community. Did the community think a small data centre could be on PI or not? These were the kinds of questions that needed to be answered.

Gert said this was two entangled questions. One was the question what a sub-assignment was and the other was what should be allowed under PI. They didn’t want to restrict people from using IPv6 because they wanted to encourage them. He echoed Erik’s comment that they needed to go back and figure out what the problem was before they could see how it could be solved.

Y. Open Policy Hour

Need for Support of IP Connectivity in RIPE Policies

Alexander Isavnin

This presentation is available here:
https://ripe77.ripe.net/presentations/82-IPConnectivitySupport.pdf

Juri asked what the correct place was for these kinds of discussions.

Erik said he didn’t think Address Policy was the right WG and suggested they talk to their colleagues from the RIPE NCC’s External Relations Department and the RIPE Chair about how to have this discussion and whether it was appropriate for RIPE to be a part of this. But they were here now so they might as well have the discussion.

Alexander said if they took the African shutdown policy, it was completely about IP addresses. He wasn’t sure they should take this approach. They had the Connect WG, but this was more about technology rather than policy, so he thought they could start the discussion here.

Stephan Wahl, Megaport, said if they asked countries to sign something, they would want something in return and he was afraid this would get them into a discussion that they didn’t want to have here. If this discussion was going to be had, it should be at a European or country level.

Alexander said it was not possible to have the discussion at a country level. As he had said, countries that broke connectivity were usually well known for human rights abuses as well, so discussions within these countries were meaningless.

Stephan said there were so many questions Alexander couldn’t answer – such as what kind of sanctions he would suggest, or what checks would be needed.

Alexander said he didn’t want to propose any sanctions.

Stephan said in that case they didn’t need this paper – without sanctions it wasn’t practical.

Alexander said they had one possible sanction – if a country did not need to provide Internet connectivity then it did not need Internet resources. But he was not proposing anything here.

Malcolm Hutty, LINX, said the Cooperation WG specialised in these types of discussions and would be meeting tomorrow. He added that if Alexander was proposing that the community should use its consensus policy mechanisms as a sanction against internal legal policies of countries that they disliked, this would create an adversarial stance in which the RIPE community was unlikely to prevail. He suggested that rather than looking for sanctions, they could look at alternative solutions – perhaps a more cooperative or persuasive stance, which was where the Cooperation WG got its name from. He might also consider the IETF, which was against pervasive surveillance. It had not said it would kick anyone out – but instead that it would develop technologies that aligned with its values of allowing people to communicate. He didn’t know if this would be applicable to the RIPE community, but it might be better than a sanctions-based approach. Finally, he thought that Alexander should distinguish between two aspects – one was governments interfering with the Internet of their own country, where they had legal authority; another was countries that interfered with the Internet beyond their borders, where they did not have sovereignty and harmed third parties that weren’t under their jurisdiction.

Sander said they were a technical community – fighting governments was not something they could win. They didn’t have black helicopters and cool stuff like that. He appreciated the harm that was being done in Alexander’s community, but if they started this fight they would lose, and would lose the RIPE community along with it.

Alexander said if they took this approach they had already lost the battle. In Russia they had taken the same approach: “We are a technical community, we should do something else” – but something else didn’t work. If their primary concern was not to anger governments then they had already lost. He wasn’t talking about fighting anywhere. But they were being abused by governments that took the outcomes of the RIPE community for their own benefit but did not share their values.

Sander said he wanted to reiterate Malcolm’s point that the community had no rights to interfere with the ability of a sovereign community to make policy within its own borders. This had to be solved locally and there was nothing they could do.

Alexander said in the case of Europe, there were pan-European structures that states often agreed to follow (e.g. European Court of Human Rights) that affected what they did within their borders. While the RIPE community was not like a governmental association, it was nevertheless one of the “governance” associations of the Internet. If not them, then who else?

Lee Howard, Retevia, said slide 11 suggested they ask governments to sign a binding agreement. The problem was that an agreement was only as binding as it was enforceable, and they couldn’t wield the whois as a weapon. Another concern was that his own country (United States) shut down the Internet for valid reasons, in the case of child porn or gambling sites for example.

Alexander said they were talking about shutting down infrastructure rather than content, because this affected the global Internet. In the case of child porn, it was better to go after the perpetrators rather than blocking the whole ASN.

Lee said when dealing with global command and control systems for botnets, the best approach was often to shut down routing. He didn’t want to take away a valuable tool from governments that might need to stop something, and he didn’t think they wanted to distinguish between good and bad, because different groups had different ideas about what this was.

Alexander said he wasn’t deciding what was good and what was bad. But as he had referenced in an earlier slide, one of their foundational documents (ripe-001) had stated they were about IP connectivity.

Aftab asked for clarification. He said there was a contract between an LIR and the RIPE NCC. If an LIR blocked a prefix to its customers, was he in breach of contract?

Alexander said that depended on what was in the contract. When talking about commercial contracts, you could usually find another LIR. When government enforced something, it wasn’t easy to resolve this through negotiation or by choosing another government. If you were in the EU, you could always move to another country – but this wasn’t the case for many other countries.

Aftab said he wanted to stay on the RIPE NCC and the contract. Governments did not control transit or routing – you went from LIR to LIR to LIR. He asked again if he would be in breach of contract if he blocked a prefix. This was a matter they could discuss here – he didn’t think they could discuss anything else beyond this.

Alexander said when talking about resource allocations of the RIPE NCC – IP resources could be used in private networks without global routing. So here it might not be breach of contract.

Erik said they would need to cut this discussion because they were out of time. He said they could take this offline and suggested Alexander talk with Malcolm about taking this up with the Cooperation WG.  

Z. AOB

There were no AOBs.

End of second session.