[address-policy-wg] Draft Address Policy WG Minutes from RIPE 85

Dear WG,

The RIPE NCC has now prepared draft minutes of our session at RIPE 85.

Please write to this list or inform the co-chairs of any issues or corrections.

Kind regards,

Leo Vegoda
for the Address Policy WG co-chairs



RIPE 85 Address Policy WG Minutes
Wednesday, 26 October 2022, 09:00-10:00 UTC+1
Chairs: Erik Bais, James Kennedy, Leo Vegoda
Scribe: Antony Gollan
Status: Draft

A. Introduction

The presentation is available at:
https://ripe85.ripe.net/wp-content/uploads/presentations/64-RIPE-85-Address-Policy.pdf

The video is available at:
https://ripe85.ripe.net/archives/video/898/

There were no changes to the agenda.

The minutes from RIPE 84 were approved without changes.

B. ASO AC Update
James Kennedy, ASO AC

The presentation is available at:
https://ripe85.ripe.net/wp-content/uploads/presentations/72-ASO-AC-Report-RIPE85.pdf

The video is available at:
https://ripe85.ripe.net/archives/video/901/

James Kennedy gave an update from the ASO AC. Kevin Blumberg from the
ARIN region was their new Chair. Kevin had appointed Mike Silber
(AFRINIC) and Herve Clement (RIPE) as Vice Chairs.

There were no questions.

C. Policy Update Followed by Q&A
Angela Dall'Ara, RIPE NCC

The presentation is available at:
https://ripe85.ripe.net/wp-content/uploads/presentations/59-RIPE-85-Current-Policy-Topics.pdf

The video is available at:
https://ripe85.ripe.net/archives/video/902/

Angela ran through open policies in the five RIR service regions. In
the RIPE region, there were two: 2022-01: Personal Data in the RIPE
Database (Database WG) and 2022-02: Remove mandatory IPv4 PA
assignment registration in the RIPE Database (Address Policy WG).

Jordi Palet Martinez (online), Moremar, noted all of the APNIC
proposals would get a new version soon.

D. (2022-02) Remove Mandatory IPv4 PA Assignment Registration in the
RIPE Database
James Kennedy, Address Policy WG co-chair

The presentation is available at:
https://ripe85.ripe.net/wp-content/uploads/presentations/73-2022-02.pdf

The video is available at:
https://ripe85.ripe.net/archives/video/905/

James said that the proposer (Jeroen Lauwers) could not be at the
meeting and so he would run through the proposal quickly for him. He
added that he would be recusing himself as WG co-chair from
determining consensus on this proposal. James’s interpretation of the
intent of the policy was that it sought to allow LIRs to document only
information in the RIPE Database that was needed for operational and
administrative purposes, and to reduce workload by not forcing them to
maintain duplicate data.

Sander Steffann, 6connect, said he agreed that everything visible
externally should be documented in the RIPE Database. That was an
absolute minimum. However, he thought they already had this – if it
was externally visible there would be a ROUTE object, in which case
there would have to be an INETNUM object it pointed to.

Erik Bais, Address Policy WG co-chair, said for the allocation there was not.

Sander said then he would definitely put that in as a minimum
requirement. For the rest, it was a contact database – so that if
something went wrong, people could see who to contact and who was
responsible. If the LIR was willingly taking responsibility to be the
contact for all its customers, that was a business decision, and they
should allow for that.

Kurt Kayser (online), speaking on his own behalf, asked if the logic
was correct that routed = used, and that it if was not assigned, it
was not shown as used.

Erik said this played into the comment from Sander. When were they
going to say the address space was in use? Was it when there was a
valid ROUTE object or when there was a valid assignment?

James said, on that point, maybe the ROUTE object was created before
being used. But a quarter of all allocations was an interesting
number.

Elvis Daniel Velea (online), v6escrow, said he supported the intent of
the proposal. Assignments should only be registered if required by the
End User or if the LIR wanted to delegate some
administrative/abuse/routing decisions.

Peter Koch, DENIC, said he had been a member of the RIPE Database
Requirements Task Force. The TF report made a distinction between the
RIPE Database and the RIPE Registry. He thought the differences and
commonalities here weren’t reflected in the proposal in a way that
would help with making a decision. Further, while the author pointed
towards the TF report and its recommendations, he didn’t think the
proposal reflected the corresponding recommendation. That was fine,
because it didn’t have to, but he wanted to avoid the impression that
this was a proposal to implement what the TF recommended. It did make
a recommendation on the assignments, following the observation of an
asymmetry in terms of depth and volume of usage by various LIRs and,
as someone had said on the mailing list, maybe a policy wasn’t the way
to change that.

Peter made a further observation. The RIPE Chair Team had, after
consultation and with the community’s support, offered clarification
to the PDP. That clarification had strongly suggested that policy
proposals should be the result of in-depth discussion. This proposal
seemed to come out of the blue, and so he would urge the chairs to
think about their gatekeeping and steering function.

Finally, Peter didn’t think this proposal was getting anywhere.
Unfortunately, the PDP’s was biased towards stumbling forward, and so
he would suggest putting an end to the proposal and considering the
problems identified in the subsequent discussion.

Erik noted that the intent for creating the proposal was discussed at
RIPE 84 in Berlin and the proposal was only created later.

Peter said that since Berlin there had been little discussion on the
list that would support the general direction of the proposal and the
problem statement that needed to be fixed. A couple of people had
mentioned their own surprise at seeing the proposal and two or three
had said it did not seem to be addressing the problem it sought to
fix.

James said he thought the proposer had tried to get as much feedback
as possible at RIPE 84, but he took Erik’s point that it could have
been progressed further on the mailing list. James added that he had
been on the Database Requirements TF with Peter and their
recommendation had inspired this proposal, but it was definitely not
one-to-one.

Brian Storey (online), Gamma, asked if the intent of the proposal was
to no longer require the registration of any downstream End User PA
assignments.

James said he could only give his own interpretation. The current
policy text said that for any assignments it should be optional. But
from the feedback Jeroen had received over the past few weeks, and
from his discussions with him, he was taking that into account. So,
the intent seemed to have changed since then.

Erik said as chairs they had looked at all the comments on the mailing
list. If this was moving forward, they would need to have a discussion
with Jeroen about whether it was for all assignments or just for the
resource holder of the allocation, which would probably make more
sense.

Kurt said he would split the main purpose of the documentation between
customer data (mainly assignments) and network operator related data
(such as abuse-c and admin-c). RIPE NCC needed both datasets before
but now the (very sensitive GDPR-Data) purposes may allow a different
handling.

Erik said this was not a GDPR topic. Yes, they were trying to minimise
the duplication of data. If the assignments were the same information
as the resource holder, then they shouldn’t need to duplicate it. But
if you were adding different information with different parties and
contacts, then that should still be in the database. At least that was
how he read it.

Erik and James encouraged people to share their opinions on the mailing list.

E. Registry Services Update Followed by Q&A
Marco Schmidt, RIPE NCC

The presentation is available at:
https://ripe85.ripe.net/wp-content/uploads/presentations/66-RIPE85-Feeback-from-RS.pdf

The recording is available at:
https://ripe85.ripe.net/archives/video/907/

Marco gave an update from the RIPE NCC’s Registry Services Department.
He had three topics he wanted feedback on:

1. IPv4 Waiting List: they now had about 1,050 LIRs on the waiting
list and the estimated wait time was now about two years. There were
still multiple-LIRs being created, which disadvantaged newcomers. He
asked if the WG wanted to accept this or if they should try to fix it.

2. IPv4 IXP Pool: the addition of a further /16 to the pool for IPv4
IXP assignments had drastically extended its lifetime. They expected
this pool to become empty around 2029. He asked if that was enough.

3. Assignment Definition: the policy referred to assignments made to
‘downstream networks’ but later referred to ‘End Users’. He asked if
these terms needed further definition by the WG.

Shane Kerr, NS1, responded to the question about the IXP pool. This
policy had been created so that IXPs wouldn’t have to go to an LIR.
Now that they were out of space, he asked why they wouldn’t buy
address space like anyone else.

Marco said he thought this was about seeing IXPs as critical infrastructure.

Shane said everyone thought their own infrastructure was critical.

Sander said he’d been around since the beginning of the run-out
policies. The fact that they still had some IPv4, even with a waiting
list of two years, was an achievement which meant their policies had
worked well. By now, they had extended this for so many years and
given people many opportunities, but at a certain point they needed to
say that they had properly arranged the deck chairs on the Titanic.
Regarding IXPs, Sander thought they did have an important role and
they should keep a separate pool for that. Maybe they could have a
policy that used some of the recovered IPv4 space to top up the pool
when it reached a certain level. He suggested they try a proposal that
would allow the RIPE NCC to manage this without an intervention from
the WG every time.

Erik said they would need input from the Connect WG on this policy,
and how it saw the prospect of this pool running out in seven years.

Sander said he would attend the Connect WG session later that day and
raise the topic there.

Regarding the definition of assignments, Sander said he could vaguely
remember this being discussed a long time ago; they had tried to keep
it vague since there were many ways of providing a service to a
customer. They had intentionally avoided going into what that service
could be, as they would be stuck chasing reality. They did put in that
there had to be some relation, and so he thought the RIPE NCC could be
a bit stricter, but that would require a very long policy process to
define what that meant.

Elvis (online), suggested they not get into the leasing discussion.
Since forever, LIRs in the RIPE region had assigned either PA or PI to
connecting customers or customers that offered all kind of services
and the colors of the IPs hadn’t really mattered.

Denis Walker, Database WG co-chair, said he had a comment on leasing.
What they had now was a situation where someone with spare address
space was asking third-party companies to lease it out on their
behalf, which might go to an LIR that saw it more as an allocation and
assigned it to an End User. None of this could be reflected in the
RIPE Database, because this whole structure that was hidden from view.
If they were going to allow leasing, they should document it properly.

Riccardo Gori, IP4WISP, wanted to go into the definition of LIR. He
interpreted this as ‘Local Internet Registry’ in the same way as an
RIR was a regional registry. He didn’t find a strict relation between
the LIR and the services that were operated. Often the resources were
associated to access offered by an operator to an Internet Service
Provider or in a data centre. So, he didn’t see much need to go deeper
into the definition of an LIR because it should reflect the fact that,
as the comment before said, it should give the right description in
the RIPE Database where the resources were being used and who was
using them. If this was consistent and correct, then in his opinion it
was done.

End of first session.

F. IPv6 Policy Goals - Review Process (Community Input Sought) [15 minutes]
 Leo Vegoda, Address Policy WG co-chair

The presentation is available at:
https://ripe85.ripe.net/wp-content/uploads/presentations/81-IPv6_at_RIPE-85.pdf

The recording is available at:
https://ripe85.ripe.net/archives/video/910/

Leo noted that they’d started a discussion at RIPE 84 to look at the
goals of the IPv6 policy, which hadn’t been reviewed for many years.
He asked if they wanted to adjust the policy goals, change their order
of priority, or introduce new ones.

Erik said there had been a lot of updates on this topic since RIPE 84.
That didn’t mean that the issues raised were gone. He’d also had a
discussion with a Dutch ISP that had quite some issues, because they
actually planned to do IPv6 with /48s to their customers, but instead
they had to refer back to /56s because they couldn’t get the
documentation within a reasonable time period. This meant they had to
move ahead with a /29 instead of a /25 or /27.

Sander said he was part of the group that discussed all these IPv6
changes and the main thing was a steep jump in requirements and in
terms of documentation they needed a full-sized novel. He asked if the
RIPE NCC was still reserving three bits of adjacent address space for
future growth.

Marco confirmed that they were.

Sander said he had heard concerns from organisations that they would
have to come back and get de-aggregated blocks when they needed to
grow later. So this might help to address some of their concerns. This
wasn’t in the policy and was an implementation detail – so maybe to
alleviate some of this stress the RIPE NCC could make this a bit more
official and tell people that they had a reservation for when they
came back in the future.

Marco confirmed that they could extend all the way to a /26.

Erik said this meant they could take a gradual approach and they could
grow into their space.

Sander said there was a three-bit reservation. There was an issue with
older allocations, as they would be able to extend from a /32 to a /29
as opposed to others who could grow from a /29 to a /27. There might
also be the issue of LIRs who opted for a /32 rather than a /29 and
unknowingly limited themselves in the future.

Leo asked what kind of planning horizon was reasonable from the
perspective of a network operator in terms of growing to a larger
allocation. He also asked to hear from the RIPE NCC, as they were the
ones who would have to go back to IANA if they needed more address
space.

Sander said currently there was no official planning horizon and the
implementation detail was that there was a planning horizon of three
bits – so someone could grow up to eight times as large. He didn’t
want to micromanage the RIPE NCC – maybe they needed to put this in
policy or maybe they just needed to inform people what the current
operational procedure of the RIPE NCC was.

Erik said maybe the LIR could have some kind of first right of refusal
– so they could give the RIPE NCC notice that they were intending to
grow in the next three to five years so that the additional bits were
not consumed. This could be a lightweight way to do it.

Sander asked if this was more of an informational hint rather than a guarantee.

Erik said they would still need to do the documentation part.

Sander said his first preference would be to round allocation sizes to
nibble boundaries.

Erik said they couldn’t always, especially if they were running out
and would have to go back to IANA and ask for additional allocations –
IANA would ask why.

Leo said, from memory, one of the things in the global policy was that
reservations were considered use. But that didn’t mean they shouldn’t
manage things responsibly.

Marco Schmidt, RIPE NCC, said he wanted to confirm for the record that
they reserved an additional three bits for every IPv6 allocation. This
meant someone with a /29 had a reservation up to a /26, for a /26 up
to a /23 and so on. There were a few exceptions, for example
historical allocations of a /32 that were extended to a /29 and
couldn’t go further, and sometimes those who transferred their
allocations were unable to extend, but that was just a sidenote. This
approach had been used for a long time and it worked well. They could
do more to make sure that people were aware. They did things on a
case-by-case basis and sometimes would tell people that they might
start with a /29 so they could expand later if they needed to. They
could do this in a more consistent and formal way. They weren’t too
concerned about going back to IANA – the /12s they currently received
lasted for a long time.

Tina Morris, AWS, said nibble boundaries shouldn’t be such a concern.
They were using 3% globally of what had been assigned and it was
ridiculous to get these micro allocations when the whole point of IPv6
was to make things easier. When you assigned just part of a block, the
entire network planning was messed up – internally you could no longer
use nibble boundaries, could no longer make a good organisational plan
for your network. The whole point of IPv6 was to make things easier,
better, implementable, and if they didn’t make things workable for
organisations, then they were blocking the growth of IPv6 networks.

Elvis said the RIPE NCC already reserved three bits for larger blocks
and so he wondered why they were even having this discussion. The way
the RIPE NCC used the sparse allocation mechanism allowed allocations
to grow further.

Kurt said he would turn it around and define a nibble-boundary
routing-obligation to support small IPv6 routing tables. He hated
fragmentation and deaggregation.

Erik said this came back to the goals of the policy. Obviously, they
still thought that deaggregation wasn’t something they could fix in
the policy. They encouraged everyone to use BCPs and not announce all
their /48s. But if you looked at the IPv6 routing tables, it was 48%
/48s at this point.

Sander asked if there was interest in him drafting a policy proposal
to realign the policies with nibble boundaries. That would mean
changing a /29 to a /28 and asking the RIPE NCC to reserve four bits
to align it with the /24. Maybe it was time to be more ambitious than
to tweak this one bit at a time. He asked for a show of hands [but
only saw a couple of hands]. He said he would discuss further with the
chairs to see if there was support.

Erik said on the next video call that they would have on IPv6 they
would invite Sander and Gert to provide additional feedback. They
would also invite people from the RIPE NCC to explain what their
current operation was and where they stumbled on the current policy,
before they made any changes.

Daniel Karrenberg, Internet geek, asked why maintaining a low number
of prefixes was suddenly such a big problem. They had managed a much
bigger number in IPv4.

Erik said it was the fact that IPv6 prefixes were longer, and if you
started announcing every /29 in /48s, you got an explosion in the
routing table, so that’s why aggregation was a topic.

Mirjam Kühne, RIPE Chair, said she was happy to see the enthusiasm.
She was going to suggest they discuss this on the list before creating
a proposal, but she noted that Erik seemed to be suggesting this with
the interim call.

Erik agreed.

Leo said he thought this had been a useful discussion. Before leaping
towards a specific thing with nibble boundaries, he thought it would
be good to base this in the policy goals. If they could get clear on
that, it would help any discussions on the specifics to be more
productive, as they would know what they were trying to achieve.

Erik said that sounded reasonable.

G. Temporary IPv4 Assignments - Minimum Assignment Size
Leo Vegoda, Address Policy WG co-chair

The video is available at:
https://ripe85.ripe.net/archives/video/913/

Leo gave a brief summary of the topic. The RIPE NCC got requests for
temporary allocations for academic and research experiments that often
only needed a very small number of IPv4 addresses. The policy said
that justification was required for experiments in the same way as
anything else – meaning that if you were unable to justify 128
addresses or more, you did not get a /24. The question was whether
they needed a minimum allocation size for experiments, and whether
this should apply only to academic or research assignments, or if it
needed to be a more general thing – because if you needed to use an
assignment it had to be a /24.

Elvis (online) said /24 should be the minimum size for temporary
assignments, as it was unusable otherwise.

Erik asked if they needed to limit this to research or if it should be
for more general use. His personal feeling was that it shouldn’t be
limited to specific research as the IPv4 policy had a minimum size for
allocations and the policies should align. He said they would take
this back to the mailing list.

Edwin Verheul, SURF, said they liked that the RIPE NCC provided
temporary assignments – they used them for events and were happy with
that. One issue was geolocation. He wondered if certain /24s could be
limited to certain countries or regions so they didn’t run into
limitations in that department.

Erik said geolocation was going to be an issue when they ran into
leasing or temporary assignments. There might be an option where the
RIPE NCC could provide a geofeed. This could feed into the IP
databases that were doing geolocation. Otherwise, you could extend the
time that the addresses were in use – it typically took 6-8 weeks
before geolocation databases were updated unless you were willing to
do the legwork.

Marco said he was happy to hear the suggestion that they have a
minimum assignment size and he would like to see this discussed
further on the mailing list. For the RIPE NCC it was a pain point and
everyone thought it should change.

Erik said he would try to find someone to create a proposal.

Kurt asked if there was any usability guarantee after getting the
space back (getting it removed from spam blocklists and so on).

Marco said they did pick address space randomly and allowed a certain
quarantine time, but they didn’t check how ‘tainted’ the address space
was. They tried to give space that was as clean as possible and he
might contact Kurt to hear feedback on how his experience was.

Radu-Adrian Feurdean, FranceIX, asked if they should plan to gradually
phase out temporary allocations. Surely the message should be that
IPv4 was over and IPv6 was the way.

Elvis volunteered to author the temporary assignment policy proposal.

H. AOB/Open Mic

The video is available at:
https://ripe85.ripe.net/archives/video/914/

Sander said there was a message on one of the RIPE mailing lists from
Hans Petter Holen about Ukraine. This was about protecting the
resources of Ukrainian members from being transferred at gunpoint.
They had talked about this in Berlin, but it still seemed to be going
on. In his response to the Ukrainian Government, Hans Petter had
suggested they raise this in the Address Policy WG. He didn’t think
protecting members’ resources was a policy issue, but he was
interested to hear from the WG.

Erik said the WG chairs had discussed this issue. It wasn’t unique to
Ukraine, whatever they came up with should apply to other areas, such
as Palestine, Syria and so on. He added that there had been a
suggestion that people have some kind of ability to lock their
resources in the LIR Portal. Some kind of country-specific transfer
lock was not something he would envision. When looking at art [as a
parallel example], this was often stolen in war. What happened was
that the owners went to the court after the war and got their property
back that way. His personal thinking was that they should focus more
on the appeals side rather than finding a policy solution.

Max Tulyev, NetAssist, agreed that it should not be handled through
policy. He agreed it would be good to have a big red button that would
lock transfers for some period of time. A country-specific lock was
not an option. He added that there was government corruption within
Ukraine and he thought some kind of government approval for transfers
should not be used.

Erik said that one of the risks he saw – and he was sorry to state it
this way – was if a gun was pointed at a director of a company or
their family. Surely in this case the best response was to process the
transfer and get an appeal afterwards. That was the safest option for
everybody involved. However, that was his own opinion.

Max said they had some statistics that this had already happened in
the occupied territories regarding other types of assets (he didn’t
know of any cases involving IP resources) and they were killing people
after the transfer. Reversing transfers would also open a can of worms
as it could be open to abuse.

Erik said the process here was similar to cases of art, for example.
He added that there would be an update on this topic in the RIPE NCC
Services WG.

Olena Kushnir, WebPro, said they were a telecommunications provider of
critical infrastructure in Ukraine. Of course, they had LIRs that only
bought and sold IP addresses, and others who used these resources to
provide services. When the war started in Ukraine, businesses that
continued to work in the country were afraid that they would be put in
danger. Of course they would do everything to save their family and
their lives – but they were also afraid for their business and
resources. It was first of all a matter of cyber-security. It was also
a considerable amount of money that they could save [in terms of the
value of the resources]. They didn’t want influence from government in
their business, though she added that they had good dialogue with
government through many working groups. She noted that Max said he
didn’t know of any cases involving stolen IP addresses – she
referenced the case of FTcom which had transferred addresses to
Russian territory. She thought it was good to discuss changes to
policy and she was grateful for the opportunity to be present for the
discussion. She said they wanted to freeze all transfers until they
found some way to protect Ukrainian network operators, because they
were also part of the RIPE family.

Hans Petter Holen, RIPE NCC, thanked his Ukrainian colleagues for
attending the meeting and raising their concerns. What was happening
in their country was terrible and he wanted to be clear on that. He
noted that Athina would be presenting on this in the RIPE NCC Services
WG. They would need input from the community on this and would be
listening carefully to all of the input they received. And he
reassured them that no matter how they would go forward, the RIPE
NCC’s Board was intent on them taking timely action on the matter, so
he didn’t think they should let the policy path be prohibitive just
because of the timing, as perhaps the board could approve a temporary
measure until the policy was ready.

Artem Zurkov, no affiliation, said he was a provider from an occupied
territory. He thought there should be some kind of public log so that
if resources were locked, people would know that there was no ability
to unlock them. This could support people’s physical safety if people
with guns could see that this was the case. He supported Max’s
suggestion that they should have some way for people to lock resources
for a period of time.

Elvis asked Hans Petter for guidance from the RIPE NCC on what kind of
policy interventions would be needed.

Hans Petter said the transfer policies said that the RIPE NCC should
process transfers, but now they were suggesting that it shouldn’t
process some transfers… but the community wanted the RIPE NCC to
follow its policies. Clearly this could become complicated. He
encouraged people to attend the RIPE NCC Services WG services session
later that day to hear more on this.

Rüdiger Volk, no affiliation, said he wanted to raise a different
topic. He wondered whether the status field in the delegated extend
file as it was defined and operated by the RIPE NCC should get some
attention in the Address Policy WG. He noted that ISOC had reported
some confusion using the data and, as far as he could tell, there was
not really any clear documentation or attention to what was being done
in that file. A couple of years ago, people had said this was just
some statistics the RIRs were putting out and didn’t have much
meaning. At the time of RIPE 75, policy changes in RPKI provided
arguments that the delegated extended file actually had to be taken
seriously. At RIPE 78, he had reported operational problems with the
file, and he thought that if ISOC people, who were quite
knowledgeable, were getting confused, then this was something that
should be reviewed from a policy point of view.

Erik thanked Rüdiger for his feedback and said this was definitely a
discussion they needed to have on the mailing list, so they would need
some more feedback from him there.

End of second session.