RIPE 88 Address Policy Working Group Minutes
Session 1
Wednesday, 22 May 2024 09:00 - 10:30 (UTC+2)
Chairs: Erik Bais, Leo Vegoda, Alex le Heux
Scribe: Adonis Stergiopoulos
Status: Draft
Session 1 Chat Transcripts
Session 2 Chat Transcripts
A. Chair Selection
Leo Vegoda opened the session, introduced the Working Group Co-Chairs and thanked the Stenographer and Scribe. The minutes from RIPE 87 were approved. There were two seats up for selection, and Erik has been re-selected for two years while Alex for three years.
B. ASO AC Update
Herve Clement
Malcolm Hutty (LINX London Internet Exchange) asked where more information can be found while this is being developed in advance of the public consultation. Herve replied that information is available on the ASO website and they are considering creating a document with all this information.
C. Registry Services Update Followed by Q&A
Marco Schmidt, RIPE NCC
Gert Döring (SpaceNet AG) noted that obtaining an IPv6 allocation should be easy to align with the IPv6 policy goal of not hindering IPv6 adoption. He noted confusion created around the distinction between a member and an LIR and that this needs clarification. The focus should be on making obtaining IPv6 allocations easier for LIRs.
Jan Zorz (6connect) commented that he had noticed this hoarding of IPv6 prefixes for years and asked if Marco’s policy application moving forward also applies to LIR mergers. Marco confirmed that they did and that they would look into it.
Sander Steffann (independent) voiced concerns about the financial and operational implications of members bypassing RIPE NCC by acquiring IPv6 addresses through secondary markets, suggesting that this could undermine the membership model.
Brian Nisbet (HEAnet) asked if anything can be done for the address space that has already been taken. Marco reassured Brian that they would also look into this.
Peter Hessler (Zayo Europe) asked if there are any insights as to why these customers would go to these third-party entities for address space instead of the RIPE NCC and if there is an intention to misuse this space. Marco answered that they do not have insights on this matter and the individual members can answer this only. Peter added that the Working Group should look into the reasons why people would go to other sources to avoid issues such as stockpiling.
Jordi Palet Martinez (The IPv6 Company) added that they should consider if the transfers should have justified need verification, otherwise it will not be as easy as presented. In some cases, some members go through this path because they cannot request larger allocations. Jordi continued that a few of them have put forward a policy proposal that the Chairs did not allow to go through. Marco replied that the current policies allow a valuation for a subsequent allocation, therefore transfer allocations will also be treated the same way. Jordi answered that he did not consider that it applies to existing allocations and transfers as it contradicts the transfers policy.
Erik Bais added that they have looked at the policy, and particularly the transfers as a subsequent allocation, and this is already in place and it is the reason the RIPE NCC is requiring documentation on that.
Sander Steffann (independent) noticed that the stockpiling is occurring in countries that are also under sanctions, and asked if there is any indication that this mechanism is used to bypass sanctions. Marco replied that they would like to look into this matter further.
Jan Zorz (6connect) commented on Jordi’s point that the initial allocation for the LIR is /29 without additional documentation. If the LIR receives more space, this might explain why they need it.
Maximilian Emig (UNIBERG GmbH) asked via chat if they will use large assignments from LIR to end users. Marco replied that yes, they have the auth procedure and the possibility to do so.
Tobias Fiebig (MPI-INF) asked if they do the needs assessment before completing incoming IPv4 transfers. Marco replied that transfers are only completed if the policy requirements are met. Tobias asked if they rejected any IPv4 requests and Marco said no and that this is something they are working on now. Erik Bais added that there is a need for requirements for inter-RIR transfers, not for IPv4 regional transfers.
Elvis-Daniel Velea (V4EScrow, LLC) asked via chat what will stop entities from opening an additional LIR and getting an IPv6 allocation for that LIR, and so forth. Brian Storey (Gamma) asked via chat what timelines are they suggesting to solve this problem. Marco replied that they will need to adjust their internal procedures first and then take it from there.
Marco continued his presentation and provided an update on ASN requests. Sander Steffann (independent) mentioned that he would like to see a solution where people can get easy access to ASNs, but also attach some charge to an ASN, to avoid overwhelming the RIPE NCC. He continued by expressing his support for the RIPE NCC to have a stronger role in policy proposal initiation.
Tobias Fiebig (MPI-INF) highlighted the issue of LIRs not taking their responsibilities seriously when sponsoring ASNs, suggesting that more emphasis should be placed on ensuring LIRs mentor their end users properly. He proposed that policies should put more responsibility on LIRs rather than end users. Marco agreed and suggested this would be put forward to the Working Group Chairs.
Peter Hessler (Zayo Europe) inquired about the regional limitations for ASN assignments, questioning whether resources should be assigned to users outside the RIPE NCC region and whether that is out of the scope of the policy. Marco responded that the current policy requires ASNs to be used within the RIPE NCC region, but admitted that ensuring compliance is resource-intensive.
Mirjam Kühne (RIPE Chair) emphasised the importance of the RIPE NCC playing an active role in policy development, whilst maintaining a balanced approach that benefits the RIPE community rather than itself.
Emil Petersen (independent) asked for more guidance on allocating requests correctly. Marco thanked Emil and acknowledged the difficulty of acquiring resources with ease whilst avoiding potential abuse.
Jordi Palet Martinez (The IPv6 Company) commented via chat that the RIPE NCC should also work in policy proposals. Maximilian Emig (UNIBERG GmbH) asked via chat whether the RIPE NCC monitors the DMZ for unused or single-homed ASNs. Marco replied that they do not due to a lack of resources.
Elvis-Daniel Velea (V4EScrow, LLC) asked via chat about the ASN issue and whether a change in policy would affect this. Marco replied that this is for the Working Group to discuss. Elvis-Daniel also mentioned that the RIPE NCC should be careful about the PDP process as it does not want to be perceived as the one writing the rules it needs to follow. Marco agreed and it is the reason he decided to make this an open question to the community.
D. Policy Update
Angela Dall'Ara, RIPE NCC
There was no time for questions.
E. IPv6 PI Policy
Tobias Fiebig (MPI-INF)
Peter Hessler (Zayo Europe) asked based on Tobias’ proposal, whether an assignment of two /48s PI for two separate projects would fall under a 48 with a 44 reserved for each of them or a single 44 with a 40 reservation for this. Tobias replied that he would consider this one 44 from which two 48s can be used, however there are several options and a trade-off between operability versus simplicity.
Sander Steffann (independent) thanked Tobias for all the hard work he had put into this.
Jan Zorz (6connect) also thanked Tobias and asked whether End Sites should be defined beyond this document and into a global level. Tobias agreed and asked Jan to send his contribution in writing.
Benedikt Stockebrand (independent) added that defining an End Site is by saying what it is not, and he can find some documentation from a few years ago. Tobias would also look at the current text as it revolves a lot around unique routing policies.
Maria Matejka (independent) agreed on the need to define an End Site and whether this should be relevant to allocating too little or too many addresses. Tobias replied that he sees the need to define an End Site for operational bodies such as the RIPE NCC, but also use the slightly extended version for the purposes of this document and move the exact definition of an End Site to a different policy proposal.
Maximilian Emig (UNIBERG GmbH) asked via chat if extending a 46 would be possible without renumbering. Tobias mentioned that there is a provision about renumbering in the document and this would depend on the different scenarios.
Peter Hessler (Zayo Europe) added to the need for simplicity in the definition of an End Site in this proposal. Thereafter, a much more specific one can be used for general use that would be incorporated into all the other documents as a separate document. Tobias agreed.
End of the first session.
Session 2
Wednesday, 22 May 2024 11:00 - 12:30 (UTC+2)
Chairs: Erik Bais, Leo Vegoda, Alex le Heux
Scribe: Alun Davies
Status: Draft
G. PI Policy Simplification
Remco van Mook
Cynthia Revström (Itnord Security Solutions AB) agreed there were too many different IPv4 statuses in the RIPE Database but recommended keeping LEGACY as it helps with certain use cases. Remco van Mook responded that information about legacy is available in other places and that a table of what is legacy today should suffice since it's not going to change in the near future.
Peter Hesler (Zayo Europe) asked whether public access to information about certain features of blocks (e.g., anycast) was beneficial and whether the suggestion was to hide this info from the public or make it a different field in the Database. Remco responded that keeping corner cases because they were once special is not beneficial, and removing them wouldn't cause significant loss. Peter added that there might be technical issues in implementing changes, as seen with the recent approval of NWI4, and these should be checked with RIPE NCC staff.
Tobias Fiebig (MPI-INF) noted that transfer policy refers to some of these features of address blocks and added that legacy does not have to remain static. He questioned how to categorise an inetnum object created in legacy space and suggested that legacy holders might feel targeted by these changes.
Nick Hilliard (INEX) raised concerns about the proposal, indicating a lack of clarity and potential misleading elements. He emphasised that specific terms like ASSIGNED PI and ASSIGNED PA hold significant meaning and should not be conflated. Remco clarified that the proposal aimed to simplify database structures without altering current policies, which might be necessary for future contractual adjustments. Despite this explanation, Nick expressed that he was still unclear about the proposal's implications and stressed the need for a more precise understanding of its objectives and potential consequences.
Erik Bais read out an online question from Elvis Velea (V4Escrow, LLC) who asked whether all PI holders must become LIRs under this proposal. Remco clarified that this was not part of the proposal. Erik added that this is about statuses in the database, not contracts.
Sander Steffann (S.J.M. Steffann Consultancy) expressed agreement with Nick Hilliard's concerns, questioning the direction of the proposal. Sander highlighted that separating and simplifying data categories could have operational impacts, particularly on transfers, and could reduce the visibility of important contextual information. He acknowledged understanding the intent but did not see it as the right solution. Remco suggested that the necessary context would remain apparent from the database structure but noted Sander's concerns.
Peter Hessler revisited his earlier points, emphasising he was not opposed to the problem statement and acknowledged it as a significant issue to address. Peter stressed the importance of ensuring that any new policies created should have minimal impact on future charging schemes. He also highlighted the need to maintain reasonable freedom for the RIPE NCC and its members. Remco thanked Peter for his input.
Mike Burns (IP Trading) noted the frequent use of the LEGACY field in transfers, explaining that at ARIN, the LEGACY status does not appear in the Whois database. For brokers, determining LEGACY status is crucial due to different transfer rules. ARIN addressed this by creating a separate accessible database for legacy blocks. Mike warned that without such a field, brokers would need to frequently contact RIPE NCC to verify statuses, as clients often do not know. Remco acknowledged this workaround as elegant and thanked Mike for the suggestion.
Matthias Wichtlhuber (DE-CIX Management GmbH) raised concerns about removing the ASSIGNED ANYCAST category, pointing to the difficulty in identifying anycast in measurements and the value of any information available. He urged against making anycast data less visible. Remco responded that out of the millions of ASSIGNED PI inetnums, many are anycast, and having a small designated section for anycast might be misleading. Matthias suggested that even a sample of identified anycast addresses is useful for studies. Alex Le Heux added that in practice, anycast space is not typically marked as such in databases.
Tobias Fiebig (MPI-INF), speaking as a researcher, supported Matthias's point about the importance of identifying anycast in measurements. Tobias highlighted that having a small, reliable set of networks identified as anycast can be used as roundtrips to help identify other anycast networks not clearly marked. This sample serves as a valuable reference for conducting accurate measurements and studies.
Stefan Wahl (Route 128) expressed issues with explaining the different terms listed earlier, mentioning the confusion caused by small and large letters, double S, and single S. He suggested that simplification could provide more freedom and proposed creating a special database for legacy information or anycast, possibly a global one. Stefan believed that simplification could give more freedom to discuss the future of RIPE.
Elvis Velea asked (online) what holders of ASSIGNED PI would hold if the proposal were approved. Remco clarified that the status would simply be ASSIGNED. He emphasised that the distinction in the status field would be either ALLOCATED or ASSIGNED. Remco noted the existence of an AGGREGATED status, which he found problematic.
Angela Dall'ara (Policy Officer at RIPE NCC) provided further clarification. She noted that, according to the proposal, there would be two main categories: ALLOCATED and ASSIGNED. ASSIGNED would be the final stage of assignment, indicating that the holder would be the user. Remco clarified that ASSIGNED is a stub, while ALLOCATED can have leaves. Angela pointed out a correction regarding the AGGREGATED-BY-LIR status, explaining that it allows for child assigned PA statuses (e.g. in IPv6). She emphasised that syntax and allocation could be arranged. Remco agreed and acknowledged the complexity, expressing confidence in Angela's understanding and the detailed work required in drafting the proposal.
Radu Feurdean (FRANCE-IX) raised concerns about the proposal to categorise statuses as only ALLOCATED and ASSIGNED, emphasising the need to identify who performed the assignment. He noted that currently, the status indicates if it was the RIPE NCC or an LIR, with the latter often being less reliable. Erik Bais responded, explaining that a parent block can always be identified, even if an LIR assigns the space. Radu acknowledged this but pointed out complications with global coverage and other RIRs.
H. ASN Assignment Issues
Radu Anghel, TU Delft
Peter Hessler (Zayo Europe) shared his experience as a member of the OpenBSD project, explaining his use of two ASNs for separate routing policies. One ASN is used for a server and hosting information, while the other supports a BGP routing daemon project. He noted that OpenBSD, as a non-profit, lacks the assets to manage these resources directly, necessitating personal assignment.
Cynthia Revstrom (Itnord Security Solutions AB) highlighted the importance of personal ASNs for learning and entering the networking community, arguing that hands-on experience is far more effective than reading. Radu Anghel countered by suggesting alternatives such as BGP courses and private ASNs, asserting that creating parallel Internets over tunnels isn't beneficial.
Savvas Kastanakis (Lancaster University) pointed out the potential for a business opportunity in acquiring ASNs, likening it to the IPv4 market. Erik Bais (WG-Chair) stepped in to respond, explaining there are limitations and requirements imposed by RIPE NCC to prevent such exploitation. Marco Schmidt added that both individuals and companies must meet the same stringent requirements. He also noted the high workloads involved.
Tobias Fiebig (MPI-INF) stressed the issue of irresponsible LIRs promoting vanity resource use, suggesting that RIPE NCC enforce more responsibility and costs on these LIRs. Another speaker emphasised the value of personal ASNs for learning and experimentation, proposing a two-year usage requirement to prevent resource wastage.
Urban Suhadolnik (TU Graz) explained that having an ASN significantly shaped his career as a network engineer, enabling him to undertake various projects and experiments. He argued that the current €50 fee for an ASN is reasonable and that increasing it to the RIPE NCC membership cost would be counterproductive. He also highlighted that in large companies few people request personal ASNs, and noted the difficulty in obtaining ASNs through universities or companies, advocating for maintaining the current system which operates on a bottom-up principle. Finally, Urban suggested imposing a usage requirement to ensure ASNs are not wasted. Radu responded by asking whether a company would be more motivated if all its employees got AS numbers.
Peter Hessler noted the need to consider valid non-visible ASN usage, like for IXPs and MPLS VPNs, in policy changes. Radu Feurdean (FRANCE-IX) suggested revising the definition of unique routing policy to include globally unique AS numbers used in non-public contexts.
Alex Le Heux (WG-Chair) clarified that the Internet comprises many internets, each unique to its users, affecting the visibility and uniqueness of ASNs. Tobias Fiebig shared his experience of becoming an LIR after leaving TU Delft, noting the importance of responsibility among sponsoring LIRs.
An online question from Carlos addressed the ease of acquiring ASNs and its cost impact on real operators. Antonio Prado (SBTAP) suggested a testbed similar to 6bone for IPv6 experimentation. Radu Anghel noted that 6bone required RIPE NIC handles for participation.
Cynthia Revström argued that real Internet access was necessary for learning IPv6 at home and questioned other arguments against personal ASNs beyond workload concerns. Radu Anghel suggested using Hurricane Electric tunnels instead of personal ASNs, which the speaker found unworkable due to address deallocation issues. Urban Suhadolnik compared learning BGP to other fields where hands-on experience is permitted, such as amateur radio, advocating for similar opportunities in networking.
Peter Hessler warned against repeating the IPv4 issue of resource depletion due to lax distribution, advocating for reasonable barriers to prevent waste while allowing genuine learning and development. Sander Steffann expressed doubts about the operational problem being solved by the proposal and was not convinced it should move forward. Erik Bais closed the session, inviting further comments on the mailing list.
I. Getting Useful Input from Government-Adjacent Organisations
Leo Vegoda
Brian Nisbet (speaking as Anti-Abuse Working Group Chair) emphasised the necessity for the community to reinvigorate its relationship with law enforcement, which had weakened over time. He highlighted the previous stronger engagement and noted current problems resulting from this disconnect. Brian expressed a desire to enhance collaboration within the Anti-Abuse group and across the community.
Erik Bais acknowledged Brian's points and discussed the need to keep up with evolving requirements from various legislative acts like the DSA and e-evidence discussions. He stressed the challenge of getting timely input from law enforcement within the policy development process and the importance of finding ways to integrate their contributions transparently.
Peter Hessler voiced concerns about the potential for law enforcement to dominate policy-making processes. While he appreciated the inclusiveness, he cautioned against giving law enforcement too much influence and stressed the importance of maintaining transparency.
Mirjam Kühne (RIPE Chair) agreed that it was a good discussion to have and emphasised the importance of establishing communication channels and dialogue with non-traditional stakeholders like law enforcement. She noted the need to explain RIPE's processes to these stakeholders while recognising their constraints and working together to deepen the community's responsibilities in this area.
Andrei Robachevsky (Global Cyber Alliance), speaking for himself, sought clarification on whether these discussions implied changes to the PDP or were about informal information exchanges. He stressed the importance of defining how different stakeholder groups can be involved in the policy development process, which traditionally focuses on individual participation.
Erik Bais responded that there were no current plans to change the PDP. He acknowledged that some stakeholders, including large organisations, might have constraints on speaking publicly and emphasised the importance of engaging these groups without forcing changes to the PDP.
Brian Nisbet reiterated that previous engagement with law enforcement had been effective without compromising community values. He stressed the importance of re-engaging with law enforcement to gain useful input without altering the existing structures.
Leo Vegoda highlighted the inevitability of personnel changes in organisations and the need to re-explain processes continuously. He emphasised that the goal was not to propose significant changes but to solve practical problems and gradually improve engagement with law enforcement. Leo assured the group that there were no plans to abandon transparency or change the PDP but to acknowledge the need for better engagement publicly.
Brian Nisbet concluded by noting that the issue of maintaining relationships with law enforcement was not unique to RIPE and stressed the importance of ongoing efforts to re-engage effectively.
J. Open Microphone
Leo Vegoda
Sander Steffann discussed the limited use of the transfer log, noting that only two LIRs, including himself, had tested it. He described a scenario where he tested the system by logging a resource that was meant to be returned to the NCC to see the response. He highlighted the potential wider application of the transfer log, especially for enterprises like banks that may benefit from additional security measures against administrative errors or malicious actions. Sander invited others to join him in raising awareness about the transfer log's benefits.
Erik Bais shared his experience with the transfer log, noting the process's lack of visibility and the need to open a ticket in the LIR portal to use it. He pointed out that the resources under transfer lock are not visible in the RIPE Database, only on the transfer lock statistics page. Erik suggested reevaluating the system in a year or two, given its current low usage, and encouraged those with legitimate use cases to engage with the NCC. He mentioned that the process, although considered lengthy by some, was manageable based on his experience.
Peter Hessler asked Marco Schmidt about the workload impact on RIPE NCC when processing transfer lock requests. Marco confirmed that while there are checks to verify the legitimacy of requests, the process is manageable and not overly burdensome. He echoed Sander's sentiment that there could be valuable use cases for the transfer log and welcomed requests from organisations looking to protect their resources.
Sander Steffann added that many potential users of the transfer log might be unaware of its existence because they do not participate in the Working Group or attend meetings. He agreed on the need to reevaluate the system but stressed the importance of giving it enough time for awareness to spread among operators.
End of the second session.