[address-policy-wg] New RIPE Labs Article: "IPv6 Stockpiling: A Trojan Horse in Our Midst?"

[Marco Schmidt]

Dear colleagues,

Together with my colleague Rene Wilhelm, I have just published an 
article on the interesting phenomenon of IPv6 stockpiling and its 
implications for the Internet ecosystem in our region.


You can find the article here:
https://labs.ripe.net/author/marco_schmidt/ipv6-stockpiling-a-trojan-horse-in-our-midst/

During the Address Policy WG session at RIPE 88 next week, I'll be 
talking more about this trend and would love to hear your thoughts.


Kind regards,

Marco Schmidt
Manager Registration Services
RIPE NCC


--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status

[Marco Schmidt]

Hello,

First, let me note that this is not a comment on the policy discussion, 
which has now concluded, but a separate response regarding how we ensure 
compliance with RIPE Policy. We would like to clarify some aspects that 
may be unclear to the community.


The RIPE NCC has always emphasised the importance of documenting 
networks through assignments, and we are consistent in what we consider 
valid contact information for End User/customer assignments. This stance 
has not changed because of IPv4 runout. We do consider the member’s 
contact details to be valid contact information for the customer if this 
is what the member and their customer have agreed suits their business 
needs.


There are a number of policies we follow for ensuring correct contact 
information. The policy on IPv4 allocation, RIPE-804, requires that 
contact information in the database must be correct [1]. The same policy 
also mentions that an LIR can be closed if it “consistently violates the 
RIPE community’s policies” [2]. We build on this in our public closure 
procedure, where we state that incorrect registration in the RIPE 
Database can lead to termination of a membership [3].


Together, this means the RIPE NCC is empowered to close down a member 
for incorrect contact information in the database, and this includes 
incorrect data about a member’s customers. When we discover incorrect 
information, our practice is to follow a collaborative approach in which 
we help our members correct the errors. This is in line with our overall 
mission to support the broader Internet community, not through punitive 
measures, but through educating members in our processes for requests, 
ARCs and training courses so that we can collectively work to create an 
accurate registry. See also our impact analysis for policy proposal 
2017-02 (“Regular abuse-c Validation”) for a detailed description of how 
we work with resource holders to correct information before considering 
closure, in this case regarding “abuse-c:” contacts [4].


We do not consider it beneficial to the Internet community or our 
members to immediately terminate memberships. However, if a member 
submits repeated and intentionally incorrect contact information, this 
will result in stronger actions on our end.


Kind regards,
Marco Schmidt
Manager Registration Services
RIPE NCC


[1] IPv4 Address Allocation and Assignment Policies for the RIPE NCC 
Service Region: https://www.ripe.net/publications/docs/ripe-804/#4

[2] Idem: https://www.ripe.net/publications/docs/ripe-804/#9
[3] Closure of Members, Deregistration of Internet Resources and Legacy 
Internet Resources: https://www.ripe.net/publications/docs/ripe-808/#a1211c
[4] Regular abuse-c Validation: 
https://www.ripe.net/membership/policies/proposals/2017-02/#relevant-ripe-policies-and-ripe-ncc-procedures


On 05/04/2024 16:51, denis walker wrote:

Colleagues

I am not surprised this policy proposal (2023-04) has gone to last
call. I expected this from the start, no matter what anyone said. And
I won't be surprised when it is approved. I used to wonder why no one
would even talk about bringing the RIPE Database into the modern
world. Why continue to use an ancient, broken tool that is barely fit
for purpose? It is quite obvious now. Playing on the complexity and
difficulties with using the database allows people to justify changing
the purpose and the rules, to make it more convenient. That is simpler
and cheaper than fixing the tool. It is easy for a small vocal group
to sell 'simple and cheap' to a silent majority. Convenience is easier
to do than right. But it may have consequences.

The proposers have assured us all that this proposal is about nothing
more than introducing this optional, minor, inconsequential feature
that changes nothing. They have argued that the RIPE NCC has
"repeatedly" verified their claim that this proposal changes nothing
'of significance'. This is based on the RIPE NCC legal team's
confusing impact analysis and the comments made once and referred to
once by the RIPE NCC Registration Services through messages passed on
by the policy officer. The legal team declined to clarify the
confusing wording of their impact analysis. No one from Registration
Services was willing to discuss the claims that they have been wrongly
applying the policy for a number of years, or the reason why and when
they stopped correctly applying the policy. I thought RIPE NCC staff
were being encouraged to be more involved in community discussions?

It has been said and confirmed recently by several people from the
community that we no longer understand what some of the registration
data in the RIPE Database means, why it is there and why we have these
rules about it. This is despite the actual, current wording of these
rules having been written into a version of the policy published in
October 2003 that was authored by some people who are still leading
members of this community, and at the time were RIPE

Re: [address-policy-wg] AS Number Assignments - Transitioning to Policy Compliance Completed

[Marco Schmidt]

Hello Mikael and colleagues,

Thank you for the question, and I'm happy to provide clarification.

At present, we assign the highest available ASN from our 
undifferentiated pool, but we are planning to adopt a more randomized 
approach in the future. As a result, there will be no depletion of the 
lower digit (16-bit) ASNs anytime soon.


Kind regards,

Marco Schmidt
Manager Registration Services
RIPE NCC


On 25/01/2024 16:07, Mikael Abrahamsson wrote:

On Thu, 25 Jan 2024, Marco Schmidt wrote:


Dear colleagues,

In November 2023, I shared with you during the RIPE meeting and on 
this mailing list that the RIPE NCC intends to assign Autonomous 
System Numbers (ASNs) from an undifferentiated 32-bit AS Number pool, 
as defined in the Autonomous System (AS) Number Assignment Policies.


I am pleased to inform you that this change has been successfully 
implemented. The option to choose between a 16-bit or 32-bit AS 
Number as been removed. When submitting a request, the RIPE NCC will 
assign the next available AS Number from the undifferentiated 
allocation pool.


Hi,

could you please elaborate on what this "undifferentiated 32-bit AS 
Number pool" is?


I'm mainly curious if it means we'll deplete 16 bit ASNs (allocate 
from the lowest available number)?


Thanks.



--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

[address-policy-wg] AS Number Assignments - Transitioning to Policy Compliance Completed

[Marco Schmidt]

Dear colleagues,

In November 2023, I shared with you during the RIPE meeting and on this 
mailing list that the RIPE NCC intends to assign Autonomous System 
Numbers (ASNs) from an undifferentiated 32-bit AS Number pool, as 
defined in the Autonomous System (AS) Number Assignment Policies.


I am pleased to inform you that this change has been successfully 
implemented. The option to choose between a 16-bit or 32-bit AS Number 
as been removed. When submitting a request, the RIPE NCC will assign the 
next available AS Number from the undifferentiated allocation pool.


Kind regards,
Marco Schmidt
Manager Registration Services
RIPE NCC

On 30/11/2023 16:40, Marco Schmidt wrote:

Dear colleagues,

During the RIPE 87 Address Policy working group session yesterday, I 
presented the topic of AS Number assignments, specifically addressing 
a policy in place since 2010. According to this policy, assignments 
should be made from an undifferentiated 32-bit AS Number allocation pool.

https://www.ripe.net/publications/docs/ripe-679#ASnumbers

Before this policy became active in 2010, the Address Policy WG 
recognized that many providers were not ready to exclusively work with 
32-bit ASNs, mostly due to technical constraints. A verbal consensus 
in 2009 suggested that the RIPE NCC would temporarily continue using 
two pools of 16-bit and 32-bit AS Numbers. The plan was to attempt to 
extend the global policy by 12 months, but this effort was never 
undertaken. To date, the RIPE NCC remains the only Regional Internet 
Registry (RIR) employing this temporary approach.


Observing that other RIRs have successfully issued AS Numbers from an 
undifferentiated pool for many years without technical challenges for 
operators, the RIPE NCC plans to phase out the current temporary 
approach. The intention is to align with the policy and issue AS 
Numbers accordingly.


No objections were raised during the working group session. However, 
for transparency, we want to inform working group members who couldn't 
attend the RIPE meeting. The presentation can be viewed here:

https://youtu.be/Zoq4PpqlaK4?t=1797

Kind regards,
Marco Schmidt
Manager Registration Services
RIPE NCC



--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

[address-policy-wg] Update on AS Number Assignments - Transitioning to Policy Compliance

[Marco Schmidt]

Dear colleagues,

During the RIPE 87 Address Policy working group session yesterday, I 
presented the topic of AS Number assignments, specifically addressing a 
policy in place since 2010. According to this policy, assignments should 
be made from an undifferentiated 32-bit AS Number allocation pool.

https://www.ripe.net/publications/docs/ripe-679#ASnumbers

Before this policy became active in 2010, the Address Policy WG 
recognized that many providers were not ready to exclusively work with 
32-bit ASNs, mostly due to technical constraints. A verbal consensus in 
2009 suggested that the RIPE NCC would temporarily continue using two 
pools of 16-bit and 32-bit AS Numbers. The plan was to attempt to extend 
the global policy by 12 months, but this effort was never undertaken. To 
date, the RIPE NCC remains the only Regional Internet Registry (RIR) 
employing this temporary approach.


Observing that other RIRs have successfully issued AS Numbers from an 
undifferentiated pool for many years without technical challenges for 
operators, the RIPE NCC plans to phase out the current temporary 
approach. The intention is to align with the policy and issue AS Numbers 
accordingly.


No objections were raised during the working group session. However, for 
transparency, we want to inform working group members who couldn't 
attend the RIPE meeting. The presentation can be viewed here:

https://youtu.be/Zoq4PpqlaK4?t=1797

Kind regards,
Marco Schmidt
Manager Registration Services
RIPE NCC

--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

[address-policy-wg] New AS Number Blocks Allocated to the RIPE NCC

[Marco Schmidt]

Dear colleagues,

On 10 August 2023, the RIPE NCC received the following AS Number blocks 
from IANA:


213404-214427
214428-215451
215452-216475

You may want to update your records accordingly.

All allocations of AS Numbers made by IANA to RIRs are listed here:
https://www.iana.org/assignments/as-numbers/as-numbers.xhtml


Kind regards,

Marco Schmidt
Manager Registration Services
RIPE NCC


--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

Re: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management

[Marco Schmidt]

Dear Elvis, dear colleagues,

We are happy to provide you with the data you requested.

In the last 12 months, about 18% (414 out of 2291) of the requests were 
for 16-bit ASNs. Currently we have enough 16-bit ASNs in our free pool, 
but it should be noted that the return of unused ASNs is the only source 
to add such ASNs to our pool.


Once an ASN has been returned to RIPE NCC, the only reason to keep it in 
our quarantine pool for longer than 6 months is that the ASN is still 
visible in the routing system. We currently have just over 200 16-bit 
ASNs in regular quarantine, mainly thanks to our project to clean up 
unused ASNs.


It is correct that we still assign 16-bit ASNs when they are 
specifically requested. Although the ASN policy states that since "2010 
the RIPE NCC will cease to make any distinction", it was decided in 2010 
to keep the option to request for 16-bit ASNs [1][2]
Neither IANA nor other RIRs make this distinction between 16-bit and 
32-bit ASNs any more.


I hope you found this information useful, especially in terms of how to 
achieve more responsible ASN management.


Kind regards,
Marco Schmidt
Manager Registration Services
RIPE NCC

[1] https://www.ripe.net/publications/docs/ripe-679#ASnumbers
[2] 
https://www.ripe.net/ripe/mail/archives/address-policy-wg/2010-January/004977.html


On 12/06/2023 12:46, Elvis Daniel Velea wrote:

Hi Nick,

On Mon, Jun 12, 2023 at 00:25 Nick Hilliard  wrote:

Elvis Daniel Velea wrote on 11/06/2023 10:06:
> If someone could tell me why a 32bit ASN can not be used today
(even
> with 10 years old equipment), I’d appreciate it.

there's plenty of kit out there which still doesn't support BGP Large
Communities, particularly mikrotik routeros which only released an
initial production implementation at around the beginning of 2022.

Nick


thanks for that. I’m surprised to hear this, but heh, manufacturers 
can be slow sometimes… very slow :(


It may, then, matter to some if an ASN is 16bit or not. I know that 
the NCC had at some point (maybe still do) assigned 16bit ASNs upon 
request. Curious to see some stats, if possible:
- how many requests come in for 16bit a year? how many are those of 
the total ASN requests?
- how many 16bit ASNs are still in the pool and how many come back to 
the free pool every year?


Just trying to see how many years until 16bit ASNs could only be 
issued by the NCC only if returned.


On another note, I believe that there were a lot of 16bit ASNs in 
quarantine because of references in various objects (mostly as-sets if 
I recall correctly). Can you tell us, Marco, how many of those ASNs 
are quarantined and why aren’t these removed out of quarantine and 
assigned?


elvis

--
This message was sent from a mobile device. Some typos may be possible.
-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

Re: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management

[Marco Schmidt]

Dear colleagues,

Thank you for the feedback received so far.

As Aleksi noted, there are indeed valid reasons why ASNs seem to be 
unused. We have some data on this from our AS Number Clean up project.
When asked if the resource is being used, about 2/3 of ASNs have been 
returned, about 1/3 are expected to be used soon, and only a very small 
number have been used by transit providers or IXPs.


Of the more than 8,000 ASNs not visible in the routing system, about 52% 
are 16-bit ASNs.


As mentioned by Kaj, the members of RIPE NCC clearly voted against 
charging for ASNs. So we wanted to ask this working group if there are 
other ways to improve the situation?
Something that falls under the authority of the RIPE community, such as 
developing RIPE policies or guidelines for Registration Services.
For example, are you in favour of us being more active in trying to 
clarify the status of ASNs that seem to have been unused for a long 
period of time?


Kind regards,

Marco Schmidt
Manager Registration Services
RIPE NCC

On 08/06/2023 16:55, Nick Hilliard wrote:

Marco Schmidt wrote on 08/06/2023 14:30:
We also plan to intensify our ongoing project to clean up unused 
Autonomous System (AS) Numbers [2]. Almost 2,000 unused ASNs have 
been recovered as part of this work so far. Do you support our 
approach here? And are there other ways we could improve the 
situation? Perhaps you could add clarification on requesting and 
returning ASNs in the relevant RIPE policy, or maybe we could give a 
stronger mandate and responsibility to the sponsoring LIRs.


Hi Marco,

There are good reasons to clean up unused ASN16s, as they are 
categorised by policy as scarce resources. There isn't a compelling 
reason to get as excited about ASN32s, other than to say that normal 
good stewardship practices should apply.


Unfortunately there is a disconnect between RIPE policy and RIPE NCC 
practice in regard to charges for ASNs. This is a real shame because 
paying for resources is one of the simpler ways of creating positive 
pressure to return them if they're unused. The community would benefit 
from the board re-thinking this.


Nick


--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

[address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management

[Marco Schmidt]

Dear colleagues,

At RIPE 86, we shared some observations regarding Autonomous System 
Number (ASN) requests and usage [1].


We see an increasing number of ASN requests coming from both inside and 
outside of our service region. This seems to be driven primarily by the 
low cost and ease of receiving an ASN from the RIPE NCC. The downside is 
that we also see a significant decrease in responsible resource 
management by these resource holders. A large number of ASNs are never 
used or become abandoned after a short period.


Some data: in the last two years, we have provided 4,186 ASNs (between 
March 2021 and February 2023). Of this amount, we can see that 1,478 
ASNs (more than 35%) do not appear to be in use, as they are not visible 
in the routing system.


Looking at total numbers, we have issued almost 38,000 ASNs, of which 
more than 8,000  (~20%) are not visible.


This growing trend not only creates avoidable work for Registration 
Services and added costs for the membership, we believe it also 
undermines the goal of responsible management of Internet number 
resources within our service region.


As the membership voted against an annual service fee for ASNs at the 
recent RIPE NCC General Meeting, I would like to ask the working group 
for guidance on how resource holders can be motivated to manage their 
ASNs responsibly and how the RIPE NCC can provide support for this.


We also plan to intensify our ongoing project to clean up unused 
Autonomous System (AS) Numbers [2]. Almost 2,000 unused ASNs have been 
recovered as part of this work so far. Do you support our approach here? 
And are there other ways we could improve the situation? Perhaps you 
could add clarification on requesting and returning ASNs in the relevant 
RIPE policy, or maybe we could give a stronger mandate and 
responsibility to the sponsoring LIRs.




If you have an ASN registered to you that you don’t need anymore, you 
can always contact us through the LIR Portal or via your sponsoring LIR 
and we will arrange for the return of this resource.


Kind regards,

Marco Schmidt
Manager Registration Services
RIPE NCC



[1] 
https://ripe86.ripe.net/wp-content/uploads/presentations/82-RIPE86-Feeback-from-RS-reviewed.pdf


[2] https://www.ripe.net/manage-ips-and-asns/as-numbers/as-number-clean-up


--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

[address-policy-wg] 2023-01 - Clarification about the utilisation requirement for IXPs requesting an assignment larger a /24

[Marco Schmidt]

Dear colleagues,

Reading the comments on this list, I would like to provide some 
clarification.


If the proposal is accepted, it would only change the initial assignment 
size and offer the option to "jump" directly to a /24 when at least 33 
addresses are in use. The utilisation requirements for IXPs requesting 
assignments larger than a /24 would remain unchanged.


When receiving requests for more than a /24, the RIPE NCC checks that 
the IXP will need more than 50% of the assignment within one year. If 
their growth rate is too slow and we expect that it will take more than 
a year to exceed that utilisation threshold, we suggest that they 
postpone their request.


Kind regards,
Marco Schmidt
Manager Registration Services
RIPE NCC

On 08/05/2023 15:56, Steven Bakker via address-policy-wg wrote:

On Thu, 2023-05-04 at 06:21 +, Matthias Wichtlhuber via address-
policy-wg wrote:

The problems in section 5 can be fixed easily, but it depends on
how the authors want to handle assignment upgrades / renumberings.
I'd suggest either dropping the 1Y utilisation requirement to e.g.
40%, or else that if you reach e.g. 80% current usage, you qualify
to receive an assignment of 2x the current, up to /22.  Those
figures are plucked out of the air btw. The point with them is that
they are not 50%, which is obviously a magic number when the
natural increase of assignment size would be to double the size of
the block.

The goal of this part is to minimize renumberings while avoiding
greedy requests. Dropping the one year requirement to 40% is
reasonable if you think 50% is too harsh ("magic numbers"). We can
incorporate this change.

I believe that what Nick was getting at was that 50% is "magic" in the
sense that it creates a problem:

  * a /24 has 254 usable addresses.
  * a /23 has 510 usable addresses -> half of that is 255.

So, suppose you have used 230 addresses out of your /24. You apply for
and get a /23 and happily renumber.

Then, after one year, you have used 254 addresses. This is less than
half of the /23 (510/2 = 255), so according to the rules you'd have to
downgrade back to a /24 again. You can now no longer grow, unless you
immediately apply for a /23 again.

So we either live with this "bug" and trust that whoever has to perform
evaluation is "reasonable", or we find a numbers that don't cause these
kind of edge cases.

Cheers,
Steven



--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

Re: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26)

[Marco Schmidt]

Dear Radu,

Yes, that is correct.

Kind regards,
Marco Schmidt
Manager Registration Services
RIPE NCC

On 11/01/2023 15:41, Radu-Adrian FEURDEAN wrote:

On Wed, Jan 11, 2023, at 15:18, Marco Schmidt wrote:

Other IP ranges that might be used for IXP services, such as parts of an
IPv4 allocation (ASSIGNED PA), do not fall under this condition.

So when the time comes (and provided the other conditions are met) it would be possible 
to request a /23 in grow an IXP currently using a /24 "ASSIGNED PA", with 
nothing to return to the NCC (the rest of the allocation being in use).

Is that correct ?



--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

Re: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26)

[Marco Schmidt]

Dear Radu,

I'm happy to provide some clarification.

The current IPv4 IXP policy states "Once they require a larger 
assignment, they must return their current one (or existing PI used as 
an IXP peering LAN)" [1]


It is the RIPE NCC's understanding that this condition applies to IXP 
assignments provided under this policy and to older regular PI 
assignments if they were provided exclusively for IXP peering LANs. 
Other IP ranges that might be used for IXP services, such as parts of an 
IPv4 allocation (ASSIGNED PA), do not fall under this condition.


As you mentioned, the proposed new wording on this topic is very 
similar, and the RIPE NCC would apply the same understanding if this 
proposal would become a RIPE policy.


Kind regards,
Marco Schmidt
Manager Registration Services
RIPE NCC

[1] https://www.ripe.net/publications/docs/ripe-733#61

On 11/01/2023 12:14, Radu-Adrian FEURDEAN wrote:

Hello,

Would somebody from NCC be able to clarify how would the wording "must return the 
existing assignment (or existing PI used as an IXP peering LAN)" (proposed text 
6.1.4 and 6.1.5) be interpreted/implemented for the case of IXPs that use ASSIGNED PA 
space for the peering LAN. OK, it's the same wording that already exists in the current 
policy, but a clarification is welcome.

Otherwise the proposal seems reasonable.

On Mon, Jan 9, 2023, at 11:40, Angela Dall'Ara wrote:

Dear colleagues,

A new RIPE Policy Proposal, 2023-01, "Reducing IXP IPv4 assignment
default size to a /26"
is now available for discussion.

The goal of this proposal is to extend the lifetime of the IXP IPv4
address pool and to motivate IXPs to implement the exchange of IPv4
routing information over IPv6.

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2023-01

As per the RIPE Policy Development Process (PDP), the purpose of this
four-week Discussion Phase is to discuss the proposal and provide
feedback to the proposer.

At the end of the Discussion Phase, the proposer, with the agreement of
the WG Chairs, will decide how to proceed with the proposal.

The PDP document can be found at:
https://www.ripe.net/publications/docs/ripe-781

We encourage you to review this proposal and send your comments to
address-policy-wg@ripe.net before 7 February 2023.


Kind regards,

Angela Dall'Ara
Policy Officer
RIPE NCC


--

To unsubscribe from this mailing list, get a password reminder, or
change your subscription options, please visit:
https://lists.ripe.net/mailman/listinfo/address-policy-wg


--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

[address-policy-wg] IPv6 Allocation to the RIPE NCC

[Marco Schmidt]

Dear colleagues,

The RIPE NCC Arbiters Panel has approved a request for an IPv6 
allocation to the RIPE NCC for its internal network based on the RIPE 
Document ripe-635, "Allocating/Assigning Resources to the RIPE NCC", and 
the RIPE NCC Document ripe-738, “IPv6 Address Allocation and Assignment 
Policy”.


You can find the full announcement at:
https://www.ripe.net/publications/news/about-ripe-ncc-and-ripe/ipv6-allocation-to-the-ripe-ncc

If you have any questions, please send us a message at ripe.net>.


Kind regards,

Marco Schmidt
Manager Registration Services
RIPE NCC


--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

[address-policy-wg] Potential Improvements to the Temporary Internet Number Assignment Policies

[Marco Schmidt]

Dear colleagues of the Address Policy Working Group,

During the last RIPE Meeting in May, I presented on several observations 
that the Registration Services department had [1]. After receiving some 
feedback during the meeting, it was agreed to continue the discussion on 
the mailing list before RIPE 85.


One of the topics discussed was the challenges encountered when dealing 
with temporary assignment requests. A specific policy allows the RIPE 
NCC to assign Internet Number resources on a temporary basis for a 
specific time-limited purpose, such as academic research and 
experimental purposes, conferences and other types of events. [2]


Over the past years, the RIPE NCC has received some requests for 
academic research that required only a few IPv4 addresses for actual 
experiments, but within a routable prefix.
This created a conflict with the current policy which requires the use 
of at least 50% of the requested IPv4 address space. With some 
creativity, the RIPE NCC has been able to approve these requests so far, 
but this has resulted in unnecessary delays in processing these 
requests. It is also possible that people have been refraining from 
submitting a request because of this policy limitation.


One possible solution would be to review the current policy and propose 
a policy change, for example the introduction of a minimum IPv4 
assignment size.


Does the working group agree that this is an issue that should be 
discussed and that might require a policy change?


Kind regards,
Marco Schmidt
Manager Registration Services
RIPE NCC

[1] https://ripe84.ripe.net/archives/video/786/
[2] https://www.ripe.net/publications/docs/ripe-587


--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

Re: [address-policy-wg] Maximum size for current IPv4 allocations

[Marco Schmidt]

Dear Ronald,

On 15/08/2022 12:45, Ronald F. Guilmette wrote:

In message <19f8c8b6-0590-8903-0e9e-ec6638d1f...@ripe.net>,
Marco Schmidt  wrote:


As Elvis clarified, the examples you listed are the results of resource
transfers.

The “netname:” attribute of an INETNUM object in the RIPE Database
indicates whether an IPv4 allocation was received directly from the RIPE
NCC or via a transfer.

Please elaborate.   How does it do that exactly?  For example, what does
this value tell us about how the block was received?

CH-AS5398-20191016
The last part of the netname is the date when the resource was allocated 
by the RIPE NCC, in this example 16 October 2019.



It includes the date on which that range was
provided by the RIPE NCC, also for smaller ranges that are part of a
previously bigger range. If the date in the “netname:” and the date on
which the object was created differ, you can deduce that the range
concerned was not allocated directly by the RIPE NCC.

In other words you are saying that 193.222.104.0/23 wasw purchased, correct?


If the dates differ, this only indicates that a change of the resource 
holder took place, either for this range directly or another part of a 
previously larger address block. Such change can be a policy transfer, a 
company merger or a network acquisition. The RIPE NCC is not involved in 
the financial details of such update.


Kind regards,
Marco Schmidt
RIPE NCC





I hope this helps answer your question.

It may, once I understand clearly everything you just said.


Regards,
rfg



--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

Re: [address-policy-wg] Maximum size for current IPv4 allocations

[Marco Schmidt]

Dear Ronald,

As of November 2019 the RIPE NCC only provides /24 IPv4 allocations to 
LIRs that have not previously received an IPv4 allocation from us. As 
Elvis clarified, the examples you listed are the results of resource 
transfers.


The “netname:” attribute of an INETNUM object in the RIPE Database 
indicates whether an IPv4 allocation was received directly from the RIPE 
NCC or via a transfer. It includes the date on which that range was 
provided by the RIPE NCC, also for smaller ranges that are part of a 
previously bigger range. If the date in the “netname:” and the date on 
which the object was created differ, you can deduce that the range 
concerned was not allocated directly by the RIPE NCC.


I hope this helps answer your question.

Kind regards,
Marco Schmidt
RIPE NCC

On 15/08/2022 10:45, Elvis Daniel Velea wrote:

hi,

On Mon, Aug 15, 2022 at 01:41 Bogdan Rotariu  wrote:



On Aug 15, 2022, at 11:19, Ronald F. Guilmette
 wrote:

In message <301e0ef8-ed15-67d3-d390-7bea8571c...@ripe.net>,
    Marco Schmidt  wrote:


On 15/08/2022 09:16, Gert Doering wrote:

Hi,

On Mon, Aug 15, 2022 at 12:10:49AM -0700, Ronald F. Guilmette
wrote:

What is the maximum size for current new IPv4 allocations in
the RIPE
region?

/24  "if there is something to distribute at all"


Just to confirm what Gert said.

For more information please feel free to check our website about
IPv4
https://www.ripe.net/manage-ips-and-asns/ipv4

as well the underlying RIPE policy which was published in
November 2019
https://www.ripe.net/publications/docs/ripe-733#51


Thank you for the confirmation. Unfortunately, I remain rather
mystified
by how the following IPv4 blocks, and the current RIPE WHOIS
records that
pertain to them, comport with what you and Gert have just now
told me.
Perhaps there is something that I am missing (?)

ORG-AS976-RIPE:

31.44.32.0/20 <http://31.44.32.0/20>  created:
2022-06-24T06:46:34Z
46.21.16.0/21 <http://46.21.16.0/21>  created:
2022-06-24T06:46:34Z
46.21.28.0/22 <http://46.21.28.0/22>  created:
2022-06-24T06:46:34Z
77.220.64.0/19 <http://77.220.64.0/19> created:
2022-06-23T09:56:04Z
185.155.176.0/22 <http://185.155.176.0/22>   created:
2022-06-23T09:56:04Z
185.155.184.0/22 <http://185.155.184.0/22>   created:
2022-06-24T06:46:34Z
193.221.216.0/23 <http://193.221.216.0/23>   created:
2022-06-24T06:46:33Z
193.222.104.0/23 <http://193.222.104.0/23>   created:
2022-06-24T06:46:33Z


Regards,
rfg


P.S.  I would still be concerned, although perhaps a bit less
concerned, if
this organisation had not elected to place a fradulent and
non-existant
comnpany name into its public WHOIS organisation: record.  I
would however
still remain befuddled by how this organisation managed to be
assigned
some 72 times as much IPv4 address space as anybody else could
get, all
apparently less than 2 months ago.

But there must be a reasoable explanation, I suppose.



when the RIPE NCC processes a transfer and needs to split a block, all 
the smaller blocks that are transferred from the original large block 
will have the date of the transfer as creation date


/elvis





There is, those are transfers, check them here

https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-statistics/within-ripe-ncc-service-region/ipv4-transfer-statistics
-- 


To unsubscribe from this mailing list, get a password reminder, or
change your subscription options, please visit:
https://lists.ripe.net/mailman/listinfo/address-policy-wg

--
This message was sent from a mobile device. Some typos may be possible.
-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

Re: [address-policy-wg] Maximum size for current IPv4 allocations

[Marco Schmidt]

Hello Ronald,

On 15/08/2022 09:16, Gert Doering wrote:

Hi,

On Mon, Aug 15, 2022 at 12:10:49AM -0700, Ronald F. Guilmette wrote:

What is the maximum size for current new IPv4 allocations in the RIPE
region?

/24  "if there is something to distribute at all"


Just to confirm what Gert said.

For more information please feel free to check our website about IPv4
https://www.ripe.net/manage-ips-and-asns/ipv4

as well the underlying RIPE policy which was published in November 2019
https://www.ripe.net/publications/docs/ripe-733#51


Kind regards,

Marco Schmidt
Manager Registration Services
RIPE NCC




Gert Doering
 -- NetMaster



--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

Re: [address-policy-wg] Reclamation of Number Resources

[Marco Schmidt]

Hello Ronald,

Thank you for your question.

On 11/07/2022 17:24, Ronald F. Guilmette wrote:

In message <915f19e1-fff5-ced2-611b-30e5f3167...@ripe.net>,
Marco Schmidt  wrote:


The RIPE NCC has de-registered address space based on these policy
requirements by carrying out further investigations, including for
policy violations.

Thank you Marco.

Can you give me some idea of how many instances there have been of
reclamations that were the result of policy violations other than
the non-payment of fees, over say, either the past 5 years or since
the inception of RIPE?

Would the number be closer to 5 or 500?


When checking our Annual Reports, you will see that it was closer to 5 
during the last years.




We see de-registration of Internet number resources as the last resort,

Of course!


Regards,
rfg


Kind regards,

Marco Schmidt
Assistant Manager Registry Services
RIPE NCC

--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

Re: [address-policy-wg] Reclamation of Number Resources

[Marco Schmidt]

Dear Ronald,

The RIPE policy document “IPv4 Address Allocation and Assignment 
Policies for the RIPE NCC Service Region” contains clear requirements 
regarding the de-registration of address space held by our members:

https://www.ripe.net/publications/docs/ripe-733#9

—---
The RIPE NCC may close an LIR for any of the following reasons:

    * the LIR does not pay money owed to the RIPE NCC
    * the LIR cannot be contacted by the RIPE NCC for a significant 
period of time

    * the LIR consistently violates the RIPE community's policies

The RIPE NCC takes on responsibility for address space held by closing LIRs.
—

This is further specified in our procedural document “Closure of 
Members, Deregistration of Internet Resources and Legacy Internet 
Resources”:

https://www.ripe.net/publications/docs/ripe-775

The RIPE NCC has de-registered address space based on these policy 
requirements by carrying out further investigations, including for 
policy violations. We provide an overview of the investigations carried 
out in our Annual Report [1]. Please note that the RIPE region has no 
specific out-of-region usage policy.



We see de-registration of Internet number resources as the last resort, 
and as far as possible, we try to work with our members to ensure policy 
compliance while simultaneously preventing any impact on active networks 
and their users.


I hope this answers your questions.

Kind regards,


Marco Schmidt
Assistant Manager Registry Services
RIPE NCC

[1] https://www.ripe.net/publications/docs/ripe-777


On 07/07/2022 23:27, Ronald F. Guilmette wrote:

Greetings all,

As many of you no doubt know, there has been quite an extraordinarily large
brouhaha of late within the AFRINIC region relating to AFRINIC's efforts to
reclaim certain large blocks of IPv4 addresses from one particular member
organization.  This effort has resulted in considerable litigation within
Mauritius, the home country of AFRINIC.

Partially as a result of this ongoing controversy, but also just for my
own edification, I would like to ask a number of questions about any and
all prior instances in which RIPE has reclaimed number resources from
member organizations, based on policy.

It seems safe to assume that there have historically been some instances in
which RIPE memberships have been terminated, and any associated assigned
number resources reclaimed, if and when a given member has simply failed
to pay fess due to RIPE.  My questions however have to do with situations
where policy violations other than the non-payment of fees are involved.
Specifically, I would like to know if any of you can recall past instances
where number resources have been reclaimed, by RIPE, for any of the following
reasons:

 *)  Usage of the assigned number resources was no longer consistant with
 the original justification submitted to RIPE.

 *)  Violation(s) of out-of-region usage policy.

 *)  Any other policy violations.

Thanks in advance for any and all responses.


Regards,
rfg



--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

Re: [address-policy-wg] IPv4 waiting list policy

[Marco Schmidt]

Hello Denis,

Thank you for your questions. Allow me to answer as many as I can right 
now. As you indicated, getting the data for some of the requests in your 
email from 9 December would require quite some time and effort. 
Considering that Registry Services is currently in the busiest time of 
the year, I would prefer to first identify if this data would really be 
beneficial for the ongoing discussion about the IPv4 waiting list policy 
and potential policy proposal.


For example, you asked if some members with 10+ LIR accounts are brokers 
or are from a certain country. What I can say is that these members are 
quite diverse. They are located in several countries inside and outside 
of our service region.
Some of these 98 organisations only became members in the last two 
years, while others opened multiple LIR accounts in the past several 
years and so received multiple /22 IPv4 allocations under the former 
"Last /8” policy, and later /24 IPv4 allocations under the current 
policy. Those members received around 1,100 /22s between September 2012 
and November 2019, when the "Last /8" policy was in place.


As for your comments about consolidations, I would like to clarify that 
the RIPE NCC uses this term when a member consolidates some of their LIR 
accounts into another LIR account. When an LIR receives resources that 
are restricted by a holding period, those resources must be kept in that 
LIR account until the holding period has passed. After that 24-month 
period, these members usually decide to consolidate their LIR accounts, 
including their resources. If a company were to take over one of its 
child companies, this would be processed by the RIPE NCC as a merger of 
two different legal bodies.


To provide some more numbers, besides the 98 members that hold 10 or 
more accounts, we currently have 112 members that hold between 5 and 9 
LIR accounts.
The maximum amount of /24 allocations that a single member has received 
under the current policy is 33.
So far, no allocations received under the current waiting list policy 
have been transferred due to the fact that the first such allocation was 
provided around 24 months ago and almost all allocations are still 
within their holding period.


I hope this answers most of your questions.

Kind regards,
Marco Schmidt
Assistant Manager Registry Services
RIPE NCC

On 14/12/2021 14:20, denis walker wrote:

Hi Guys

I have some more questions now as I dig deeper into these allocations. 
Marco mentioned in his email that the situation is quite fluid because 
of consolidations, transfers, and opening of new LIR accounts that 
occur all the time. I have found the transfer information, where can I 
find details of consolidations? Also is the waiting list published 
anywhere? I have seen companies with say 25 LIRs where 22 have already 
received a /24 this year. I would like to know if the other 3 LIRs are 
on the waiting list and at what position.


Now I have some detailed questions about what is meant by 
consolidation. I will illustrate with an anonymous example. For all my 
analysis I will not identify any company by name. My intention is to 
expose behaviour.


So we have a parent company ABC Networks BV. They set up 5 child 
companies. One in 2017 and 4 in early 2019. One of them is XYZ 
Networks BV.


XYZ networks BV opens 12 LIRs. Throughout 2019 each of these LIRs 
receive a /22 allocation. In December 2019 all these LIRs/allocations 
moved to the parent company ABC Networks BV and the child company XYZ 
Networks BV was deregistered according to the Chamber of Commerce.


In total the 5 child companies opened 50 LIRs. They each received a 
/22 throughout 2019 and all these child companies were deregistered in 
December 2019 with their LIRs/allocations 'transferred' to the parent 
company. Is this what is meant by consolidation? Not sure what the 
business case is to register several companies who open several LIRs 
each to get allocations, then close the companies a few months later 
and merge all the resources into the parent company...unless it is to 
try to hide the true number of LIRs the parent company has set up.


The timing is also interesting. All of these child companies were 
merged with the parent company on 2 December 2019, according to the 
Chamber of Commerce:
"Merger deed passed on 02-12-2019. Acquiring legal entity: ABC 
Networks BV Disappearing legal entities: XYZ Networks BV..."
The child companies were then all deregistered on 5 December 2019, 
according to the Chamber of Commerce:
"As of 5-12-2019, the legal entity has been deregistered due to 
Termination of registration"


According to the Transfer Statistics the date of the transfer of the 
resources was 23 December 2019 from the child company XYZ Networks BV 
to the parent company ABC Networks BV. The ORGANISATION objects in the 
RIPE Database were also modified on 23 December 2019 to change the 
"org-name:" to that of the p

Re: [address-policy-wg] IPv4 waiting list policy

[Marco Schmidt]

Dear Arash,

Thank you for your question.

At the moment, we see 98 members with 10 or more LIR accounts. These 
members have received a total of 1254 /24s under the current IPv4 
waiting list policy.


I would like to note that these numbers are constantly changing. On the 
one hand, some members continue to open additional LIR accounts, while 
other members consolidate or close many LIR accounts as soon as the 
24-month holding period expires. This also explains the slight 
difference from the previously published numbers. Several members that 
held 10 or more accounts when they received /24s have since reduced 
their number of LIRs.


I hope this answers your question.

Kind regards,
Marco Schmidt
Assistant Manager Registry Services
RIPE NCC

On 08/12/2021 12:39, Arash Naderpour wrote:

Hi Marco,

Could you please let me know how many organizations have 10 or more 
LIR accounts?


Thanks,

Arash Naderpour

On Tue, Dec 7, 2021 at 8:22 PM Marco Schmidt  wrote:

Dear colleagues,

In the Address Policy Working Group sessions at RIPE 83, I shared our
observations regarding the IPv4 waiting list policy. [1]

The intent of this policy was to provide newcomers with a minimal
amount
of IPv4 space for as long as possible. However, about half of these
allocations went to members that received several /24 allocations via
multiple LIR accounts.

As there was interest in reviewing the policy at the RIPE Meeting, I
would like to provide more detail on the provision of IPv4
allocations
over the last two years and the current situation with the waiting
list.

In the last 24 months, we provided 4,178 LIRs with a /24 allocation:
-    2,019 allocations (48%) went to members with a single LIR account
-    452 allocations (11%) went to members with 2-4 LIR accounts
-    298 allocations (7%) went to members with 5-9 LIR accounts and
-    1,409 allocations (34%) went to members with 10 or more LIR
accounts (up to 33 /24 allocations to a single member)

This trend towards allocations to multiple LIR accounts has
accelerated
in the past six months. Between June and November 2021, only 24% of
allocations went to members with a single LIR account, while 54%
went to
members with 10 or more accounts.

We see the same trend with the current waiting list. At the time of
writing, we can see 327 requests for a /24 allocation:
-    83 (25%) are from members with a single LIR account
-    42 (13%) are from members with 2-4 LIRs accounts
-    45 (14%) are from members with 5-9 LIR accounts
-    157 (48%) are from members with 10 or more LIR accounts

Consequently, there is a significantly longer wait time for
members with
a single LIR account.

Looking at the current market prices for IPv4 in comparison to our
membership fees, even a wait time of several months is acceptable for
organisations that plan to transfer their allocation after the end of
the holding period. Conversely, the long wait time will create
uncertainty for real newcomers, especially if they can’t rely on
IPv6-only networks.

I hope the WG finds this information useful for further
discussion. If
there is consensus to change the current situation, there are several
approaches available – including a review of the waiting list
policy and
changing ‘per LIR’ to something else. Other approaches, such as a
different charging scheme or changing the concept of multiple LIRs
would
need to be approved by the RIPE NCC membership.

Kind regards,
Marco Schmidt
Assistant Manager Registry Services
RIPE NCC

[1] https://ripe83.ripe.net/archives/video/642/


-- 


To unsubscribe from this mailing list, get a password reminder, or
change your subscription options, please visit:
https://lists.ripe.net/mailman/listinfo/address-policy-wg
-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

[address-policy-wg] IPv4 waiting list policy

[Marco Schmidt]

Dear colleagues,

In the Address Policy Working Group sessions at RIPE 83, I shared our 
observations regarding the IPv4 waiting list policy. [1]


The intent of this policy was to provide newcomers with a minimal amount 
of IPv4 space for as long as possible. However, about half of these 
allocations went to members that received several /24 allocations via 
multiple LIR accounts.


As there was interest in reviewing the policy at the RIPE Meeting, I 
would like to provide more detail on the provision of IPv4 allocations 
over the last two years and the current situation with the waiting list.


In the last 24 months, we provided 4,178 LIRs with a /24 allocation:
-    2,019 allocations (48%) went to members with a single LIR account
-    452 allocations (11%) went to members with 2-4 LIR accounts
-    298 allocations (7%) went to members with 5-9 LIR accounts and
-    1,409 allocations (34%) went to members with 10 or more LIR 
accounts (up to 33 /24 allocations to a single member)


This trend towards allocations to multiple LIR accounts has accelerated 
in the past six months. Between June and November 2021, only 24% of 
allocations went to members with a single LIR account, while 54% went to 
members with 10 or more accounts.


We see the same trend with the current waiting list. At the time of 
writing, we can see 327 requests for a /24 allocation:

-    83 (25%) are from members with a single LIR account
-    42 (13%) are from members with 2-4 LIRs accounts
-    45 (14%) are from members with 5-9 LIR accounts
-    157 (48%) are from members with 10 or more LIR accounts

Consequently, there is a significantly longer wait time for members with 
a single LIR account.


Looking at the current market prices for IPv4 in comparison to our 
membership fees, even a wait time of several months is acceptable for 
organisations that plan to transfer their allocation after the end of 
the holding period. Conversely, the long wait time will create 
uncertainty for real newcomers, especially if they can’t rely on 
IPv6-only networks.


I hope the WG finds this information useful for further discussion. If 
there is consensus to change the current situation, there are several 
approaches available – including a review of the waiting list policy and 
changing ‘per LIR’ to something else. Other approaches, such as a 
different charging scheme or changing the concept of multiple LIRs would 
need to be approved by the RIPE NCC membership.


Kind regards,
Marco Schmidt
Assistant Manager Registry Services
RIPE NCC

[1] https://ripe83.ripe.net/archives/video/642/


--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

Re: [address-policy-wg] do we need a policy for avoiding "multiple unjustified LIRs"?

[Marco Schmidt]

Hello Jordi,

Thank you for your question.

The policy proposal 2018-01, "Organisation-LIR Clarification in IPv6 
Policy" agreed upon by the Address Policy WG gave a clear mandate to the 
RIPE NCC to allocate IPv6 resources per LIR, regardless of whether it is 
a single or multiple LIR account.

https://www.ripe.net/participate/policies/proposals/2018-01

As I pointed out yesterday during my presentation, the collection of 
IPv6 allocations via multiple LIR accounts appears to conflict with some 
of the goals of the IPv6 policy. However, as was generally agreed 
yesterday during the Address Policy WG session, it might be time to 
review these goals. This could be one way forward to provide guidance to 
the RIPE NCC about how we should handle requests for additional IPv6 
allocations from parties that already have large IPv6 blocks and no 
clear reason for requesting additional IPv6 allocations.


Regarding your suggestion concerning opening multiple LIR accounts, this 
would be something for the RIPE NCC membership and the Executive Board 
to discuss. As you indicated, defining reasonable boundaries between 
justified and unjustified might be a challenge.


Kind regards,
Marco Schmidt
Assistant Manager Registry Services
RIPE NCC

On 24/11/2021 11:14, JORDI PALET MARTINEZ via address-policy-wg wrote:

Not acting is a path for abuse and stockpiling. Not fair and we must resolve it 
avoiding it as much as possible.

  
Regards,

Jordi
@jordipalet
  
  


El 23/11/21 11:59, "address-policy-wg en nombre de Staff" 
 escribió:

 Hello everybody,

 Of cause no.

 That will not help. always possible to avoid.
 Doing more complex polices is not good way. NCC had already lot of
 issues with that.
 Does any body remember how they asked to use email with the name to use
 in their database and people should change emails lot of times to
 sutisfy NCC We did  a lot of noise and NCC canceled it. Brr...

 If people request space - then they need it and they select this way to
 get it with NCC.

 This is normal process. No rush here. NCC should work as usual.

 Yury


 To unsubscribe from this mailing list, get a password reminder, or change 
your subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.




To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg


To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

[address-policy-wg] IPv6 Stockpiling

[Marco Schmidt]

Dear colleagues,

During RIPE 82, we provided you with an update on our observation of 
IPv6 stockpiling [1]. Based on the feedback we received and in 
preparation for the coming RIPE meeting, we would like to give you 
another update on that issue.


According to the IPv6 Address Allocation and Assignment Policy, an LIR 
can receive up to a /29 IPv6 allocation without needing to supply any 
additional information. The RIPE community considered this size 
sufficient for most organisations for long-term IPv6 deployment. 
Additionally, LIRs may qualify allocations greater than /29 by 
submitting documentation that reasonably justifies this request [2].


However, over the past few years we have noticed that some organisations 
are collecting multiple IPv6 allocations in ways that are permitted by 
current RIPE policies but might conflict with the above-mentioned intent 
of the IPv6 policy. For example, it is possible for a single RIPE NCC 
member to receive a /29 allocation for each of the multiple LIR accounts 
that it holds. This is the result of a policy change in 2018 [3]. LIRs 
can also receive multiple IPv6 allocations via policy transfers without 
needing any further justification. However, when the IPv6 transfer 
policy was discussed in 2014, it was assumed that there wouldn't be an 
active transfer market [4].


We have gathered data showing the significant development of the 
collection of IPv6:
- Almost 700 IPv6 allocations have been transferred in 2021 so far (and 
there have been more than 3,900 transfers since policy implementation in 
2015)
- About 60% all IPv6 allocations ever handed out by the RIPE NCC are now 
held as multiple allocations
- In the last three months, more than 75% of all new allocations were 
given to members that already hold at least one IPv6 allocation
- More than 1,500 members hold multiple IPv6 allocations, exceeding the 
size /29
- Almost 100 members hold more than 10 IPv6 allocations (the maximum is 
102 IPv6 allocations held by one member)


It is the RIPE NCC’s understanding that some of these situations are 
within the intent of previous policy changes, for example, to avoid 
renumbering of deployed IPv6 networks during holdership changes, or if a 
large company has multiple network departments that prefer to manage 
their own allocation.
However, the huge volume indicates that most are for other reasons. 
While members can collect multiple IPv6 allocations without evaluation 
by the RIPE NCC, we still were able to gather some feedback how members 
plan to use their allocations. Many members simply stockpile them for an 
undefined future use, others plan to use them for activities which 
temporarily require a vast amount of IPs, and some plan to offer IPv6 on 
a large scale to other ISPs in their country.


We believe that this situation could create several issues:
- IPv6 might be deployed in conflict with RIPE policies, underlying RFCs 
and other best practices, resulting in challenges to that IPv6 
deployment once the policy violation is discovered during an audit
- There could be a negative impact on the quality of the registry if 
large parts of allocations were given to third parties without clear 
registration requirements
- The policy requirement to justify larger IPv6 allocations would then 
be rendered useless


If you agree that this is a problem, we would like to initiate a 
discussion in this Working Group about possible solutions. We see at 
least two potential paths forward.


Firstly, if the Working Group believes that this trend is an indication 
of a widespread need for IPv6 address space larger than /29, then the 
requirement for justification could perhaps be adjusted for a larger 
allocation size. Members could then more easily get the address space 
they need, but as an aggregated block. Stockpiling would still be 
possible under this potential policy change, in fact on an even bigger 
scale.


Secondly, if the Working Group believes that this trend is in conflict 
with the original intent of the IPv6 policy, adjustments to the policy 
can be proposed that give the RIPE NCC a stronger mandate to enforce it. 
One challenge here would be defining what IPv6 usages are considered 
within or outside of the intent of the policy and how to ensure better 
oversight without too much impact on IPv6 deployment.


There might be other options that this working group can consider and 
discuss.
If required, the RIPE NCC can provide additional information for this 
discussion.


Kind regards,
Marco Schmidt
Registry Services Assistant Manager
RIPE NCC

[1] https://ripe82.ripe.net/presentations/7-RIPE82-Feeback-from-RS.pdf 
from slide 9

[2] https://www.ripe.net/publications/docs/ripe-738#initial_allocation
[3] https://www.ripe.net/participate/policies/proposals/2018-01
[4] https://www.ripe.net/participate/policies/proposals/2014-12

[address-policy-wg] Stockpiling IPv6 Update

[Marco Schmidt]

Dear Address Policy Working Group,

During the last Address Policy WG session in October 2020, we provided an
update on the topic of stockpiling IPv6 allocations. For the upcoming
RIPE 82 meeting, we want to share some additional information to
support the community discussion.

To summarise, the RIPE NCC observed a significant amount of members
requesting several IPv6 allocations via multiple LIR accounts or the
transfer policy. Based on the IPv6 policy, it is possible to request up 
to a

/29 IPv6 allocation per LIR account, without any justification needed.

Firstly, we want to stress again that this is not about any potential
scarcity of IPv6. Rather we would like to ask the Working Group if the
current development is within the intend of the IPv6 policy.

Currently, we see around 100 members that have collected multiple IPv6
allocations with totaling amounts of /26 or more, with the maximum of 91 
IPv6

allocations (totals /23+).
To put this in perspective, in the last ten years, only 12 members could
document the need for initial allocations of a /26 or more, with a
decreasing trend in the last years while at the same time, more multiple
smaller IPv6 allocations are being requested.
We see a big discrepancy between organisations being able to justify
larger IPv6 allocation based on actual network plans (despite eased
policy requirements) and organisations that collect many /29 allocations
without any real requirement of justification.

We also noticed that some of the members rent out large blocks of their
multiple allocations to other ISPs. While the IPv6 policy supports this
approach, we would like to raise awareness that this creates a
strong dependency of the ISP to their LIR, especially if large IPv6
networks are being deployed. In case the members decide to change their
business model or terminate the membership, the sub-ordinated ISPs will
be forced to renumber whole IPv6 networks or follow any requirement set
by the LIR.

We hope that this information will help the Working Group to review if
the current development is in line with the intent of the IPv6 policy.

Kind regards,

Marco Schmidt
Assistant Manager Registry Services and Policy Development
RIPE NCC

[address-policy-wg] Policy Proposal Implemented: 2019-05 "Revised IPv4 assignment policy for IXPs"

[Marco Schmidt]

Dear colleagues,

We are pleased to announce that we have fully implemented the RIPE 
Policy Proposal 2019-05 "Revised IPv4 assignment policy for IXPs”.


This policy increased the reserved IPv4 pool for IXPs to a /15 and 
finetuned assignment criteria.


The default IPv4 assignment size for IXP remains a /24 however on 
request or once there are no more assignments of /24 (or larger) 
available, assignments can be made down to /27.


The pool management part of this proposal was already implemented in 
October 2019.


The archived policy proposal can be found at:
https://www.ripe.net/participate/policies/proposals/2019-05

The RIPE Document, "IPv4 Address Allocation and Assignment Policies for 
the RIPE NCC Service Region" is available at:

https://www.ripe.net/publications/docs/ripe-733

Kind regards,

Marco Schmidt
Registration Services and Policy Development Assistant Manager
RIPE NCC

[address-policy-wg] 2019-07 Policy Proposal Withdrawn (Default assignment size for IXPs)

[Marco Schmidt]

Dear colleagues,

The policy proposal 2019-07, "Default assignment size for IXPs" has been 
withdrawn.


This proposal aimed to change the default IXP assignment size from a /24 
to a needs-based model, with a /27 as a minimum.


The proposal is archived and can be found at:
https://www.ripe.net/participate/policies/archived-policy-proposals/archive-policy-proposals/ 



Reason for withdrawal:
The proposer felt that there was no clear direction on how to proceed 
with the proposal.


Kind regards,

Marco Schmidt
Registration Services and Policy Development Assistant Manager
RIPE NCC

[address-policy-wg] 2019-06 Review Phase Extended (Multiple Editorial Changes in IPv6 Policy)

[Marco Schmidt]

Dear colleagues,

Policy proposal 2019-06, "Multiple Editorial Changes in IPv6 Policy" is 
now in the extended Review Phase.


This proposal aims to remove obsoleted text and simplify the IPv6 policy.

You can find the full proposal and the RIPE NCC impact analysis at:
https://www.ripe.net/participate/policies/proposals/2019-06

And the draft documents at:
https://www.ripe.net/participate/policies/proposals/2019-06/draft

As per the RIPE Policy Development Process (PDP), the purpose of this 
four week extended Review Phase is to continue discussing the proposal, 
taking the impact analysis into consideration, and to review the full 
draft RIPE Policy Document.


At the end of the Review Phase, the Working Group (WG) Chairs will 
determine whether the WG has reached rough consensus. It is therefore 
important to provide your opinion, even if it is simply a restatement of 
your input from the previous phase.


We encourage you to read the proposal, impact analysis and draft 
document and send any comments to  before 6 
February 2020.


Kind regards,

Marco Schmidt
Registration Services and Policy Development Assistant Manager
RIPE NCC

[address-policy-wg] 2019-07 New Policy Proposal (Default assignment size for IXPs)

[Marco Schmidt]

Dear colleagues,

A new RIPE Policy proposal, 2019-07, "Default assignment size for IXPs"
is now available for discussion.

This proposal aims to change the default IXP assignment size from a /24
to a needs-based model, with a /27 as a minimum.

You can find the full proposal at:

https://www.ripe.net/participate/policies/proposals/2019-07

As per the RIPE Policy Development Process (PDP), the purpose of this
four week Discussion Phase is to discuss the proposal and provide
feedback to the proposer.

At the end of the Discussion Phase, the proposer, with the agreement of
the WG Chairs, will decide how to proceed with the proposal.

We encourage you to review this proposal and send your comments to
 before 13 November 2019.

Regards,

Marco Schmidt
Policy Officer
RIPE NCC

[address-policy-wg] 2019-05 Proposal Accepted (Revised IPv4 assignment policy for IXPs)

[Marco Schmidt]

Dear colleagues,

Consensus has been reached on 2019-05, "Revised IPv4 assignment policy 
for IXPs".


This proposal aimed to increase the reserved IPv4 pool for IXPs to a /15 
and finetune assignment criteria.


You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2019-05

The new RIPE Document is called ripe-730 and is available at:
https://www.ripe.net/publications/docs/ripe-730

We have already implemented the pool management part of this proposal 
(185.0.0.0/16 and the IPv4 fragments smaller than /24 have been added to 
the reserved IPv4 pool for IXPs). We estimate that this proposal will 
take around two months to fully implement.


We will send another announcement once the implementation is complete 
and the new procedures are in place.


Thank you to everyone who provided us with your input.

Kind regards,
Marco Schmidt
Policy Officer
RIPE NCC

[address-policy-wg] 2019-06 New Policy Proposal (Multiple Editorial Changes in IPv6 Policy)

[Marco Schmidt]

Dear colleagues,

A new RIPE Policy proposal, 2019-06, "Multiple Editorial Changes in IPv6 
Policy"

is now available for discussion.

This proposal aims to remove obsoleted text and simplify the IPv6 policy.

You can find the full proposal at:

https://www.ripe.net/participate/policies/proposals/2019-06


As per the RIPE Policy Development Process (PDP), the purpose of this
four week Discussion Phase is to discuss the proposal and provide
feedback to the proposer.

At the end of the Discussion Phase, the proposer, with the agreement of
the WG Chairs, will decide how to proceed with the proposal.

We encourage you to review this proposal and send your comments to
 before 6 November 2019.

Regards,

Marco Schmidt
Policy Officer
RIPE NCC

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

[Marco Schmidt]

Dear colleagues,

The draft minutes from the Address Policy Working Group sessions at RIPE 
78 have now been published:


https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-78-address-policy-working-group-minutes


Please let us know of any corrections or amendments.

Kind regards,

Marco Schmidt
Policy Officer
RIPE NCC

[address-policy-wg] 2019-05 Last Call for Comments (Revised IPv4 assignment policy for IXPs)

[Marco Schmidt]

Dear colleagues,

Proposal 2019-05, "Revised IPv4 assignment policy for IXPs", is now in 
Concluding Phase.


This proposal aims to increase the reserved IPv4 pool for IXPs to a /15 
and finetune assignment criteria.


The WG co-chairs have declared that rough consensus has been reached and 
the proposal will now move to Last Call.


As per the RIPE Policy Development Process (PDP), the purpose of this 
four week Concluding Phase is to give an opportunity to present 
well-justified objections for those who missed the previous two phases 
and wish to oppose the proposal.


Any objection must be made by 8 October 2019 and must be supported by an 
explanation.


If no substantive objections are raised by the end of Last Call, the 
proposal will complete the PDP and will be evaluated by the WG co-chairs 
for final consensus.


As this policy change has reaches rough consensus, the RIPE NCC has now 
reserved 185.0.0.0/16 for this policy change. If final consensus is 
achieved, the /16 will be used as per the policy proposal, and 
alternatively, if the proposal is withdrawn, the address space will be 
returned to the IPv4 pool for allocations.


You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2019-05

Please e-mail any final comments about this proposal to 
 before 8 October 2019.


Regards,

Marco Schmidt
Policy Officer
RIPE NCC

Re: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)

[Marco Schmidt]

Hello Gert and colleagues,


On 09/08/2019 21:43, Gert Doering wrote:

As I understand the current proposal and the NCC's impact analysis, 
implementation of this proposal would necessarily mean that the resulting IXP 
pool would be at best two disjoint /16s, at worst one /16 plus a bunch of 
smaller fragments scattered all over the address space. That'd be a shame, in 
my opinion.

Mmmh.  Marco, can you comment on whether this is an implementation thing
at the NCC, or whether you'd need a formal statement in the policy text
to make this happen?

(While it's all just numbers, some numbers look more familiar than others,
so having all IXP space "in one block" is a bit easier on "oh, these
numbers look IXPish" - so I can see that it would be nice)

Yes, this is an implementation thing. While the IPv4 Policy requires
that we set aside a /16 for unforseen circumstances, it doesn't specify
the range or that it must be a contiguous block.

At RIPE 77, Andrea Cima suggested that this (currently contiguous) /16
could be replaced with an equivalent of /23s and /24s as we near IPv4
runout:
https://ripe77.ripe.net/wp-content/uploads/presentations/71-Andrea_Cima_RIPE_77_APWG.pdf

There was general support for the idea, though some questioned the
intent of doing this to create more convenient /22 allocations. Now with
this proposal, we plan to replace the currently-reserved 185.0.0.0/16
and use this for the IXP pool if this proposal reaches consensus. So
Tore's suggestion would be achieved.

It should be noted that for this to happen, there must be at least a /16
of regular space in our remaining pool when rough consensus is reached,
to allow us to make the swap. The IPv4 Policy is clear that this
reserved space must be used for IPv4 allocations as per section 5.1.

Kind regards,

Marco Schmidt
Policy Officer
RIPE NCC

[address-policy-wg] 2019-05 Review Phase (Revised IPv4 assignment policy for IXPs)

[Marco Schmidt]

Dear colleagues,

Policy proposal 2019-05, "Revised IPv4 assignment policy for IXPs" is 
now in the Review Phase.


This proposal aims to increase the reserved IPv4 pool for IXPs to a /15 
and finetune assignment criteria.


The proposal has been updated following the last round of discussion and 
is now at version v2.0. Some of the changes made to version v1.0 include:

- The maximum assignment size to IXPs remains /22
- Defines that IPv4 ranges smaller than /24 will be added to the IXP pool

The RIPE NCC has prepared an impact analysis on this latest proposal 
version to support the community’s discussion. You can find the full 
proposal and impact analysis at:

https://www.ripe.net/participate/policies/proposals/2019-05

And the draft documents at:
https://www.ripe.net/participate/policies/proposals/2019-05/draft

As per the RIPE Policy Development Process (PDP), the purpose of this 
four week Review Phase is to continue discussion of the proposal, taking 
the impact analysis into consideration, and to review the full draft 
RIPE Policy Document.


At the end of the Review Phase, the Working Group (WG) Chairs will 
determine whether the WG has reached rough consensus. It is therefore 
important to provide your opinion, even if it is simply a restatement of 
your input from the previous phase.


We encourage you to read the proposal, impact analysis and draft 
document and send any comments to  before 6 
September 2019.


Kind regards,

Marco Schmidt
Policy Officer
RIPE NCC

Re: [address-policy-wg] 2019-02 Proposal Accepted (IPv4 Waiting List Implementation)

[Marco Schmidt]

Hi Aleksey,

At the moment we expect to reach IPv4 runout sometime in late 2019/early 
2020.
Of course, this will depend on the rate at which new members join the 
RIPE NCC and so it is difficult to make accurate predictions.


Kind regards,

Marco Schmidt
Policy Officer
RIPE NCC


On 30/07/2019 16:20, Alexey Bulgakov wrote:

Hi.

When will it happen? The RIPE NCC graph of IPs exhaustion has 
approximated statistics.


--
Kind regards,
Aleksey Bulgakov
FastTelecom, CEO
+7 926 6908729

16:59, 30 июля 2019 г., Marco Schmidt :

Dear colleagues,

Consensus has been reached on 2019-02, "IPv4 Waiting List
Implementation".

This proposal aimed at creating a waiting list based on an allocation
size of /24 once the RIPE NCC’s free IPv4 pool is exhausted.

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2019-02

The new RIPE Document is called ripe-725 and is available at:
https://www.ripe.net/publications/docs/ripe-725

We estimate that this proposal will take around one to two months to
fully implement.

We will send another announcement once the implementation is complete
and the new procedures are in place.

Thank you to everyone who provided input.

Kind regards,

Marco Schmidt
Policy Officer
RIPE NCC

[address-policy-wg] 2019-02 Last Call for Comments (IPv4 Waiting List Implementation)

[Marco Schmidt]

Dear colleagues,

Proposal 2019-02, "IPv4 Waiting List Implementation", is now in Concluding 
Phase.

This proposal aims at creating a waiting list based on an allocation size of 
/24 once the RIPE NCC’s free IPv4 pool is exhausted.

The WG co-chair has declared that rough consensus has been reached and the 
proposal will now move to Last Call.

As per the RIPE Policy Development Process (PDP), the purpose of this four week 
Concluding Phase is to give an opportunity to present well-justified objections 
for those who missed the previous two phases and wish to oppose the proposal.

Any objection must be made by 24 July 2019 and must be supported by an 
explanation.

If no substantive objections are raised by the end of Last Call, the proposal 
will complete the PDP and will be evaluated by the WG co-chairs for final 
consensus.

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2019-02

Please e-mail any final comments about this proposal to 
 before 24 July 2019.

Regards,

Marco Schmidt
Policy Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)

[Marco Schmidt]

Dear colleagues,

A new RIPE Policy proposal, 2019-05, "Revised IPv4 assignment policy for IXPs" 
is now available for discussion.

This proposal aims to increase the reserved IPv4 pool for IXPs to a /15 and 
finetune assignment criteria.

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2019-05

As per the RIPE Policy Development Process (PDP), the purpose of this four week 
Discussion Phase is to discuss the proposal and provide feedback to the 
proposer.

At the end of the Discussion Phase, the proposers, with the agreement of the WG 
Chairs, will decide how to proceed with the proposal.

We encourage you to review this proposal and send your comments to 
 before 27 June 2019.

Regards,

Marco Schmidt
Policy Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2019-01 Proposal Accepted and Implemented (Clarification of Definition for "ASSIGNED PA")

[Marco Schmidt]

Dear colleagues,

Consensus has been reached on 2019-01, "Clarification of Definition for 
"ASSIGNED PA"".

This proposal made it clear in the IPv4 Policy that the status "ASSIGNED PA" 
can also be used for assignments to an LIR's infrastructure.

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2019-01

The new RIPE Document is called ripe-720 and is available at:
https://www.ripe.net/publications/docs/ripe-720

This proposal is implemented with immediate effect.

Thank you to everyone who provided input.

Kind regards,

Marco Schmidt
Policy Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2019-02 Review Phase (IPv4 Waiting List Implementation)

[Marco Schmidt]

Dear colleagues,

Policy proposal 2019-02, "IPv4 Waiting List Implementation" is now in the 
Review Phase.

This proposal aims at creating a waiting list based on an allocation size of 
/24 once the RIPE NCC’s free IPv4 pool is exhausted.

The proposal has been updated following the last round of discussion and is now 
at version v2.0. Some of the differences from version v1.0 include:
- New proposal title
- Focus on waiting list requirements
- Adjusting the moment of policy activation

The RIPE NCC has prepared an impact analysis on this latest proposal version to 
support the community’s discussion. You can find the full proposal and impact 
analysis at:
https://www.ripe.net/participate/policies/proposals/2019-02

And the draft documents at:
https://www.ripe.net/participate/policies/proposals/2019-02/draft

As per the RIPE Policy Development Process (PDP), the purpose of this four week 
Review Phase is to continue discussion of the proposal, taking the impact 
analysis into consideration, and to review the full draft RIPE Policy Document.

At the end of the Review Phase, the WG Chairs will determine whether the WG has 
reached rough consensus. It is therefore important to provide your opinion, 
even if it is simply a restatement of your input from the previous phase.

We encourage you to read the proposal, impact analysis and draft document and 
send any comments to  before 4 June 2019.

Kind regards,

Marco Schmidt
Policy Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2019-01 Last Call for Comments (Clarification of Definition for "ASSIGNED PA")

[Marco Schmidt]

Dear colleagues,

Proposal 2019-01, "Clarification of Definition for "ASSIGNED PA"", is now in 
Concluding Phase.

This proposal aims to make it clear in the IPv4 Policy that the status 
"ASSIGNED PA" can also be used for assignments to an LIR's infrastructure.

The WG co-chair has declared that rough consensus has been reached and the 
proposal will now move to Last Call.

As per the RIPE Policy Development Process (PDP), the purpose of this four week 
Concluding Phase is to give an opportunity to present well-justified objections 
for those who missed the previous two phases and wish to oppose the proposal.

Any objection must be made by 14 May 2019 and must be supported by an 
explanation.

If no substantive objections are raised by the end of Last Call, the proposal 
will complete the PDP and will be evaluated by the WG Chairs for consensus.

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2019-01

Please e-mail any final comments about this proposal to 
 before 14 May 2019.

Regards,

Marco Schmidt
Policy Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

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

[Marco Schmidt]

Dear colleagues,

The draft minutes from the Address Policy Working Group sessions at RIPE 77 
have now been published:

https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-77-address-policy-working-group-minutes

Please let us know of any corrections or amendments.

Kind regards,

Marco Schmidt
Policy Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2018-02 Policy Proposal Withdrawn (Assignment Clarification in IPv6 Policy)

[Marco Schmidt]

Dear colleagues,

The policy proposal 2018-02, "Assignment Clarification in IPv6 Policy" has been 
withdrawn.

This proposal aimed to clarify the definition of "Assign" in the IPv6 Policy 
(section 2.6).

The proposal is archived and can be found at:
https://www.ripe.net/participate/policies/archived-policy-proposals/archive-policy-proposals/

Reason for withdrawal:
The proposer decided it was best to find agreement on a problem statement 
before developing new policy text.

Kind regards,

Marco Schmidt
Policy Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2019-01 Review Phase (Clarification of Definition for "ASSIGNED PA")

[Marco Schmidt]

Dear colleagues,

Policy proposal 2019-01, "Clarification of Definition for "ASSIGNED PA"" is now 
in the Review Phase.

This proposal aims to make it clear in the IPv4 Policy that the status 
"ASSIGNED PA" can also be used for assignments to an LIR's infrastructure.

The RIPE NCC has prepared an impact analysis to support the community’s 
discussion. You can find the full proposal and impact analysis at:
https://www.ripe.net/participate/policies/proposals/2019-01

And the draft documents at:
https://www.ripe.net/participate/policies/proposals/2019-01/draft

As per the RIPE Policy Development Process (PDP), the purpose of this four week 
Review Phase is to continue discussing the proposal, taking the impact analysis 
into consideration, and to review the full draft RIPE Policy Document.

At the end of the Review Phase, the WG Chairs will determine whether the WG has 
reached rough consensus. It is therefore important to provide your opinion, 
even if it is simply a restatement of your input from the previous phase.

We encourage you to read the proposal, impact analysis and draft document and 
send any comments to  before 9 April 2019.

Kind regards,

Marco Schmidt
Policy Development Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

Re: [address-policy-wg] IPv6 PI justification requirements

[Marco Schmidt]

Dear Cynthia,

Thank you for raising this topic.

We are seeing more requests from organisations that want separate /48 PI 
assignments for different locations. We approve these requests if the 
policy requirements are met - primarily that their different routing 
requirements are documented.


One of the best ways to do this is through an addressing plan. While I 
can't discuss the specifics of your case on the mailing list, I can 
state that it wasn't the physical locations that made your request 
unique. Feel free to contact me offline if you would like any further 
clarification around the policy requirements as they apply to your 
situation.


It's also worth noting that if an LIR wants to request a second /29, 
they would need to provide justification in this case as well.


Of course, there's always the option to propose a policy change if the 
current policy appears too strict or in need of improvement, and I am 
always available to help people get started with this.


Kind regards,

Marco Schmidt
Policy Officer
RIPE NCC


On 27/02/2019 11:08, Cynthia Revström wrote:

Hi Gert,

As I attempted to explain this was 3 separate uses that required 
separate announcements.


- Cynthia

On 2019-02-27 11:05, Gert Doering wrote:

Hi,

On Wed, Feb 27, 2019 at 08:47:04AM +, Krasimir Ganchev via 
address-policy-wg wrote:
I couldn't agree more with Cynthia, policies are too strict and 
require justification which doesn't allow expansion over time and is 
just based on immediate needs.


All that especially in the era of exhausted IPv4 is practically 
unbelievable.


No offense of course, just the reality.

This claim is just not true.

There might be some cases where expectations and grandeur plans do not
match reality, and in this cases it's reasonable that the NCC is strict
and will not hand out a /19 to someone who can fulfill all their 
expected

needs with a /32.

There are other cases where the NCC is asking lots of questions, and 
maybe
there are cases where the NCC is too strict.  So we need to talk 
about these

and see if it's "lack of reasonable documentation on the user side" or
"annoying interpretation on the NCC side".

OTOH, a /48 for an end-user site or a /29 for an ISP is pretty huge
(we have not even extended our /32 to a /29 as we assume that we will
never manage to fill the /32) - and documented reality shows that *if*
you need more, you can get it today.

Gert Doering
 -- APWG chair, and IPv6 user from day one, where the 
policies were

    *much* stricter than today

Re: [address-policy-wg] can deadbeat LIRs reverse IPv4 exhaustion?

[Marco Schmidt]

Dear Jim, all,

I would just like to provide some clarification regarding your point below.


On 07/02/2019 11:14, Jim Reid wrote:



On 7 Feb 2019, at 07:59, Carlos Friaças via address-policy-wg 
 wrote:

Even when the pools reach ZERO, if 1000 LIRs stop paying fees (and that's only one 
example/route), the "runout" will be temporarily reverted, and handing out IPv4 
addresses will be again, in theory, possible.

How is that possible? Once the pools reach zero, there are no more addresses to 
hand out.

An RIR can't conjure up IPv4 address space out of thin air. If it was able to 
do that, we could just continue forever with business as usual and allocate v4 
until the heat death of the universe.

Besides, there’s no mechanism or policy for the NCC to recover addresses from 
LIRs that don’t pay their bills. If such mechanisms or policies existed, they’d 
be unworkable. There’s no way of knowing for sure that those addresses weren’t 
being used. So if they were reclaimed, the addresses couldn’t be allocated to 
someone else.



Section 9.0 of the IPv4 policy states that an LIR may be closed if it 
does not pay money it owes to the RIPE NCC. The policy also states that 
the RIPE NCC takes on responsibility for the address space of LIRs that 
are closed:

https://www.ripe.net/publications/docs/ripe-708#9

Based on the policy, we have existing procedures to de-register IPv4 
address space and re-issue the addresses. Our procedure in these cases 
includes announcement checks and a quarantine period to minimise 
routablity issues for future resource holders.


In fact, many of the allocations we are currently making have gone 
through such a recycling process.
We expect that we will continue to receive IPv4 addresses due to LIR 
closures and other reasons for some time after the current IPv4 pool has 
been exhausted.


Kind regards,

Marco Schmidt
Policy Officer
RIPE NCC

[address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)

[Marco Schmidt]

Dear colleagues,

A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24"
is now available for discussion.

This proposal aims to reduce the IPv4 allocation size to a /24 once the
RIPE NCC is unable to allocate contiguous /22 ranges.

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2019-02

As per the RIPE Policy Development Process (PDP), the purpose of this
four week Discussion Phase is to discuss the proposal and provide
feedback to the proposer.

At the end of the Discussion Phase, the proposer, with the agreement of
the WG Chairs, will decide how to proceed with the proposal.

We encourage you to review this proposal and send your comments to
 before 5 March 2019.

Regards,

Marco Schmidt
Policy Officer

Re: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification

[Marco Schmidt]

Hello Jordi and all,

Allow me to provide some clarification.

While 2016-04 was indeed focused primarily on IPv6 PI assignments, the 
adjusted definition in section 2.6 applies to all assignments.


The RIPE NCC Impact Analysis says:
-
This definition of sub-assignments will apply for assignments within 
IPv6 allocations and for IPv6 Provider Independent (PI) Assignments.
While LIRs have to consider this definition when providing assignments, 
the RIPE NCC will apply this understanding during the evaluation of IPv6 
PI requests and when reviewing assignments within allocations during a 
potential audit of an LIR.


https://www.ripe.net/participate/policies/proposals/2016-04

Kind regards,
Marco Schmidt
Policy Officer
RIPE NCC


On 17/01/2019 20:34, JORDI PALET MARTINEZ via address-policy-wg wrote:


Hi Kai,

You’re missing that 2016-04 is for the clarification of IPv6 PI, not PA.

https://www.ripe.net/participate/policies/proposals/2016-04


Regards,

Jordi

*De: *address-policy-wg  en nombre 
de Kai 'wusel' Siering 

*Organización: *Unseen University, Department of Magic Mails
*Fecha: *jueves, 17 de enero de 2019, 20:16
*Para: *
*Asunto: *Re: [address-policy-wg] suggestions from the list about IPv6 
sub-assignment clarification


On 17.01.2019 15:37, JORDI PALET MARTINEZ via address-policy-wg wrote:

We need to consider as well, as I depicted already before, that if you have 
a physical sever, you probably need also multiple addresses for that server, 
that's why, I think the policy should allow that (this is clearly now allowed 
now).


Let's consult ripe-707:


  2.6. Assign

To “assign” means to delegate address space to an ISP or End User
for specific use within the Internet infrastructure they operate.
Assignments must only be made for specific purposes documented by
specific organisations and are not to be sub-assigned to other
parties.

Providing another entity with separate addresses (not prefixes)
from a subnet used on a link operated by the assignment holder is
not considered a sub-assignment. This includes for example letting
visitors connect to the assignment holder's network, connecting a
server or appliance to an assignment holder's network and setting
up point-to-point links with 3rd parties.


  2.9. End Site

An End Site is defined as an End User (subscriber) who has a
business or legal relationship (same or associated entities) with
a service provider that involves:

·that service provider assigning address space to the End User

·that service provider providing transit service for the End User
to other sites

·that service provider carrying the End User's traffic

·that service provider advertising an aggregate prefix route that
contains the End User's assignment


By these definitions, only an IR ("2.1. Internet Registry (IR)")  can 
"assign" allocated address space to non-IRs, i. e. ISPs or End Users, 
in the context of ripe-707.
The term "ISP" is not wll defined within ripe-707 except for "LIRs are 
generally ISPs whose customers are primarily End Users and possibly 
other ISPs" in "2.4. Local Internet Registry (LIR)". The graph in "2. 
Definitions" suggests that ISPs are the entities that are actually 
creating the Internet, whereas (L)IRs are involved in distributing IP 
space only. Since, following 2.6., only an (I)SP _that also is an 
(L)IR_ could, acting in it's (L)IR role, "assign" address space, 2.9. 
should therefore receive a friendly "s/service provider/ISP/g" and 
have the first bullet point removed.


On the other hand, 2.6. in it's current form – except for the 
"separate addresses (not prefixes)" issue, as any singke address IS 
technically also a /128 prefix – seems rather clear to me: if it's for 
the documented "specific use within the Internet infrastructure they 
operate", it's fine. Otherwise, a separate assignment is needed for 
either a new specific use _or a different End User_, so the ISP or End 
User (or the ISP for it's End User) will have to request that from an 
(L)IR (which it may be itself, if the ISP or End User is an LIR as well).


Thus, if you need "multiple addresses" for your "physical server" and 
you received an assignment for your infrastructure including your 
server(s), I cannot see a conflict with ripe-707. If you want to add a 
dedicated server for a customer of yours, I'd expect you to get a new 
(non-PI) prefix (i. e. no less than a /64 as per 5.4.1.) for this 
different End User from your LIR of choice (or have that End User 
apply for a /48 PIv6 via your cooperative LIR).


Regards,
-kai


**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may b

Re: [address-policy-wg] Policy violation

[Marco Schmidt]

Dear Aleksey and all,

We would like to clarify the situation because the policy refers to
transfers between RIPE NCC members and not transfers between the LIR
accounts that members might hold. A member may hold multiple LIR accounts.

Regarding the section that you refer to in the procedure, please see the
mail that was sent to the NCC Announce mailing list in October:
https://www.ripe.net/ripe/mail/archives/ncc-announce/2018-October/001286.html

This message explains how the RIPE NCC processes transfers of IPv4
address space or 16-bit ASNs due to a merger, acquisition or any other
change in business structure.

We hope this clarifies that no policy violation has taken place. A
merger or acquisition is possible at any time and must take place
following the processes outlined in the email.

Kind regards,

Marco Schmidt
Policy Officer
RIPE NCC


On 17/12/2018 19:21, Aleksey Bulgakov wrote:

Hi.

Regarding our situation. We have 3 accounts opened this year (for
different legal entities). We provided the oficial government
documents that confirm M procedure. But the NCC doesn't want to
merge 2 accounts (of closed organizations) into the 1st account due to
it is necessary to convert such accounts into additional account of
receiving party, regarding
https://www.ripe.net/publications/docs/ripe-709#transfer36.

But there is restriction to transfer the resources during 24 month
between accounts of the same member. So we should pay for additional 2
years fees.
пн, 17 дек. 2018 г. в 21:12, Jens Ott - Opteamax GmbH :



Which is kind of the point.  The 24 month restriction holds, unless
  one LIR gets bought/merged, and the latter needs to be proved by
official documents.

This is also not correct! At least from my experience, the restriction
also persists on being bought!

The difference between being bought and merged is, at least from
German legal point of view, that in a merge (=Verschmelzung) the $OLD
company does not exist any longer but becomes fully integrated into
$NEW company, while in buying a company, $OLD stays it's own legal entit
y.

 From my experience ONLY A MERGE IS accepted by RIPE to not apply
24month restriction, while being bought does not shorten this restrictio
n.

BR

--
Jens Ott
Geschäftsführer

Opteamax GmbH

Simrockstr. 4b
53619 Rheinbreitbach

Tel.:  +49 2224 969500
Fax:   +49 2224 97691059
Email: j...@opteamax.de

HRB: 23144, Amtsgericht Montabaur
Geschäftsführer: Jens Ott
Umsatzsteuer-ID.: DE264133989

Re: [address-policy-wg] Policies and Guidelines for Assignments for Network Infrastructure and End User Networks

[Marco Schmidt]

Dear Töma,

Thank you for your questions. Please allow me to provide some clarification.

Regarding our LIR Training Course - it's important to note that this is 
intended to help people fulfil their role as representatives of a member. Our 
training courses do not provide a different interpretation of RIPE policies 
("either more strict or more relaxed") - but rather represent the shared 
understanding and practices of network operators in the RIPE community. That 
being said, we are constantly reviewing our training material and will take 
another look at this with your feedback in mind.

Nick and Leo have already provided some clarification around the historical 
context of section 6.2 of the policy (ripe-708). We agree with their comments 
and there's not much we can add beyond this.

If you feel that the wording in this section is ambiguous, we invite you to 
make use of the Policy Development Process to propose a change to the policy. I 
will be happy to follow-up with you offline to provide more details and 
guidance to help you create a policy proposal.

Kind regards,
Marco Schmidt
Policy Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2018-02 Discussion Phase Extended (Assignment Clarification in IPv6 Policy)

[Marco Schmidt]

Dear colleagues,

RIPE Policy proposal 2018-02, "Assignment Clarification in IPv6 Policy" is 
still available for discussion.

This proposal aims to clarify the definition of "Assign" in the IPv6 Policy 
(ripe-707, section 2.6).

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2018-02

As per the RIPE Policy Development Process (PDP), the purpose of this three 
week extended Discussion Phase is to discuss the proposal and provide feedback 
to the proposer.

At the end of the Discussion Phase, the proposer, with the agreement of the WG 
Chairs, will decide how to proceed with the proposal.

We encourage you to review this proposal and send your comments to 
 before 25 October 2018.

Regards,

Marco Schmidt
Policy Officer
RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

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

[Marco Schmidt]

Dear colleagues,

The draft minutes from the Address Policy Working Group sessions at RIPE 76 
have now been published:

https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-76-address-policy-working-group-minutes


Please let us know of any corrections or amendments.

Kind regards,

Marco Schmidt
Policy Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2018-03 Proposal Accepted and Implemented (Fixing Outdated Information in the IPv4 Policy)

[Marco Schmidt]

Dear colleagues,

Consensus has been reached on 2018-03, "Fixing Outdated Information in the IPv4 
Policy".

This proposal fixed outdated information in the RIPE Policy "IPv4 Address 
Allocation and Assignment Policies for the RIPE NCC Service Region".

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2018-03

The new RIPE Document is called ripe-708 and is available at:
https://www.ripe.net/publications/docs/ripe-708

This proposal is implemented with immediate effect.

Thank you to everyone who provided input.

Kind regards,

Marco Schmidt
Policy Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2018-02 New Version Policy Proposal (Assignment Clarification in IPv6 Policy)

[Marco Schmidt]

Dear colleagues,

RIPE Policy proposal, 2018-02, "Assignment Clarification in IPv6 Policy" is now 
available for discussion again.

This proposal aims to clarify the definition of "Assign" in ripe-707 (section 
2.6).

This proposal has been updated following the last round of discussion and is 
now at version v2.0. Some of the differences from version v1.0 include:
- Adjusting the scope of what is considered a sub-assignment

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2018-02

As per the RIPE Policy Development Process (PDP), the purpose of this four week 
Discussion Phase is to discuss the proposal and provide feedback to the 
proposer.

At the end of the Discussion Phase, the proposer, with the agreement of the WG 
Chairs, will decide how to proceed with the proposal.

We encourage you to review this proposal and send your comments to 
 before 27 September 2018.

Regards,

Marco Schmidt
Policy Officer
RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] Proposal Implemented: 2018-01, "Organisation-LIR Clarification in IPv6 Policy"

[Marco Schmidt]

Dear colleagues,

We are pleased to announce that we have implemented the policy proposal 
2018-01, "Organisation-LIR Clarification in IPv6 Policy".

This proposal clarified the wording used in the RIPE IPv6 Policy regarding 
terms such as "organisation" and "LIR".

The archived policy proposal can be found at:
https://www.ripe.net/participate/policies/proposals/2018-01

The RIPE Document, "IPv6 Address Allocation and Assignment Policy", is 
available at:
https://www.ripe.net/publications/docs/ripe-707


Kind regards,

Marco Schmidt
Policy Officer
RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2018-03 Last Call for Comments (Fixing Outdated Information in the IPv4 Policy)

[Marco Schmidt]

Dear colleagues,

Proposal 2018-03, "Fixing Outdated Information in the IPv4 Policy", is now in 
Concluding Phase.

This proposal aims to fix outdated information in the RIPE Policy "IPv4 Address 
Allocation and Assignment Policies for the RIPE NCC Service Region".

The WG co-chair has declared that rough consensus has been reached and the 
proposal will now move to Last Call.

As per the RIPE Policy Development Process (PDP), the purpose of this four week 
Concluding Phase is to give an opportunity to present well-justified objections 
for those who missed the previous two phases and wish to oppose the proposal.

Any objection must be made by 22 August 2018 and must be supported by an 
explanation.

If no substantive objections are raised by the end of Last Call, the proposal 
will complete the PDP and will be evaluated by the WG Chairs for consensus.

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2018-03

Please e-mail any final comments about this proposal to 
 before 22 August 2018.

Regards,

Marco Schmidt
Policy Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2018-01 Proposal Accepted (Organisation-LIR Clarification in IPv6 Policy)

[Marco Schmidt]

Dear colleagues,

Consensus has been reached on 2018-01, "Organisation-LIR Clarification in IPv6 
Policy".

The goal of this proposal was to clarify the wording used in RIPE-699 regarding 
terms such as "organisation" and "LIR".

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2018-01

The new RIPE Document is ripe-707 and is available at:
https://www.ripe.net/publications/docs/ripe-707

We estimate that this proposal will take around two weeks to fully implement.

We will send another announcement once the implementation is complete
and the new procedures are in place.

Thank you to everyone who provided input.

Kind regards,

Marco Schmidt
Policy Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2018-03 Review Phase (Fixing Outdated Information in the IPv4 Policy)

[Marco Schmidt]

Dear colleagues,

Policy proposal 2018-03, "Fixing Outdated Information in the IPv4 Policy" is 
now in the Review Phase.

This proposal aims to fix outdated information in the RIPE Policy "IPv4 Address 
Allocation and Assignment Policies for the RIPE NCC Service Region".

The proposal has been updated following the last round of discussion and is now 
at version v2.0. Some of the differences from version v1.0 include:
- Adding a direct reference to the "IANA IPv4 Special-Purpose Address Registry"

The RIPE NCC has prepared an impact analysis on this latest proposal version to 
support the community’s discussion. You can find the full proposal and impact 
analysis at:
https://www.ripe.net/participate/policies/proposals/2018-03

And the draft documents at:
https://www.ripe.net/participate/policies/proposals/2018-03/draft

As per the RIPE Policy Development Process (PDP), the purpose of this four week 
Review Phase is to continue discussing the proposal, taking the impact analysis 
into consideration, and to review the full draft RIPE Policy Document.

At the end of the Review Phase, the WG Chairs will determine whether the WG has 
reached rough consensus. It is therefore important to provide your opinion, 
even if it is simply a restatement of your input from the previous phase.

We encourage you to read the proposal, impact analysis and draft document and 
send any comments to  before 19 July 2018.

Kind regards,

Marco Schmidt
Policy Officer
RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2018-01 Review Phase (Organisation-LIR Clarification in IPv6 Policy)

[Marco Schmidt]

Dear colleagues,

Policy proposal 2018-01, "Organisation-LIR Clarification in IPv6 Policy" is now 
in the Review Phase.

This proposal aims to clarify the wording used in ripe-699 regarding terms such 
as "organisation" and "LIR".

The proposal has been updated following the last round of discussion and is now 
at version v2.0. Some of the differences from version v1.0 include:
- Clarifies when the subsequent allocation policy applies
- Fixing some typos

The RIPE NCC has prepared an impact analysis on this latest proposal version to 
support the community’s discussion. You can find the full proposal and impact 
analysis at:
https://www.ripe.net/participate/policies/proposals/2018-01

And the draft documents at:
https://www.ripe.net/participate/policies/proposals/2018-01/draft

As per the RIPE Policy Development Process (PDP), the purpose of this four week 
Review Phase is to continue discussing the proposal, taking the impact analysis 
into consideration, and to review the full draft RIPE Policy Document.

At the end of the Review Phase, the WG Chairs will determine whether the WG has 
reached rough consensus. It is therefore important to provide your opinion, 
even if it is simply a restatement of your input from the previous phase.

We encourage you to read the proposal, impact analysis and draft document and 
send any comments to <address-policy-wg@ripe.net> before 1 June 2018.

Kind regards,

Marco Schmidt
Policy Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2018-04 New Proposal (PDP Clarification) to be discussed on RIPE Discussion Mailing List

[Marco Schmidt]

Dear colleagues,

A new RIPE proposal, 2018-04, "PDP Clarification" has been published on the 
RIPE Discussion mailing list for discussion.

This proposal aims to clarify the options available to the WG chairs at the end 
of the Review Phase of the RIPE Policy Development Process (PDP).

Please note that since changes to the PDP can affect all RIPE Working Groups, 
the RIPE Chair decided to discuss this proposal on the RIPE Discussion mailing 
list. The RIPE Chair will also moderate the proposal discussion.

We wanted to notify the Address Policy Working Group in particular, as most of 
the policy proposals are discussed here.

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2018-04


We encourage you to review this proposal and join the discussion on the RIPE 
Discussion mailing list (ripe-l...@ripe.net).

Regards,

Marco Schmidt
Policy Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2018-03 New Policy Proposal (Fixing Outdated Information in the IPv4 Policy)

[Marco Schmidt]

Dear colleagues,

A new RIPE Policy proposal, 2018-03, "Fixing Outdated Information in the IPv4 
Policy" is now available for discussion.

This proposal aims to fix outdated information in the RIPE Policy "IPv4 Address 
Allocation and Assignment Policies for the RIPE NCC Service Region".

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2018-03

As per the RIPE Policy Development Process (PDP), the purpose of this four week 
Discussion Phase is to discuss the proposal and provide feedback to the 
proposer.

At the end of the Discussion Phase, the proposer, with the agreement of the WG 
Chairs, will decide how to proceed with the proposal.

We encourage you to review this proposal and send your comments to 
<address-policy-wg@ripe.net> before 23 May 2018.

Regards,

Marco Schmidt
Policy Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

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

[Marco Schmidt]

Dear colleagues,

The draft minutes from the Address Policy Working Group sessions at RIPE 75 
have now been published:

https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-75-address-policy-working-group-minutes


Please let us know of any corrections or amendments.

Kind regards,

Marco Schmidt
Policy Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2016-04 Proposal Accepted (IPv6 Sub-assignment Clarification)

[Marco Schmidt]

Dear colleagues,

Consensus has been reached on 2016-04, "IPv6 Sub-assignment Clarification".

The goal of this proposal was to re-define the term "sub-assignment" for IPv6.

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2016-04

The new RIPE Document is ripe-699 and is available at:
https://www.ripe.net/publications/docs/ripe-699

We estimate that this proposal will take around two weeks to fully implement.

We will send another announcement once the implementation is complete
and the new procedures are in place.

Thank you to everyone who provided input.

Kind regards,

Marco Schmidt
Policy Development Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] LACNIC "Proposal to create a Global Internet Registry (GIR)"

[Marco Schmidt]

Dear colleagues,

We would like to make you aware of a policy proposal that is being discussed in 
the LACNIC community, called "Proposal to create a Global Internet Registry 
(GIR)". You can find the proposal here: 
https://politicas.lacnic.net/politicas/detail/id/LAC-2018-1?language=en 

This is a global policy proposal, meaning that it would apply to all five RIRs. 
However, each RIR community would first need to ratify an identical version of 
the policy before it could be implemented. 

No such policy proposal has yet been submitted in our service region. We will 
let you know of any further developments. 

You can find more on the global policy development process here: 
https://www.nro.net/policies/global-policies-development-process/

Kind regards

Marco Schmidt
Policy Development Officer
RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2018-01 New Policy Proposal (Organisation-LIR Clarification in IPv6 Policy)

[Marco Schmidt]

Dear colleagues,

A new RIPE Policy proposal, 2018-01, "Organisation-LIR Clarification in IPv6 
Policy" is now available for discussion.

This proposal aims to clarify the wording used in ripe-684 regarding terms such 
as "organisation" and "LIR".

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2018-01

As per the RIPE Policy Development Process (PDP), the purpose of this four week 
Discussion Phase is to discuss the proposal and provide feedback to the 
proposer.

At the end of the Discussion Phase, the proposers, with the agreement of the WG 
Chairs, will decide how to proceed with the proposal.

We encourage you to review this proposal and send your comments to 
<address-policy-wg@ripe.net> before 23 March 2018.

Regards,

Marco Schmidt
Policy Development Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)

[Marco Schmidt]

Dear Sander and Jordi,

On 2018-01-19 11:57:38 CET, Sander Steffann wrote:
> Hi Jordi,
> 
> > 1) Policy text say: "... separate addresses (not prefixes) ...".
> > 2) Max proposal say: "... or anything alike where devices of non-members of 
> > the organisation would get assigned an IP out of the organisation’s prefix 
> > ..."
> > 3) Max proposal say: "... Explicitly allowing another entity to be provided 
> > with addresses from a subnet ..."
> > 4) Max proposal say: "... A subnet in the spirit of this policy is a prefix 
> > from the PI/PA assignment with a prefix length of /64 or longer ..."
> > 5) Max proposal say: "... or for housing/hosting for servers in data 
> > centres ..."
> > 6) IA say: "... There are cases where a /64 is needed per customer to 
> > provide a separate address ..."
> > 7) IA say: "... It is the RIPE NCCs understanding that assignments as 
> > described above are dynamic in nature, either by varying the prefix or 
> > interface identifier (IID) over time. Any permanent and static assignments 
> > of a prefix would still be considered a sub-assignment ..."
> > 8) IA say: "... by using single IPv6 addresses for End User devices and 
> > services ..."
> > 
> > [...]
> > 
> > 5 seem to indicate that this is acceptable in data centres, but 7 says 
> > permanent and static ... I don't see how a data centre can do temporary 
> > addresses?
> 
> Now that is indeed a contradiction that I agree with. Here the NCC's 
> interpretation is more strict than what the policy says, and that should be 
> corrected. Marco, can you look at this again from the NCC's perspective?
> 
> Cheers,
> Sander
> 

I'm happy to provide some clarification here.

If this policy change is accepted, it will be possible to connect a customer 
server to the IPv6 PI assignment holder's network, provided only a separate 
address is used. This is clearly specified in the proposed policy text.

Our reference to the dynamic provision of a prefix was referring to 
configuration mechanisms that are mainly used to provide Internet access to 
customers. The RIPE NCC's approach aims to support the intent of the proposal 
to allow IPv6 PI assignments for use cases such as (public) Wi-Fi networks but 
to discourage the use of IPv6 PI for permanent broadband services.

Kind regards,

Marco Schmidt
Policy Development Officer
RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)

[Marco Schmidt]

Dear Max,

On 2018-01-15 18:23:42 CET, Maximilian Wilhelm wrote:
> As said before somewhere (I'm not sure wether on a RIPE meeting or
> here on the list), the RS folks said, that they use the proposal text
> as well as the summary/rationale as guidance what is allowed and what
> isn't.
> 
> Maybe Ingrid, Andrea, Marco, * from the NCC can comment on that?
> 

Yes, this is correct.

Whenever there is a question about the interpretation of RIPE Policies,
we can refer to proposal summary as well to the impact analysis to
ensure the correct understanding of the policy and its intent.

Kind regards,
Marco Schmidt
Policy Development Officer
RIPE NCC


Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)

[Marco Schmidt]

Dear Jordi,

Thank you for your question.

On 2018-01-15 11:21:10 CET, Jordi Palet Martinez wrote:
> Furthermore, I will like a clarification from NCC about what I mention in the 
> mike, I think is this comment:
> 
>   One of the opposing remark was that this would prevent "unique prefix 
>   per host" style allocations, but that was addressed by Marco at the 
>   APWG meeting already - the RS interpretation is "this would work".
> 

My comment during the Address Policy WG session at RIPE 75 was referring to 
configuration mechanisms where a /64 is needed per customer to provide a 
separate address, for instance by using dedicated (V)LANs to connect WiFi 
customers. Such mechanisms will be considered in line with the policy.

Section A of the impact analysis provides more details on our understanding for 
these cases.
https://www.ripe.net/participate/policies/proposals/2016-04

I hope this clarifies.

Kind regards,

Marco Schmidt
Policy Development Officer
RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2016-04 Last Call for Comments (IPv6 Sub-assignment Clarification)

[Marco Schmidt]

Dear colleagues,

Proposal 2016-04, "IPv6 Sub-assignment Clarification", is now in Concluding 
Phase.

The goal of this proposal is to re-define the term "sub-assignment" for IPv6.

The WG Chair has declared that rough consensus has been reached and the 
proposal will now move to Last Call.

As per the RIPE Policy Development Process (PDP), the purpose of this four week 
Concluding Phase is to give an opportunity to present well-justified objections 
for those who missed the previous two phases and wish to oppose the proposal.

Any objection must be made by 13 February 2018 and must be supported by an 
explanation.

If no substantive objections are raised by the end of Last Call, the proposal 
will complete the PDP and will be evaluated by the WG Chairs for consensus.

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2016-04

Please e-mail any final comments about this proposal to 
<address-policy-wg@ripe.net> before 13 February 2018.

Regards,

Marco Schmidt
Policy Development Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2016-04 Review Phase Extended (IPv6 Sub-assignment Clarification)

[Marco Schmidt]

Dear colleagues,

Policy proposal 2016-04, "IPv6 Sub-assignment Clarification" is now in the 
extended Review Phase.

The goal of this proposal is to re-define the term "sub-assignment" for IPv6.

You can find the full proposal and the RIPE NCC impact analysis at:
https://www.ripe.net/participate/policies/proposals/2016-04

And the draft documents at:
https://www.ripe.net/participate/policies/proposals/2016-04/draft

As per the RIPE Policy Development Process (PDP), the purpose of this four week 
extended Review Phase is to continue discussing the proposal, taking the impact 
analysis into consideration, and to review the full draft RIPE Policy Document.

At the end of the Review Phase, the WG Chairs will determine whether the WG has 
reached rough consensus. 

We encourage you to read the proposal, impact analysis and draft document and 
send any comments to <address-policy-wg@ripe.net> before 27 December 2017.

Kind regards,

Marco Schmidt
Policy Development Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)

[Marco Schmidt]

Dear Max,

On 2017-10-19 15:33:18 CET, Maximilian Wilhelm wrote:
> There seem's to be some glitch in the comparison between the proposal
> versions. The diff seems to be in the wrong direction. Could you have
> a look at that?
> 

Thank you for raising this issue.

Yesterday we deployed an update to our diff tool, which now shows the content 
of the later proposal version as the added content.

You can see an example of this in your proposal 2016-04, "IPv6 Sub-assignment 
Clarification":
https://www.ripe.net/s/y73A

Kind regards,

Marco Schmidt
Policy Development Officer
RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2017-03 Policy Proposal Withdrawn (Reducing Initial IPv4 Allocation, Aiming to Preserve a Minimum of IPv4 Space for Newcomers)

[Marco Schmidt]

Dear colleagues,

The policy proposal 2017-03, "Reducing Initial IPv4 Allocation, Aiming to 
Preserve a Minimum of IPv4 Space for Newcomers" has been withdrawn.

The proposal is archived and can be found at:
https://www.ripe.net/participate/policies/archived-policy-proposals/archive-policy-proposals/

Reason for withdrawal:

The proposers felt unable to create a second draft that addressed conflicting 
objections.

Regards,

Marco Schmidt
Policy Development Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)

[Marco Schmidt]

Dear colleagues,

Policy proposal 2016-04, "IPv6 Sub-assignment Clarification" is now in the 
Review Phase.

The goal of this proposal is to re-define the term "sub-assignment" for IPv6.

This proposal has been updated following the last round of discussion and is 
now at version v2.0.
Some of the differences from version v1.0 include:
- the scope is extended to all IPv6 assignments
- it defines that the provision of separate IPv6 addresses is not considered a 
sub-assignment

The RIPE NCC has prepared an impact analysis on this latest proposal version to 
support the community’s discussion. You can find the full proposal and impact 
analysis at:
https://www.ripe.net/participate/policies/proposals/2016-04

And the draft documents at:
https://www.ripe.net/participate/policies/proposals/2016-04/draft

As per the RIPE Policy Development Process (PDP), the purpose of this four week 
Review Phase is to continue discussing the proposal, taking the impact analysis 
into consideration, and to review the full draft RIPE Policy Document.

At the end of the Review Phase, the WG Chairs will determine whether the WG has 
reached rough consensus. It is therefore important to provide your opinion, 
even if it is simply a restatement of your input from the previous phase.

We encourage you to read the proposal, impact analysis and draft document and 
send any comments to <address-policy-wg@ripe.net> before 17 November 2017.

Kind regards,

Marco Schmidt
Policy Development Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

Re: [address-policy-wg] Agenda for APWG in Dubai (v1)

[Marco Schmidt]

Hello,

Yes, I will mention 2017-02 in my update and will put extra emphasis on 
where and when this proposal will be discussed.


Marco


On 25/09/2017 19:25, Sander Steffann wrote:

Noted, we'll refer people to anti abuse when discussing open policy proposals. 
Marco: I assume this is already on your list, but please double check :)

Cheers,
Sander


Op 25 sep. 2017 om 14:02 heeft Malcolm Hutty  het volgende 
geschreven:

Dear WG Chairs,

This is a request for a short agenda item for Dubai, or matter arising.

I would like the WG to be aware of policy proposal 2017-02 that has been
tabled in abuse-wg, for the RIPE NCC to conduct validation of abuse-cc.

https://www.ripe.net/participate/policies/proposals/2017-02

No insult intended to abuse-wg, but it's not the most well attended WG.
I'm not trying to start a debate in address-policy, but I think you
could help by giving just a moment's "advertising" that this is going
on, so that more people can consider whether this is a good idea.

Malcolm.
--
Malcolm Hutty | tel: +44 20 7645 3523
   Head of Public Affairs | Read the LINX Public Affairs blog
London Internet Exchange | http://publicaffairs.linx.net/

 London Internet Exchange Ltd
   Monument Place, 24 Monument Street London EC3R 8AJ

 Company Registered in England No. 3137929
   Trinity Court, Trinity Street, Peterborough PE1 1DA

Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)

[Marco Schmidt]

Hello Tim,

On 2017-09-22 15:39:01 CET, Tim Chown wrote:
> There’s an argument to track and follow policies implemented elsewhere, and 
> keep in step with those. LACNIC has adopted /24 it seems, and ARIN have a /10 
> of IPv4 from which they can hand out /28 to /24. what are the current APNIC 
> or AFRINIC policies?
> 

I am happy to provide some information here.

In the AFRINIC region, in the final exhaustion phase, the minimum 
allocation/assignment size will be a /24, and the maximum will be a /22 per 
allocation/assignment.
https://www.afrinic.net/library/policies/1829-afrinic-consolidated-policy-manual#s5_4

In the APNIC region, the minimum allocation size for IPv4 is a /24.
Each APNIC account holder is eligible to receive IPv4 allocations totalling a 
maximum /22 from the APNIC 103/8 IPv4 address pool (Final /8 Block) and 
additional allocations up to a maximum of /22 address space from the APNIC 
non-103/8 IPv4 address pool.
https://www.apnic.net/community/policy/resources#Part-2:-IPv4-Policy

I hope this clarifies your question.

Kind regards,
Marco Schmidt
Policy Development Officer
RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)

[Marco Schmidt]

Dear colleagues,

A new RIPE Policy proposal, 2017-03, "Reducing Initial IPv4 Allocation,
aiming to preserve a minimum of IPv4 space", is now available for discussion.

The goal of this proposal is to reduce the IPv4 allocations made by the RIPE NCC
to a /24 (currently a /22) and only to LIRs that have not received an IPv4 
allocation
directly from the RIPE NCC before.

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2017-03/

As per the RIPE Policy Development Process (PDP), the purpose of this
four-week Discussion Phase is to discuss the proposal and provide feedback to 
the proposer.

At the end of the Discussion Phase, the proposer, with the agreement of
the RIPE Working Group Chairs, decides how to proceed with the proposal.

We encourage you to review this proposal and send your comments to
<address-policy-wg@ripe.net> before 20 October 2017.

Kind regards,

Marco Schmidt
Policy Development Officer
RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2017-01 Policy Proposal Withdrawn (Publish statistics on Intra-RIR Legacy updates)

[Marco Schmidt]

Dear colleagues,

The policy proposal 2017-01, "Publish statistics on Intra-RIR Legacy updates" 
has been withdrawn.

The proposal is archived and can be found at:
https://www.ripe.net/participate/policies/archived-policy-proposals/archive-policy-proposals/

Reason for withdrawal:

The proposer didn't see enough community support, especially from Legacy 
Resource Holders as the parties that would be most affected.

Regards

Marco Schmidt
Policy Development Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

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

[Marco Schmidt]

Dear colleagues,

The draft minutes from the Address Policy Working Group sessions at RIPE 74 
have now been published:

https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-74


Please let us know of any corrections or amendments.

Kind regards,

Marco Schmidt
Policy Development Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

Re: [address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates)

[Marco Schmidt]

Dear Hank,

On 2017-04-26 07:17:35 CET, Hank Nussbacher wrote:
> > why is this true only for legacy space?
> Further to this point: can RIPE NCC provide statistics for the past 3
> years of the number of IP resource hijacks that have taken place?
> 

Thank you for your question. We are happy to provide some information here. 

Firstly, it’s important to note that the following numbers mainly refer to 
resources that are under a contractual relationship with the RIPE NCC. 
The RIPE Database contains several thousand parent legacy ranges that are not 
covered by a contractual relationship. Whoever has access to the maintainer can 
update all details of the resource object. We would only notice hijacks of 
these resources if the resource holder reports the hijack or the hijacker asks 
us to update our internal records.
 
Since 2014, the RIPE NCC has concluded around 300 hijack cases for all types of 
resources, another 16 cases are still being investigated.

We reported on resource hijacking in our 2016 Annual Report. As we mentioned 
there, legacy resources remain susceptible to hijacks using fraudulently 
provided statements and several cases are under active investigation. You can 
find this on page 18 here (PDF): 
https://www.ripe.net/participate/meetings/gm/meetings/may-2017/supporting-documents/ripe-ncc-annual-report-2016.pdf

I hope this clarifies your question.

Kind regards,
Marco Schmidt
Policy Development Officer
RIPE NCC


Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates)

[Marco Schmidt]

Dear colleagues,

A new RIPE Policy proposal, 2017-01, "Publish statistics on Intra-RIR Legacy 
updates" is now available for discussion.

The goal of this proposal is to require the RIPE NCC to publish all changes to 
the holdership of legacy resources in the existing transfer statistics.

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2017-01

As per the RIPE Policy Development Process (PDP), the purpose of this four week 
Discussion Phase is to discuss the proposal and provide feedback to the 
proposer.

At the end of the Discussion Phase, the proposer, with the agreement of the WG 
Chairs, will decide how to proceed with the proposal.

We encourage you to review this proposal and send your comments to 
<address-policy-wg@ripe.net> before 24 May 2017.

Regards,

Marco Schmidt
Policy Development Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2015-04 Proposal Accepted (RIPE Resource Transfer Policies)

[Marco Schmidt]

Dear colleagues,

Consensus has been reached on 2015-04, "RIPE Resource Transfer Policies".

This policy change created a single policy document with all relevant 
information on the transfer of Internet number resources, replacing text in 
several RIPE Policies.
The policy change also introduces a 24-month holding period for IPv4 addresses 
and 16-bit ASNs after any change of holdership.

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2015-04

The new RIPE Document is ripe-682, "RIPE Resource Transfer Policies" and is 
available at:
https://www.ripe.net/publications/docs/ripe-682

The following RIPE policies haven been updated as well and received a new 
document number:
ripe-679, "Autonomous System (AS) Number Assignment Policies"
https://www.ripe.net/publications/docs/ripe-679
ripe-680, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC 
Service Region"
https://www.ripe.net/publications/docs/ripe-680
ripe-681, "IPv6 Address Allocation and Assignment Policy"
https://www.ripe.net/publications/docs/ripe-681

The following RIPE policy has been marked as obsolete and replaced by ripe-682:
ripe-644, "Policy for Inter-RIR Transfers of Internet Resources"

We estimate that this proposal will take around three months to fully implement.

In order to ensure a correct and consistent handling of requests, the current 
procedures remain in place until the implementation is completed. This applies 
in particular to transfers of IPv4 and 16-bit ASNs.

Details of the implementation status are available at:
https://www.ripe.net/manage-ips-and-asns/resource-management/policy-implementation-status

We will send another announcement once the implementation is complete and the 
new procedures are in place.

Thank you to everyone who provided input.

Kind regards,
Marco Schmidt
Policy Development Officer
RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2016-05 Last Call for Comments (Synchronising the Initial and Subsequent IPv6 Allocation Policies)

[Marco Schmidt]

Dear colleagues,

Proposal 2016-05, "Synchronising the Initial and Subsequent IPv6 Allocation 
Policies", is now in Concluding Phase.

The goal of this proposal is to match the subsequent IPv6 allocation 
requirements with the initial allocation requirements.

The WG Chair has declared that rough consensus has been reached and the 
proposal will now move to Last Call.

As per the RIPE Policy Development Process (PDP), the purpose of this four week 
Concluding Phase is to give an opportunity to present well-justified objections 
for those who missed the previous two phases and wish to oppose the proposal.

Any objection must be made by 28 March 2017 and must be supported by an 
explanation.

If no substantive objections are raised by the end of Last Call, the proposal 
will complete the PDP and will be evaluated by the WG Chairs for consensus.

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2016-05

Please e-mail any final comments about this proposal to 
<address-policy-wg@ripe.net> before 28 March 2017.

Regards,

Marco Schmidt
Policy Development Officer
RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2015-04 Last Call for Comments (RIPE Resource Transfer Policies)

[Marco Schmidt]

Dear colleagues,

Proposal 2015-04, "RIPE Resource Transfer Policies", is now in Concluding Phase.

The goal of this proposal is a single transfer policy with all relevant 
information on the transfer of Internet number resources, replacing text in 
several RIPE Policies. The proposal also introduces a 24-month holding period 
for IPv4 addresses and 16-bit ASNs after any change of holdership.

The WG Chair has declared that rough consensus has been reached and the 
proposal will now move to Last Call.

As per the RIPE Policy Development Process (PDP), the purpose of this four week 
Concluding Phase is to give an opportunity to present well-justified objections 
for those who missed the previous two phases and wish to oppose the proposal.

Any objection must be made by 9 March 2017 and must be supported by an 
explanation.

If no substantive objections are raised by the end of Last Call, the proposal 
will complete the PDP and will be evaluated by the WG Chairs for consensus.

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2015-04

Please e-mail any final comments about this proposal to 
<address-policy-wg@ripe.net> before 9 March 2017.

Regards,

Marco Schmidt
Policy Development Officer
RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2016-04 Review Phase: Draft Document and Impact Analysis Published (IPv6 PI Sub-assignment Clarification)

[Marco Schmidt]

Dear colleagues,

The draft document for the proposal described in 2016-04, "IPv6 PI 
Sub-assignment Clarification" has been published. 
The impact analysis that was conducted for this proposal has also been 
published.

The goal of this proposal is to define sub-assignments in IPv6 PI assignments 
as subnets of /64 and shorter.


You can find the full proposal and the impact analysis at:

https://www.ripe.net/participate/policies/proposals/2016-04

And the draft documents at:

https://www.ripe.net/participate/policies/proposals/2016-04/draft


We encourage you to review this proposal and send your comments to 
<address-policy-wg@ripe.net> before 31 January 2017.

Regards,

Marco Schmidt
Policy Development Officer
RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2016-03 Policy Proposal Withdrawn (Locking Down the Final /8 Policy)

[Marco Schmidt]

Dear colleagues,

The proposal 2016-03, "Locking Down the Final /8 Policy" has been withdrawn.

It is now archived and can be found at:

https://www.ripe.net/participate/policies/archived-policy-proposals/archive-policy-proposals/

Reason for withdrawal:

The proposer decided to abandon the proposal as he felt that the ongoing 
discussion was damaging the RIPE community’s reputation. As nobody stepped 
forward to take over the authorship this proposal, the proposal was withdrawn.

Regards

Marco Schmidt
Policy Development Officer
RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification)

[Marco Schmidt]

Dear colleagues,

A new RIPE Policy proposal 2016-04, "IPv6 PI Sub-assignment Clarification"
is now available for discussion.

The goal of this proposal is to define sub-assignments in IPv6 PI assignments 
as subnets of /64 and shorter.

You can find the full proposal at:

https://www.ripe.net/participate/policies/proposals/2016-04

We encourage you to review this proposal and send your comments to
<address-policy-wg@ripe.net> before 21 November 2016.

Regards,

Marco Schmidt
Policy Development Officer
RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies)

[Marco Schmidt]

Dear colleagues,

The draft documents for version 4.0 of the policy proposal 2015-04, "RIPE 
Resource Transfer Policies" have now been published, along with an impact 
analysis conducted by the RIPE NCC.

The goal of this proposal is to create a single document with all relevant 
information regarding the transfer of Internet number resources.

Some of the differences from version 3.0 include:

- Adding a reference in all related allocation and assignment policies to the 
new transfer policy document
- Clarification in the policy text and policy summary regarding transfers due 
to a change in the organisation’s business (such as a merger or acquisition)

You can find the full proposal and the impact analysis at:
https://www.ripe.net/participate/policies/proposals/2015-04

And the draft documents at:
https://www.ripe.net/participate/policies/proposals/2015-04/draft

We encourage you to read the draft document and send any comments to 
<address-policy-wg@ripe.net> before 26 October 2016.

Regards

Marco Schmidt
Policy Development Officer
RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

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

[Marco Schmidt]

Dear colleagues,

The draft minutes from the Address Policy Working Group sessions at RIPE 72 
have now been published:

https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-72


Please let us know of any corrections or amendments.

Kind regards,

Marco Schmidt
Policy Development Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

Re: [address-policy-wg] ipv6 assignments

[Marco Schmidt]

Dear Nick,

Thank you for raising this question. 

On 2016-06-22 15:37:17 CET, Nick Hilliard wrote:
> > 2.9. End Site
> >
> > An End Site is defined as an End User (subscriber) who has a business or 
> > legal relationship (same or associated entities) with a service provider 
> > that involves:
> >
> > -that service provider assigning address space to the End User
> > -that service provider providing transit service for the End User to 
> > other sites
> > -that service provider carrying the End User's traffic
> > -that service provider advertising an aggregate prefix route that 
> > contains the End User's assignment
> 
> Our reading of this is that each of these conditions is mandatory, i.e.
> logical AND, because logical OR does not make sense.  Term 2.9.2 states
> that an ipv6 End Site is only an End Site if the service provider is
> providing transit service for the End User to other sites.
> 

The RIPE NCC's current understanding is that the points in the list in section 
2.9 are seen as logical OR, with the first point "assigning address space" as 
the mandatory one. The other requirements are considered optional. For example, 
it seems reasonable for an LIR to provide address space to an End User, while 
the End User takes care themselves for routing and traffic management.

If all points were mandatory, it would be extremely difficult for service 
providers to make IPv6 assignments. For example, only End Users with multiple 
sites would be entitled to receive an IPv6 assignment. 
This seems to be against the spirit of the IPv6 policy, which aims to allow 
networks to access IPv6.

If the RIPE community disagrees with this understanding or feels that the 
current wording of section 2.9 is ambiguous, we invite a policy proposal that 
provides an adjusted End Site definition.

I hope this clarifies.

Kind regards,

Marco Schmidt
Policy Development Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)

[Marco Schmidt]

Dear colleagues,

The Discussion Period for the policy proposal 2016-03, "Locking Down the Final 
/8 Policy" has been extended until 15 July 2016.

The goal of this proposal is to ban transfers of allocations made under the 
final /8 policy.

The text of the proposal has been revised based on mailing list feedback and we 
have published a new version (2.0) today. 
As a result, a new Discussion Phase has started for the proposal.

Some of the differences from version 1.0 include:
- Several restrictions have been removed
- Adds a recommendation that LIRs should conserve whole or part of their final 
/22 allocation for interoperability purposes

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2016-03

We encourage you to review this policy proposal and send your comments to 
<address-policy-wg@ripe.net>.

Regards,

Marco Schmidt
Policy Development Officer
RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] Join the Address Policy WG Discussions Tomorrow

[Marco Schmidt]

Dear colleagues,

Tomorrow at RIPE 72, the Address Policy Working Group will be discussing 
the following policy proposals:


- 2015-04, "RIPE Resource Transfer Policies"
- 2015-05, "Revision of Last /8 Allocation Criteria"
- 2016-03, "Locking Down the Final /8 Policy"

While no decisions are made during this session, it’s a good opportunity 
to discuss the proposals and give feedback directly to the proposers.


If you can't attend tomorrow’s session in person, you can participate 
remotely. The following link will provide you with a live webstream and 
a chat client.


https://ripe72.ripe.net/live/main/

The session begins at 07:00 UTC on 25 May 2016.

We encourage you to join the discussion if you have an opinion about one 
of these proposals.


The second Address Policy Working Group session begins at 9:00 UTC on 
the same day and includes a presentation on "Market Concentration in the 
Transfer of IPv4 Space”, as well as feedback from the RIPE NCC's 
Registration Services Department. We invite you to tune in to see these 
presentations as well.


Kind regards,

Marco Schmidt
Policy Development Officer
RIPE NCC

[address-policy-wg] 2015-05 Discussion Period extended until 13 June 2016 (Last /8 Allocation Criteria Revision)

[Marco Schmidt]

Dear colleagues,

The Discussion Period for the proposal 2015-05, "Last /8 Allocation 
Criteria Revision"

has been extended until 13 June 2016.

You can find the full proposal at:

https://www.ripe.net/participate/policies/proposals/2015-05


We encourage you to review this policy proposal and send your comments
to <address-policy-wg@ripe.net>.

Regards,

Marco Schmidt
Policy Development Officer
RIPE NCC

[address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy)

[Marco Schmidt]

Dear colleagues,

A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy"
is now available for discussion.

The goal of this proposal is to limit IPv4 from the remaining address pool
to one /22 per LIR (regardless of how it was received).
These “final /22” allocations will receive a separate status with 
several restrictions:


-These allocation are not transferrable
-LIRs may only retain one final /22 following a merger or acquisition
-Sub-allocations are not possible
-Reverse delegation authority can not delegated to another party

You can find the full proposal at:

https://www.ripe.net/participate/policies/proposals/2016-03

We encourage you to review this proposal and send your comments to
<address-policy-wg@ripe.net> before 15 June 2016.

Regards

Marco Schmidt
Policy Development Officer
RIPE NCC

Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)

[Marco Schmidt]

Dear Remco and Radu-Adrian,

On 11/05/2016 23:21, Radu-Adrian FEURDEAN wrote:

(if any of the NCC staff wants to verify my numbers, feel free to do so)

Please !
Since it's not easy to find the following information:
  - if a LIR received or not it's "last /22" (cannot distinguish from one
  that get it and sold it)
  - if a LIR has performed an "outbound" transfer or not
Thanks.




Thank you for your questions. We have some numbers to help the discussion.

As of today, 8,831 of our 13,755 members have requested a final /22 IPv4 
allocation under the last /8 policy.


This means that there are currently 4,924 LIRs that may still request a 
/22 allocation. This figure includes LIRs that opened recently — if we 
look only at older members, there are currently 4,791 LIRs that have 
been open for more than six months and still haven’t requested their 
final IPv4 allocation.


We also note that the proposal introduces limits around transfers. 
Currently we count 723 LIRs that have transferred IPv4 resources to 
another entity and so would not qualify for future allocations under the 
proposal.


Regarding how long the available pool will last, we estimate a period of 
around five years under the current policy. In the next few days, we 
will publish a RIPE Labs article that will give more insight into what 
we’re basing this estimate on, such as membership development trends and 
returned IPv4 address space.


Kind regards,
Marco Schmidt
Policy Development Officer

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

[Marco Schmidt]

Dear colleagues,

The draft minutes from the Address Policy Working Group sessions at RIPE 
71 have now been published:


https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-71


Please let us know of any corrections or amendments.

Kind regards,

Marco Schmidt
Policy Development Officer
RIPE NCC

[address-policy-wg] New and Improved IPv4 Address Space Chart

[Marco Schmidt]

Dear colleagues,

During policy discussions, we often see people asking how long the RIPE NCC’s 
available IPv4 pool
will last. This is a good question, as more than three years after the last /8 
policy was
activated, we still have almost an entire /8 still remaining in our pool. This 
is made more
confusing by the regular allocations we have been receiving from IANA since 
2014, which have been
counteracting the reduction in addresses that we should have seen due to /22 
allocations.

To more accurately show the status of our remaining pool, we have updated our 
IPv4 Address Space
Chart, which you can find here:

   
https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph
  


The updated chart makes the distinction between addresses from the last /8, and 
addresses that
were received from IANA’s Recovered IPv4 Pool (as well as addresses recovered 
from our service
region). We have also published a short article on RIPE Labs with some 
additional detail about
our IPv4 pool:

   
https://labs.ripe.net/Members/marco_schmidt/taking-a-closer-look-at-the-last-slash-8


We hope this will help to inform the community’s policy discussions.

Kind regards

Marco Schmidt
Policy Development Officer
RIPE NCC

[address-policy-wg] 2015-04 Review Period extended until 22 March 2016 (RIPE Resource Transfer Policies)

[Marco Schmidt]

Dear colleagues,

The Review Period for the proposal 2015-04, "RIPE Resource Transfer 
Policies"

has been extended until 22 March 2016.

You can find the full proposal at:

https://www.ripe.net/participate/policies/proposals/2015-04

You can find a summary of the current proposal discussion at:

https://www.ripe.net/ripe/mail/archives/address-policy-wg/2016-March/010966.html


We encourage you to review this policy proposal and send your comments
to <address-policy-wg@ripe.net>.


Regards,

Marco Schmidt
Policy Development Officer
RIPE NCC

[address-policy-wg] 2015-04 New Draft Documents and Impact Analysis Published (RIPE Resource Transfer Policies)

[Marco Schmidt]

Dear colleagues,

The draft documents for version 3.0 of the policy proposal 2015-04, 
"RIPE Resource Transfer Policies"
have now been published, along with an impact analysis conducted by the 
RIPE NCC.


The goal of this proposal is to create a single document with all 
relevant information regarding

the transfer of Internet number resources.

Some of the differences from version 2.0 include:

- clarification in the policy text about entities that can receive a 
transfer
- further clarification in the policy text and policy summary regarding 
the 24-month holding period for scarce resources


You can find the full proposal and the impact analysis at:
https://www.ripe.net/participate/policies/proposals/2015-04

And the draft documents at:
https://www.ripe.net/participate/policies/proposals/2015-04/draft

We encourage you to read the draft document and send any comments to 
<address-policy-wg@ripe.net> before 3 March 2016.


Regards

Marco Schmidt
Policy Development Officer
RIPE NCC

[address-policy-wg] RIPE Policy Proposal 2016-01 Affects Legacy Internet Resource Holders

[Marco Schmidt]

Dear colleagues,

We just published RIPE Policy Proposal 2016-01, "Include Legacy Internet 
Resource Holders in the Abuse-c Policy", to the Anti-Abuse Working Group 
mailing list.


The goal of this proposal is to extend RIPE Document ripe-563, "Abuse 
Contact Management in the RIPE Database", to Legacy Internet Resource 
Holders.


As this proposal relates to the existing RIPE Policy, "RIPE NCC Services 
to Legacy Internet Resource Holders", we would like to notify the 
Address Policy Working Group specifically.


You can find the full proposal at:

https://www.ripe.net/participate/policies/proposals/2016-01

We encourage you to review this proposal and send your comments to 
<anti-abuse...@ripe.net> before 26 February 2016.



Regards,

Marco Schmidt
Policy Development Officer
RIPE NCC

[address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments)

[Marco Schmidt]

Dear colleagues,


The proposal 2014-03, "Remove Multihoming Requirement for AS Number 
Assignments" has been withdrawn.  

It is now archived and can be found at:


https://www.ripe.net/participate/policies/archived-policy-proposals/archive-policy-proposals/


Reason for withdrawal:

The proposers decided to withdraw the proposal due to the inability to find 
an acceptable solution which satisfied all parties.


Regards,

Marco Schmidt
Policy Development Officer
RIPE NCC