Re: [address-policy-wg] .cz says bye-bye to IPv4

[Nick Hilliard]

Hank Nussbacher wrote on 24/01/2024 12:48:
https://konecipv4.cz/en/?is=e583f1196868df2304ff1140184b103346ee70b72851338b99ab8ec03065ae3b 


Whatever about the intention, I would question the wisdom of this move. 
The purpose of the internet is to serve its users, not the other way around.


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

Re: [address-policy-wg] Address Policy WG Co-Chair - James Kennedy Steps Down

[Nick Hilliard]

Erik Bais wrote on 28/11/2023 15:23:

I write to you on the ML, to ask you for your support and feedback on the 
approach.


sounds like a good candidate - thanks to Alex for volunteering!

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

Re: [address-policy-wg] 2023-04 Are anonymised assignment objects valid?

[Nick Hilliard]

Brian Storey wrote on 30/09/2023 00:03:

For me it comes down to this. As a community & considering the permitted
exceptions (individuals & P2P assignments):-

1) Is the publication of End User entities for an assignment important?
2) Is the publication of a prefix assignment boundary between end users
important?


Brian,

thanks for this thoughtful analysis of this proposal. These two 
questions are indeed the crux of this issue.


I'm also surprised at Angela's answers, but let's deal with the intent 
of the policy for the time being, namely whether the RIPEDB should or 
shouldn't include information about end user assignments and the 
entities to which they are assigned.


My take is that, in theory, there would be a good deal of merit in 
publishing both if there were some way of ensuring that this data was 
accurate and well-maintained. However, from a practical point of view, 
there's a large amount of inaccurate and stale data in the RIPE 
database. A lot of effort has been expended over the last 30 years to 
attempt to address this problem, but no good solutions have been found 
and the outcome


If we haven't solved this problem in 30 years, and if there are no 
proposals on the table to address data quality issue, I'd speculate that 
it's unlikely we'll solve the RIPE DB's data quality issues any time 
soon, and maybe now it would be appropriate to have a good, hard think 
about whether it's worth keeping this policy at all.


But, speculation is not an appropriate substitute for fact. A better 
starting point for addressing the underlying data quality issue might be 
to formally measure it. There's ~4.7m inetnum/inet6num PA assignment 
registrations in the database. A quick check with a sample size 
calculator suggests that examining around 500 random inetnums / 
inet6nums for an a/b data quality outcome would give a result with 98% 
confidence, ~5% error margin.


Is there an appetite for examining this in the DB-WG + the RIPE NCC?

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

Re: [address-policy-wg] 2023-04 Are anonymised assignment objects valid?

[Nick Hilliard]

denis walker wrote on 28/09/2023 11:31:

We are talking about one sentence in the current address policy that
this proposal removes.


that's ok: the RIPE Community is entitled to voice an opinion on 
changing RIPE policy.


If this policy nullifies the requirement to register end-user PA 
assignments in the RIPE DB, I don't necessarily view this as a bad 
thing, given the poor quality of the existing data, and the fact that 
fixing this is - whether we accept this or not - a largely intractable 
problem.


That said, it's important that any change of this scope should be done 
with the community's eyes open so that we can make an informed decision 
based on merit.


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

Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

[Nick Hilliard]

denis walker wrote on 24/09/2023 17:12:

So are you saying
that in 2023 we can't manage a distributed database without
overwhelming repetitive tasks?


yes, correct. People are stuck using the tools that they have. Most 
off-the-shelf tools don't implement server-client or 2way database 
synchronisation between the local ipam system and the ripe db, and 
there's ~zero financial inventive to build this sort of functionality 
in-house. The outcome is that the ripedb ends up with manual updates, or 
else with low quality / 1-way synchronisation with little or no cleanup.


The result of this is that the ASSIGNED-PA objects in the ripedb are 
generally of low average accuracy.


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

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

[Nick Hilliard]

Hi Angela,

thanks for your reply - this addresses all the remaining concerns I had 
about the proposal.


Nick

Angela Dall'Ara wrote on 05/07/2023 15:52:

Dear Nick,

The requirement in the current policy (ripe-733) [1] that /“After one 
year the utilisation of the new assignment must be at least 50%, 
unless special circumstances are defined"/ is implemented the way 
Marco previously explained: the 50% utilisation refers to an estimated 
projection, which must be supported by the documentation provided by 
the IXP when requesting an assignment larger than the minimum size.


This requirement was first introduced in the ripe-604 [2] policy 
document, after the approval of proposal 2013-03 [3], to maintain the 
need evaluation for IXP assignments. The RIPE NCC Impact Analysis [4] 
on proposal 2013-03 was: /“It is the RIPE NCC’s understanding that 
Internet Exchange Point assignments larger than /24 would be based on 
documented calculations that allow the utilisation to be estimated one 
year after the date of assignment. This utilisation should be at least 
50% of the assignment. “/


The requirements for returning the unused space to the IXP pool are 
described in paragraph 6.1.5 of the current policy: /“IXPs holding 
other PI IPv4 space for their peering LAN (i.e. they are seeking a 
larger assignment), and any IPv4 space assigned from this pool that is 
no longer in use, must be returned to the pool within 180 days of 
disuse or a new assignment.“/


I hope this helps.

Kind regards,
Angela Dall’Ara
Policy Officer
RIPE NCC

[1] https://www.ripe.net/publications/docs/ripe-733
[2] https://www.ripe.net/publications/docs/ripe-604
[3] https://www.ripe.net/participate/policies/proposals/2013-03
[4] 
https://www.ripe.net/participate/policies/proposals/2013-03#impact-analysis

On 04/07/2023 20:33, Matthias Wichtlhuber wrote:

Hi Nick,

Marco or Angela from RIPE should be able to answer this question. I have no 
insights into this beyond what was communicated by RIPE on this list.

Regards,
Matthias

--
Dr.-Ing. Matthias Wichtlhuber
Team Lead Research and Development
--
DE-CIX Management GmbH
Lindleystr. 12, 60314 Frankfurt (Germany)
phone: +49 69 1730902 141
mobile: +49 171 3836036
fax: +49 69 4056 2716
e-mail:matthias.wichtlhu...@de-cix.net
web:www.de-cix.net
--
DE-CIX Management GmbH
Executive Directors: Ivaylo Ivanov and Sebastian Seifert
Trade registry: District court (Amtsgericht) Cologne, HRB 51135
Registered office: Lichtstr. 43i, 50825 Cologne


Von: Nick Hilliard
Gesendet: Dienstag, 4. Juli 2023 20:18:55
An: Matthias Wichtlhuber
Cc: RIPE Address Policy Working Group
Betreff: Re: AW: [address-policy-wg] 2023-01 Review Phase (Reducing IXP IPv4 
assignment default size to a /26)

Matthias Wichtlhuber wrote on 30/06/2023 10:58:

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.

Thus, this issue is not urgent and can be discussed separately. I hope that 
answers open questions.

Hi Matthias

Let me ask the question in a different way.  The policy says:


After one year, utilisation of the new assignment must be at least 50%, unless 
special circumstances are defined.

If the IXP is using less than 50% after one year, what happens?  Will
the assignment be deassigned?

If the answer is "yes, the assignment will be deassigned", does the RIPE
NCC apply some form of threshold to determine whether or not to
deassign?  I.e. if the assignment less than exactly 50%, or is there a
practical slop factor in there?

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

Re: [address-policy-wg] 2023-02 Last Call for Comments (Minimum Size for IPv4 Temporary Assignments)

[Nick Hilliard]

The proposal looks ok to me.

Nick

Erik Bais wrote on 12/07/2023 09:26:


Dear AP-WG members,

Please be aware that the Last Call for Comments of the min. size for 
IPv4 temp assignments is about to end ..  ( June 13 2023 – aka tomorrow )


As chairs we would like to receive a bit more comments / support 
during last call, as it has been silent ..


To reach consensus, we are not only looking for objections .. but also 
for support of the community and this is a request to speak up.


So even if you voiced support in previous phases, let us know again in 
the Last Call phase as well.


Have a nice day,

Erik Bais

On behalf of the AP-WG Chairs, co-Chair

*From: *address-policy-wg  on 
behalf of Karen Hung 

*Date: *Wednesday, 14 June 2023 at 10:07
*To: *"address-policy-wg@ripe.net" 
*Subject: *[address-policy-wg] 2023-02 Last Call for Comments (Minimum 
Size for IPv4 Temporary Assignments)


Dear colleagues,

Proposal 2023-02, "Minimum Size for IPv4 Temporary Assignments" is now 
in Concluding Phase.


This policy proposal recommends setting the minimum assignment size to 
a /24 while still allowing for a smaller assignment if requested by 
the End User. This policy proposal also allows routing requirements to 
justify the request for more than a /24 for research purposes.


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 13 July 2023 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/2023-02

Please e-mail any final comments about this proposal to 
mailto:address-policy-wg@ripe.net>> 
before 13 July 2023.



Kind regards,
Karen Hung
On behalf of 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

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

[Nick Hilliard]

Matthias Wichtlhuber wrote on 30/06/2023 10:58:

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.


Thus, this issue is not urgent and can be discussed separately. I hope that 
answers open questions.


Hi Matthias

Let me ask the question in a different way.  The policy says:


After one year, utilisation of the new assignment must be at least 50%, unless 
special circumstances are defined.


If the IXP is using less than 50% after one year, what happens?  Will 
the assignment be deassigned?


If the answer is "yes, the assignment will be deassigned", does the RIPE 
NCC apply some form of threshold to determine whether or not to 
deassign?  I.e. if the assignment less than exactly 50%, or is there a 
practical slop factor in there?


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

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

[Nick Hilliard]

Angela Dall'Ara wrote on 29/06/2023 15:19:
It is therefore important to provide your opinion, even if it is 
simply a restatement of your input from the previous phase.


this version of the document hasn't addressed the problems I raised on 
April 26. The authors need to give some consideration about what might 
be the best approach to fixing them:


1. problematic edge cases in section 5 due to the magic figure of 50% 
utilisation

2. what is a "special circumstance"?

I don't believe that the document should progress until these issues are 
addressed.


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

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

[Nick Hilliard]

Gert Doering wrote on 12/06/2023 11:34:

How would you translate this into "generic 32bit AS number usability"?


this wasn't a comment about IXPs: many smaller organisations have 
mikrotiks running with bgp on service provider networks, but are unable 
to run BGP LC because of lack of support.


If you run a Mikrotik at an IXP, there are a number of important caveats 
to be aware of, BGP LC being one.


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

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

[Nick Hilliard]

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

--

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

[Nick Hilliard]

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

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

[Nick Hilliard]

Angela Dall'Ara wrote on 06/03/2023 10:43:
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.


two issues:

- I can't work out what the proposed new section 7 is saying.
- there are a bunch of problematic edge cases associated with section 5. 
E.g. what happens if an IXP has a /23 and has 254 IP addresses used 
after 1Y? They will be obliged to downgrade to a /24, according to the 
current text.  Also I don't know what a special circumstance is.


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.


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

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

[Nick Hilliard]

Gert Doering wrote on 09/02/2023 08:28:

OTOH, without this clause, IXPs will notice "there is no more IPv4 space,
so maybe we need to do something else", and then it will be a bit late
to start researching - so maybe this is something people from the IXP
community (EuroIX?) can start working on, *together with the usual
vendors*, to make sure this stuff actually works when the IXPs need it,
and there is good documentation for the IXP members "how to make it
work on their gear"...


No doubt at some point in the future, this will work reasonably well. 
In the interim, it will be fertile territory for difficult-to-diagnose 
forwarding bugs, i.e. the class of bugs that gives the night terrors to 
both device software/firmware developers and network operators.


We're no longer in a world where it's viable to deploy untested and 
experimental L3 packet forwarding features in IXPs.  NISD2 is just 
around the corner, which will categorise all IXPs in the EU region as 
Essential Entities - the equivalent of Operators of Essential Services 
in NISD1.  I.e. IXPs will shortly be regulated entities.


If enabling rfc8950 caused an IXP to blackhole traffic for a couple of 
million people, how would it work explaining it to a regulator that the 
root cause for this outage was an experimental baseline forwarding 
feature, mandated by an addressing policy and enforced by the RIPE NCC?


RFC8950 will have its place in the toolbox, but we're not there yet.

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

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

[Nick Hilliard]

Matthias Wichtlhuber wrote on 08/02/2023 13:36:

This part of the proposal is intended to foster the adoption of the technology.
IXPs may offer it as beta or experimental while still doing the actual exchange
of traffic via standard BGP over IPv4.


Hi Matthias,

this is premature: if the protocol didn't work well in production 
environments, that would raise questions about the wisdom of mandating 
the protocol in the first place.


In any event, as Randy pointed out, it's generally not a good idea to 
use policy in one area to try to force specific technology choices in 
another.


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

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

[Nick Hilliard]

Angela Dall'Ara wrote on 09/01/2023 10:40:
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.


not sure if this comment is in time, but the text contains:


Assignments strictly larger than a /24 will only be made to IXPs that
offer the exchange of IPv4 routing information over IPv6 at their
route servers


As far as I understand, this protocol is not widely deployed in IXPs, 
nor is it widely tested in inter-AS production environments. It would be 
concerning if an untested protocol were mandated as a production 
requirement in a RIR addressing policy document.


Before continuing down this path, could the authors provide information 
on how this protocol works in production environments?


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

Re: [address-policy-wg] IXP pool lower boundary of assignments

[Nick Hilliard]

Tore Anderson wrote on 08/11/2022 14:18:

Apart from the BGP session itself (which supports multi-AF), the
addresses are just needed for resolution of the next-hop layer-2
address. There's no real reason that address needs to be IPv4 and
resolved via ARP, it can be resolved just as well with IPv6 ND, as I
understand it.

For example, on Linux, you can program the FIB in this way:

$ ip route add 192.0.2.0/24 via inet6 fe80::1 dev eth0

The 'eth0' interface does not need any IPv4 addresses assigned.


Right, ipv4 forwarding using ipv6 next hop resolution.  Wow, that's ugly 
and likely to introduce an entirely new class of low-level forwarding bugs.



Obviously the major router vendors need to build in corresponding
capability in their BGP software for IPv6-only IX-es to be a realistic
proposition. I have no idea if they have.


In fairness, this goes well beyond updating a set of capabilities in 
vendor BGP stacks.


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

Re: [address-policy-wg] IXP pool lower boundary of assignments

[Nick Hilliard]

Will Hargrave wrote on 08/11/2022 13:48:

If we think router vendors are in a position to reliably support v4
AF over BGP in v6, and actually route this traffic
this is kinda the problem with RFC 5549, no?  I.e. it deals only with 
signaling rather than transport. So even if it's deployed, the IXP will 
still need to provide ipv4 addresses for transport purposes.


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

Re: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database)

[Nick Hilliard]

denis walker wrote on 10/10/2022 21:33:

The bottom line is that we cannot make assignments optional unless we
either disregard rfc7020 or we propose to the IETF an update to
rfc7020 by removing a large proportion of the current registration
data from the goals and core requirements. In


Denis,

rfc7020 is an informational rfc, not BCP or Standards Track. I.e. it is 
intended to be descriptive rather than prescriptive.  If the RIPE 
Community wants to change how assignments are documented, it can do 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

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

[Nick Hilliard]

Marco Schmidt wrote on 11/10/2022 11:49:
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?


seems reasonable.

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

Re: [address-policy-wg] IPv6 - Using RIPE acquired prefix in other regions

[Nick Hilliard]

How and where you choose to announce subnets of a legitimately 
registered address block on the internet is up to you.


There is no such thing as "ARIN regulatory domain".  RIRs are 
registration bodies, not regulatory bodies.


Nick

Michalak, Damian wrote on 27/01/2022 14:02:
Question: can I advertise the /48 subnet (that falls into the /32 
assigned by RIPE) from the location that in theory falls into ARIN 
regulatory domain?




--

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

[Nick Hilliard]

Mathias Westerlund wrote on 12/12/2021 07:50:

I realize it is not an easy thing to solve.
I also both feel and understand that something needs to be done due to 
the situation at hand.


this situation can't be solved: it can only be managed.  There's a 
unresolvable high demand for number resources, and an unresolvable 
shortage of supply.


The challenge is to work out what categories of problems we can live 
with, and then devise policies to implement that.  This is how the 
current policies came into existence.


In regard to creating new policies or updating current ones:

- the ultimate aim is accurate registration of resources

- there is reluctance on the part of RIRs to deregister previously 
allocated number resources except in cases of contractual default


- due to the high perceived value of ipv4 address resources, reclaiming 
addresses due to contractual default is likely to slow down in future


- the greater the difference between supply and demand, the higher the 
price on the open market, and the more this will hurt organisations who 
need ip addresses, and the more demand there will be to change the rules 
to something else.


- "new entrant" companies can be created simply and quickly (i.e. 
prioritising "new entrants" will create more avenues to abuse the 
registration system).


- increasing the price of registration of addresses solves some problems 
but creates others


- the RIR cannot make a value judgement about whose legitimate need for 
IP addresses is more important


- some people will try hard to cheat the system, and some will succeed

- whatever policy is implemented, it needs to be applied fairly and 
rigorously


- the policies and implementations need to be compliant with local and 
regional laws / regulations


The intersection of these constraints rules out many options for 
creating new policies.


Nick


The problem is that many of the solutions i would think of may include 
administration overhead, but i guess i will put forward two maybe three 
ideas.


The first and easiest but that will not satisfy everyone is the most 
obvious one.
Only allow new members to procure from the waiting list and make the 
addresses nontransferable.


This would in my opinion be a stop gap for a bigger solution because we 
cannot go ahead and block legitimate business needs for larger entities 
just because of newcomers like myself.
However that ties into my second more realistic approach of what might 
be accepted but also requires some changes on the administration.


How about simply having a split queue system?
New members with single LIR goes to the front of the line and gets an 
nontransferable address.
Others will according to their number of existing LIRs or ranges go to 
the back of the line according to their current ownership where an 
legitimate need for more ranges constitutes an expected revenue across 
said ranges and as such the bigger expectancy of acquiring larger ranges 
via an market otherwise said ranges are not being utilized properly (i 
understand the existence of non profits and edge cases but not everyone 
can be 100% satisfied, neither can i with this in the future)
Make an buffer that is not possible to be allocated to multi LIRs/multi 
range holders.
I am not an old member enough to have good insight to where a good 
buffer would be but for arguments sake i would say 100.


This means that there is supposed to be 100 /24 ranges available (Could 
be 20 or 30 or anything RIPE agrees on) and as long as there is, the 
"Multi holder Queue" would be able to request ranges against 
motivational uses.


There could even be a third queue at say 250 ranges available where all 
the ranges above that goes to open market against the requirement that 
they become used within x time and if they are to be resold they have to 
be resold/rented out at fair pricing. This could be 25,50 or whatever, i 
don't have the insight yet on how often ranges are allocated to give an 
accurate number and will not pretend as such either.


This would guarantee that the original spirit of the /24's for newcomers 
idea is retained, while adopting to the wishes of the larger members as 
well to a degree, I fully understand that there are some really really 
big entities out there with big needs for IPv4 still and i don't want to 
block them in any way shape or form because i one day hope to be able to 
make use of our ranges and services to become on of the really big 
players, with the benefit of being such a new player that i can already 
today build IPv6 native and just use IPv4 for the still required things 
and then hopefully phase out IPv4 and return our ranges down the road.


We today have as i mentioned earlier an single IPv4 /24 available for 
our older WISP/MSP datacenter, It was acquired from an entity called 
Resilans (If mentioning other entities by name is not allowed i 
apologize) they also helped us with the process of becoming an LIR and 
ripe member so we are VERY 

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

[Nick Hilliard]

Gert Doering wrote on 09/12/2021 07:56:

So, if you were to decide, what would you do?


the ipv4 address market is now the largest global supplier of ipv4 
addresses. To put some figures on it, 11433920 addresses were 
transferred via the ripe ncc in 2021 so far 
(ripencc-transfers_latest.json), and 9696896 in 2020.


alloclist.txt shows 2981 /24 allocations so far in 2021, i.e. 763136 
addresses, and 1166 /24 allocations in 2020, i.e. 298496 addresses


I.e. the RIPE NCC allocated only 6.25% of the total address space which 
changed hands in the ripe region in 2021, and ~3% in 2020.


In a market situation like this, there are two ways of making an impact: 
1. by being a large enough market player that decisions you make will 
make a significant difference to the ecosystem and 2. by changing the 
rules - which RIPE / the RIPE NCC has some ability to do.


The RIPE NCC has historically been reluctant to interfere with past 
assignments, and it's unlikely that this will change. It doesn't have 
the market power to change the market substantially, and any rule change 
it makes will only affect new allocations.


In other words, a policy change from APWG, if implemented by the RIPE 
NCC, would only potentially affect a tiny percentage of address 
holdership changes, and would be unlikely to make much of a difference 
in the overall scheme of things.


In addition to this, Marco's email mentioned:


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


Allocations to members with a single LIR account are unlikely to be 
wholesale abusers.  Some of the LIRs with multiple accounts and /24s 
look like genuine ip address users (e.g. telcos / vpn hosting outfits / 
etc).


But a number of them look unusual, e.g. where the first entry on a web 
search for their company name is their RIPE LIR ID.



So, if you were to decide, what would you do?


So, that.  If I were supreme ruler of the universe, I'd get more 
information about these peculiar-looking allocations, then make a 
decision about whether it was worth either changing policy or 
operational practice to block or restrict allocations of this form, then 
model some potential options in terms of risk / outcome, and then after 
thinking about it for a while, I might make a decision to change policy, 
or executive practice, or not, depending on the overall likely outcome. 
Right now we don't have enough data to work with.


Also, unless a fix actually fixes something, it's just busywork.

Sander was right though: we're talking about rearranging the deck chairs 
on the Titanic, and any discussion needs to be framed in this context.


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

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

[Nick Hilliard]

denis walker wrote on 08/12/2021 19:35:

Since it's formation the RIPE NCC has been in the address rental
market. This is what it always has and continues to do.


The LIR fee is an association membership fee, and the RIPE NCC has taken 
pains over the years to emphasise that the membership fee is not linked 
directly to address allocation quantities, because that could be 
construed to be a quid-pro-quo services arrangement.


Prohibiting transfers will cause the RIPE NCC to move towards a model of 
intrinsically linking the registration fee to a specific quantity of 
resources.  This is because there is a fixed annual fee, and the 
quantity of address space is fixed if the end user acquires holdership 
of more than one of these /24s. I.e. if an end user has one of these 
/24s, they can rationalise costs by moving any existing ip address 
allocations into the /24 LIR, but if they have two or more of these 
/24s, then there is no cost advantage to doing this.


If the effective rental fee is higher than market rates, then there's no 
value to startup end users.  If it's lower, then the RIPE NCC is 
competing with existing market operators and potentially distorting the 
market, but with an effective competitive advantage in terms of having a 
monopoly on being able to reclaim unused ip address space from former 
LIRs.  This would be an awkward position for the RIPE NCC to put itself 
into.


I sympathise with what you're trying to achieve here: you want to design 
a policy mechanism which prioritises new entrants who need IPv4 
resources so that legitimate new businesses can operate successfullt. 
Problem is, none of the mechanisms that have been proposed so far on 
apwg are going to work, or else they are likely to have unexpected and 
potentially serious downstream consequences.


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

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

[Nick Hilliard]

denis walker wrote on 08/12/2021 17:43:

I would suggest that the free pool of IPv4 that the RIPE NCC has from
time to time should only be used to allow new startups to enter the
business. Transfers on these new startup blocks should not be allowed,
ever.


What your suggestion does is acknowledge that ipv4 address space has 
asset value.  Financial value of an asset is measured either in terms of 
capital value (probably non-depreciable in the case of ipv4), or as an 
operational cost.


If there's no ability to transfer the objects out of the holding 
company, then a block of ipv4 addresses changes from a non-depreciable 
fixture to an operational cost for using an asset for as long as the 
fees are paid, i.e. a rental arrangement.  Selling the holding company 
is straightforward.


In other words, what you're effectively proposing is that the RIPE NCC 
enters the ipv4 address rental market, and competes with existing market 
operators, with no real protection against address transfers.


This may not be what you or other people intend to suggest, or want, but 
it is the practical outcome.


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

Re: [address-policy-wg] stockpiling IPv6

[Nick Hilliard]

JORDI PALET MARTINEZ via address-policy-wg wrote on 28/10/2020 12:05:

However, in RIPE NCC, if you created several LIRs for getting more
IPv4 allocations, *even if you don't use/need it* you can get (and
thus stockpile) IPv6 *at no extra cost*.

[...]

Do we need some text about "recovery if not announced and used" ?


tl;dr: no.

Nick

Re: [address-policy-wg] FW: Policy Reciprocity

[Nick Hilliard]

Jim Reid wrote on 21/10/2020 09:32:

Fair enough Shane. [Though I don’t agree legacy space is/was a
mistake.] However nobody can rewind history. So until someone invents
time travel, we just have to live with what you think was a mistake.
more to the point, the legacy policy resources document says that if 
RIPE community policy is created or updated, it only applies to legacy 
address space if the policy says so explicitly.


The consequence of this is that legacy address holders can easily veto 
any future changes to legacy address policy that they don't like.


Some people think this is a great idea; other don't and feel this was a 
mistake.  Either way it's irrelevant because it's not really possible to 
back out of this sort of policy arrangement.


The most sensible approach in the circumstances is leave it and move on.

Nick

Re: [address-policy-wg] 2019-06 Extended Review Period has ended (Multiple Editorial Changes in IPv6 Policy)

[Nick Hilliard]

Erik Bais wrote on 10/02/2020 14:14:
And if you do agree with the policy moving forward, please let it know 
in the Last Call phase as well, as it is easier for us as Chairs to call 
consensus or not, if we have some response.


I support this going forward.

Nick

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

[Nick Hilliard]

Gert Doering wrote on 08/01/2020 12:34:

This proposal got support in discussion phase, but no comments whatsoever
in review phase.  Based on this, we cannot advance it, even if chairs
and proposer think it is reasonable and had support beforehand...


Looks fine - I support this.

Nick

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

[Nick Hilliard]

Radu-Adrian FEURDEAN wrote on 14/11/2019 17:46:

On Thu, Nov 14, 2019, at 14:56, Nick Hilliard wrote:

As you're speaking in favour of the proposal, can you describe
what problem you want to see fixed here?


Problem : adapt the default assignment to the needs of most, in order
to prolong pool's life, while allowing those that need to grow to do
so while minimising re-numbering at maximum.


It looks like the pool is probably large enough to last indefinitely 
under the current assignment policy.  It's not clear what changing the 
assignment policy is going to fix.


Nick

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

[Nick Hilliard]

Radu-Adrian FEURDEAN wrote on 13/11/2019 13:41:

A little late, but here's my point of view:
- /27 is borderline for a default. Hopefully the 50% use within 2
years should alleviate this (even if I find it not enough).
- Anything smaller than a /27 is close to useless. - Renumbering is
painful and should be avoided as much as possible.
- IXP growth may be very variable in time. You may struggle for1-2
years, then add several dozens members the next year. You may easy
get in a situation when renumbering falls in a period of rapid
growth, which only makes things worse.

The purpose of a policy should be to fix a specific problem.

As you're speaking in favour of the proposal, can you describe what 
problem you want to see fixed here?


Nick

Re: [address-policy-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space) to be discussed on Routing Working Group Mailing List

[Nick Hilliard]

JORDI PALET MARTINEZ via address-policy-wg wrote on 01/11/2019 10:52:

I guess I don't have sufficient time to see enough films of TV shows ...


https://www.youtube.com/watch?v=FAxkcPoLYcQ

It's a metaphor about how we start off with incremental additions that 
seem innocent, but they end up with an appalling outcome.


See also: "boiling the frog" and "creeping featuritis".

Nick

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

[Nick Hilliard]

Marco Schmidt wrote on 15/10/2019 13:43:

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


This proposal doesn't seem well-thought-out.

The first, and main, issue is that renumbering IXPs is a terrible 
headache and is something that should be avoided if possible.


The sorts of problems that regularly erupt would include:

- loss of service during renumbering, with traffic being forced over 
backup paths at times that may not suit


- ixp participants being forced to undergo network changes outside their 
normal maintenance window procedures (some networks cannot do this).


- problems with IXP prefix misorigination due to filters not being 
updated properly, which can cause loss of service problems.


- other larger-scale configuration issues due to people making 
substantial config changes to their peering routers, which usually takes 
some time to iron out the bugs.  I.e. this is not as simple as a global 
search + replace.


INEX was a good internet citizen and started out with a /27 on our main 
peering LAN in 1996.  When that ran out, we moved to a /26 and then a 
/25.  We're now at /23.  For each renumbering operation, we ran into the 
problems above, and a lot more.  So from multiple experience, I wouldn't 
wish it on anyone to have to go through an IXP renumbering without good 
reason.  It really is a thorough pain, especially for the IXP participants.


The second issue is that there are ~220 IXPs operating in the countries 
in the ripe ncc region.  This number is pulled from IXPDB 
(https://api.ixpdb.net/v1/provider/list), and cross-referenced against 
the list of RIPE NCC countries here:


https://www.ripe.net/participate/member-support/list-of-members/list-of-country-codes-and-rirs

A /15 has enough space for 512x/24 blocks, which means that this block 
will probably last indefinitely if the minimum assignment size is /24.


By reducing this to /27, all that's going to happen is that IXPs and 
their participants will be dragged through unnecessary renumbering 
procedures; but it is unlikely to make the block last longer.


I'd like to respectfully suggest that the proposal be dropped.

Nick

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

[Nick Hilliard]

Sander Steffann wrote on 08/10/2019 15:01:

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.


I think this is a sensible update. Support.


agreed - this looks like a good idea, and thanks to Jordi for doing some 
housekeeping in this area.


Nick

Re: [address-policy-wg] New on RIPE Labs: So Long Last /8 and Thanks For All the Allocations

[Nick Hilliard]

Aled Morris via address-policy-wg wrote on 28/08/2019 11:25:
One thing that occurs to me is that all of this could represent a 
significant slow down of funds into RIPE.  I hope they are taking this 
into account in their financial planning, these "opportunist" LIRs bring 
in a lot in membership fees.


yes, this has been modelled from a financial planning point of view.

Nick

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

[Nick Hilliard]

I agree with Wolfgang - the current version is fine, and Gert - that it 
is important to move on this because otherwise we'll lose the 
opportunity forever, and that would be a shame because IXPs perform an 
important function for the Internet as a whole.


Nick


Wolfgang Tremmel 
9 August 2019 at 16:17
...and because of that I am happy with version 2.0 of 2019-05 as it is 
written.


Wolfgang



Gert Doering 
9 August 2019 at 15:41
Hi,

I hope you are all aware that you are asking for something which *was*
in version 1.0 of this proposal, and which was *not* receiving positive
feedback in the discussion phase.

Also, you are certainly all aware that if we do another version of this
proposal with changes and a new impact analysis, we'll have run out of
IPv4 before this can be implemented (thus: no extra address space for
IXPs).

Just sayin.

Gert Doering
-- AWPG chair
Jetten Raymond 
9 August 2019 at 15:26

Support for /25  +1

Cheers,

Ray

*From:*address-policy-wg  *On 
Behalf Of *Dominik Nowacki

*Sent:* 9. elokuuta 2019 15:13
*To:* Fredy Kuenzler 
*Cc:* address-policy-wg@ripe.net
*Subject:* Re: [address-policy-wg] 2019-05 New Policy Proposal 
(Revised IPv4 assignment policy for IXPs)


Same here, +1 for /25 - /26 is too small, You don’t want IX to have to 
Re-number


With Kind Regards,

Dominik Nowacki

Clouvider Limited is a limited company registered in England and 
Wales. Registered number: 08750969 . Registered office: 
88 Wood Street, London, United Kingdom, EC2V 7RS. Please note that 
Clouvider Limited may monitor email traffic data and also the content 
of email for the purposes of security and staff training. This message 
contains confidential information and is intended only for the 
intended recipient. If you do not believe you are the intended 
recipient you should not disseminate, distribute or copy this e-mail. 
Please notify ab...@clouvider.net  of this 
e-mail immediately by e-mail if you have received this e-mail by 
mistake and delete this e-mail from your system. E-mail transmission 
cannot be guaranteed to be secure or error-free as information could 
be intercepted, corrupted, lost, destroyed, arrive late or incomplete, 
or contain viruses. Clouvider Limited nor any of its employees 
therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of e-mail 
transmission. If verification is required please request a hard-copy 
version.



On 9 Aug 2019, at 13:09, Fredy Kuenzler > wrote:


Dominik Nowacki 
9 August 2019 at 15:13
Same here, +1 for /25 - /26 is too small, You don’t want IX to have to 
Re-number


With Kind Regards,
Dominik Nowacki

Clouvider Limited is a limited company registered in England and 
Wales. Registered number: _08750969_ . Registered 
office: _88 Wood Street, London, United Kingdom, EC2V 7RS_. Please 
note that Clouvider Limited may monitor email traffic data and also 
the content of email for the purposes of security and staff training. 
This message contains confidential information and is intended only 
for the intended recipient. If you do not believe you are the intended 
recipient you should not disseminate, distribute or copy this e-mail. 
Please notify _abuse@clouvider.net_  of 
this e-mail immediately by e-mail if you have received this e-mail by 
mistake and delete this e-mail from your system. E-mail transmission 
cannot be guaranteed to be secure or error-free as information could 
be intercepted, corrupted, lost, destroyed, arrive late or incomplete, 
or contain viruses. Clouvider Limited nor any of its employees 
therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of e-mail 
transmission. If verification is required please request a hard-copy 
version.


On 9 Aug 2019, at 13:09, Fredy Kuenzler > wrote:


Fredy Kuenzler 
9 August 2019 at 15:08
+1 for the /25.

--
Fredy Kuenzler
Init7 (Switzerland) Ltd.
Technoparkstrasse 5
CH-8406 Winterthur
Switzerland

http://www.init7.net/

Re: [address-policy-wg] question about IPv4 legacy and transfers - should we convert legacy to non-legacy with transfers?

[Nick Hilliard]

Carlos Friaças wrote on 24/07/2019 08:28:
However... how far is that (the geographic association bit) from 
operational reality...?


It means that if you breach the policy, then it's a policy violation, 
and the RIR policy violation procedures apply.


Nick

Re: [address-policy-wg] question about IPv4 legacy and transfers - should we convert legacy to non-legacy with transfers?

[Nick Hilliard]

Carlos Friaças wrote on 23/07/2019 22:03:

"e.g. geographic association"

-- really...??


Yep, really.

https://www.nro.net/wp-content/uploads/comp-pol-2018v2.pdf

see Section 1.3.4 - Out of region Use.

+ also: https://afrinic.net/policy/manual


5.4.6.2 AFRINIC resources are for AFRINIC service region and any use
outside the region should be solely in support of connectivity back
to the AFRINIC region.

Nick

Re: [address-policy-wg] question about IPv4 legacy and transfers - should we convert legacy to non-legacy with transfers?

[Nick Hilliard]

Piotr Strzyzewski via address-policy-wg wrote on 22/07/2019 14:26:

IMHO, this is not the case here. Let's try not to fall in the false
dilemma here.


there's no false dichotomy.

Non legacy address space falls under various policies e.g. geographic 
association and being subject to high RIR costs.  These policies are 
what causes legacy address space to cost more than RIR address space on 
the address market.


If a legacy block is threatened with being converted from something more 
valuable to something less valuable, then people will avoid the RIR 
transfer route and we'll end up with less accurate registry info.


Nick

Re: [address-policy-wg] question about IPv4 legacy and transfers - should we convert legacy to non-legacy with transfers?

[Nick Hilliard]

JORDI PALET MARTINEZ via address-policy-wg wrote on 17/07/2019 19:22:

The point here is that what I consider a valid argument (fairness for
as much overall community as possible and a bad thing otherwise, so a
problem), you think is not. This is a valid disagreement, of course
and this is just part of the process to improve our policies.

Jordi,

this has nothing to do with fairness.  The RIPE community has a policy 
for dealing with legacy resources and legacy resource holders. By having 
this policy, the RIPE Community has openly declared that it accepts that 
legacy resources are a fair and reasonable part of the number resource 
ecosystem.


Nick

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

[Nick Hilliard]

Aris Lambrianidis wrote on 05/06/2019 01:49:

Hmm.. why shouldn't defunct IXPs not be taken in consideration though?


Because they will have handed back their address space.  The address 
assignment policies are explicitly designed to have a garbage collection 
mechanism under 2007-01.  If you don't actively maintain your 
registration, it reverts to the registry.


Nick

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

[Nick Hilliard]

Aris Lambrianidis wrote on 04/06/2019 18:03:
Consulting the PCH IXP directory as Nick did earlier (as well as the 
Euro-IX one), I think it is also reasonable to say that

allocating a /24 is ambitious for the overwhelming majority of cases.

Only 64 of listed IXPs have equal to, or more than, 100 participants, 
out of 958 IXPs, or about 6.6%.


In this light, perhaps the default allocation discussed in 6.1.4 should 
go down to a /25.


/25 is too small, even for smaller IXPs.

~400-500 of the entries in the PCH IXP directory are defunct.  For the 
remainder, the participant numbers are inaccurate, mostly on the low 
side. A figure of about 500 active IXPs is largely corroborated by the 
IXP DB (650 entries, with some effectively defunct).


The figure you need to look at is 50% usage rather than 100% usage.  If 
you pin the assignment size to /25, then 50% of /25 is 64 participants, 
i.e. about ~20-25% of IXPs, not 6.6%.


The current run-out rate for the RIPE pool is about 15k addresses per 
day.  This means that a /16 is 4 days worth of allocations at the 
current rate.  A /16 pool gives adequate breathing room for core 
internet infrastructure, with a /24 assignment size.


The central question of this policy update is not the assignment size 
for IXPs, but whether it's worth investing 4 days out of 30 years worth 
of allocations in order to provide important flexibility for the 
internet core in the future.  I'm inclined to think it is.


Nick

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

[Nick Hilliard]

Tore Anderson wrote on 31/05/2019 08:41:

Looking at the DFZ, there is only a single advertisement coming out
of the current IXP pool¹:

https://stat.ripe.net/widget/routing-status#w.resource=185.1.0.0%2F16

The prefix in question is 185.1.69.0/24.


[1] I was told on IRC that the reason for the specific advertisement
seen is to provide some kind of quasi-OOB Internet transit service to
the IXP members.
The prefix in question is 185.1.69.0/24 (INEX Cork). Putting my INEX CTO 
hat on for a moment, I can confirm that INEX does not provide a 
quasi-OOB Internet transit service for its members.


Nick

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

[Nick Hilliard]

Gert Doering wrote on 29/05/2019 16:45:

IXPs say they need globally unique space, and they are the experts here.


From an architectural point of view, it's a good idea to use publicly 
registered numbering resources when interconnecting with third parties. 
IXPs are an extreme case of this because the same resource block is used 
to connect to multiple parties at the same time.


One of the reasons this can cause problems is that the address block of 
the peering LAN often ends up redistributed in the IXP participant's 
routing tables.  Lots of organisations redistribute rfc1997 address 
space internally in their own networks for their own purposes, so if 
this conflicts with the IXP peering LAN address block, the organisation 
is going to end up with connectivity problems.  There are other reasons 
this can cause problems, but this is one of the more obvious ones.


Nick

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

[Nick Hilliard]

Denis Fondras wrote on 29/05/2019 14:11:

On Wed, May 29, 2019 at 02:17:43PM +0200, Marco Schmidt wrote:

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




Just because of "It no longer provides for IXPs that need more than a
/23 of IPv4 space" I am against this proposal.


Could the NCC provide any stats on how many /22s have been assigned 
under the IXP assignment policy?


/23 is 512 hosts, which is large by IXP standards. The PCH IXP directory 
suggests there are about 20 IXPs worldwide which are larger than 256 
connected parties.


Nick

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

[Nick Hilliard]

Töma Gavrichenkov wrote on 05/11/2018 10:36:

But when we try to rely on6.2  for a definitive advice, we don't get any:


The general practice is to treat /30-/32 as LIR infrastructure 
assignments, i.e. not register them.


/29s are borderline - there are cases where a /29 could be considered as 
a point-to-point link, e.g. single customer address + VRRP config on 
routers.


Ambiguity allows common sense to be used.

There is a bigger issue of whether personal information should be 
exposed in public whois for any resource registration.


Nick

Re: [address-policy-wg] country code in ORGANISATION object

[Nick Hilliard]

Gert Doering wrote on 21/10/2018 18:40:

Which WG do we want to have this discussion in?  Is this more DB-ish,
or more AP-ish?


DB-WG

Nick

Re: [address-policy-wg] [CFP] ACM/IEEE IPSN 2019 in CPSWeek

[Nick Hilliard]

Could the chairs please be more proactive about ensuring that APWG's 
anti-spam policy is applied?


IEEE conference spam in particular seems to be a problem going back many 
years.


Nick


Vijay Rao wrote on 27/09/2018 10:39:
The 18th ACM/IEEE The International Conference on Information Processing 
in Sensor Networks (IPSN)


===
April 16-18, 2019, Montreal, Canada

IPSN'19 is part of CPS-IoT Week 2019, co-located with HSCC, ICCPS, 
CPS-IoT, and RTAS.


http://ipsn.acm.org/2019

===

The International Conference on Information Processing in Sensor 
Networks (IPSN) is a leading annual forum on research in networked 
sensing and control, broadly defined. IPSN brings together researchers 
from academia, industry, and government to present and discuss recent 
advances in both theoretical and experimental research. Its scope 
includes signal and image processing, information and coding theory, 
databases and information management, distributed algorithms, networks 
and protocols, wireless communications, collaborative objects and the 
Internet of Things, machine learning, mobile and social sensing, and 
embedded systems design. Of special interest are contributions at the 
confluence of multiple of these areas.


Like prior years, IPSN 2019 will continue its co-location with CPS-IoT 
WEEK, the premier venue for research and development of Cyberphysical 
Systems, and its strong focus on algorithms, theory, and systems for 
information processing using networks of embedded, human-in-the-loop, or 
social sensors, as well as new hardware and software platforms, design 
methods, architectures, modelling, implementation, evaluation, 
deployment experiences, and tools for networked embedded sensor systems 
and the Internet of Things. Topics of interest include, but are not 
limited to:


- Sensor data storage, retrieval, processing
- Streaming sensor system tasking and operation
- Coding, compression, and information theory
- Theoretical foundation and fundamental bounds
- Network and system architectures and protocols
- IoT gateway platform architecture and services
- Outdoor, wide-area sensing systems
- Location, time, and other network services
- Programming models, languages, and systems
- Programming models for IoT ensembles
- Modeling, simulation, and measurement tools
- Operating systems and runtime environments
- Applications in health, wellness & sustainability
- Applications in smart cities and urban health
- Experiences, challenges, comparisons of platforms
- Discovery, coordination, and use of IoT services
- Security and privacy in heterogeneous systems
- IoT reliability, adaptability, and dependability
- Technical assessment of emerging IoT standards
- Wearable systems and data processing algorithms
- Sensor-enabled drone platforms and algorithms

In addition to IPSN's traditional focus, IPSN 2019 will place a 
particular emphasis on embedded machine learning and computer vision, 
with a special track centered on these topics. In this case, topics of 
interest include but are not limited to:


- Machine learning and deep learning on sensor data
- New hardware and system design to enable machine learning on sensor data
- Novel embedded machine learning algorithms
- Data related issues, such as methods, tools, and analysis
- Computer vision for resource-constrained and mobile platforms

Submission Guidelines
Coming soon.

Response Process
As in previous years, IPSN will also elicit a review and response 
process. After the initial review, the program committee may request a 
short response from selected papers for additional clarifications. The 
authors will get a short time window of roughly 24 hours to respond. 
Participation in the response process is not mandatory.


Joint statement from IPSN and IoTDI
The two conferences are collaborating to create new synergies, also 
exploiting their CPSWEEK bi-annual co-location. Prospective authors are 
thus strongly encouraged to consider these guidelines:


- Contributions of embedded nature and applying to network segments from 
the IoT gateway to field devices should be submitted to IPSN. Examples 
include localization, low-power wireless networking, and embedded data 
processing.
- Contributions with an end-to-end perspective or applying to network 
segments from the IoT gateway to the cloud should be submitted to IoTDI. 
Examples include cloud data processing, edge computing, and systems 
covering multiple network segments.


The TPC chairs of both conferences may agree to move a submitted paper 
from one to the other if they see a better fit, subject to the authors’ 
consent. The final decision about where to submit, and therefore what 
program committee will review the work, ultimately rests with the authors.


Key Dates
Paper Abstract Registration: October 10th, 2018 

Re: [address-policy-wg] proposal to remove IPv6 PI

[Nick Hilliard]

JORDI PALET MARTINEZ via address-policy-wg wrote:

But, I think it is clear now that the main reason (1), was not
really an obstacle for the IPv6 deployment, and in fact, where we
are lacking "more" IPv6 deployment is in enterprises, so it didn't
worked to resolve that problem.


You're misremembering the problem.  The reason for the IPv6 PI policy
was not that it was going to help deployment of IPv6, but instead that
the lack of easily available, provider-portable IPv6 address space would
create unnecessary obstacles to deployment.  This hasn't changed.


Beard in mind, that having a *single* member contract, means
simplicity for both the NCC and the members, which means somehow a
(marginal) administrative cost decrease, but also simplification for
the policies, less interpretation errors, less people trying to bend
the policies to the limit, etc., etc.
There are ~2600 IPv6 PI assignments associated with ~2450 individual 
organisations.  Your proposal seems to require that these 
end-user-to-LIR contracts are replaced with end-user-to-RIPENCC contracts.


Can you elaborate on how you see this being handled? And what would the 
RIPE NCC do if an end-user declined to change?


Nick

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[Nick Hilliard]

JORDI PALET MARTINEZ via address-policy-wg wrote:
> Obviously, I don’t agree, just because for me, “consensus” is having
> no objections, not a “democracy voting”.

APWG aims to follow the IETF approach to consensus, as defined in
rfc7282.  This explicitly allows for consensus to be declared even if
there are outstanding objections.

Nick

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

[Nick Hilliard]

Ondřej Caletka wrote:
> The only difference is that with PI, the it is the RIPE NCC evaluating
> the rules, which seem to be too strict in considering what should count
> as sub-assignment. But if we try to fix this, let's keep the fix working
> both for PI and PA addresses. Just because the problem is not visible in
> PA world does not mean it does not exist there.

I see what you mean here, but this is something that has been almost
universally ignored for PA assignments since forever.

Nick

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

[Nick Hilliard]

Erik Bais wrote:
> I don’t think that the fear from past times is something that we
> should keep in this discussion these days..

the issue isn't fear from past times: it's that PI & PA are ingrained
pretty deeply in the RIPE NCC billing model and service expectation
model, and some way would need to be found to square a number of circles
in order to integrate the two flavours of integers.  I'm not objecting
to trying to get this done, btw, just saying that if we're going to do
it, let's do it properly.

Regarding 2016-04, it's clear that the current rules / rule
interpretations are too limited and are causing problems in the real
world, so the sensible thing to do would be to open up the usage terms
so that third parties can use PI assignments, even if the addresses are
not subassigned.  This doesn't go as far as what Jordi is talking about
and looks like a practicable middle ground to aim for.

Nick

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

[Nick Hilliard]

JORDI PALET MARTINEZ wrote:
> I don’t think reaching consensus in the PI/PA change will be so easy
> in the “near future” (considering that it may require a long
> implementation time), and a middle way proposal looks feasible to
> me.

but it's not a middle way: it's removing the block on sub-assigning to
other parties, which is the thing that distinguishes PI from PA.

Nick

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

[Nick Hilliard]

JORDI PALET MARTINEZ wrote:
> Fully agree, and I’ve been working around that idea for about a year
> already … I’ve something in the kitchen, but still not mature
> enought.
> 
> I’m waiting for NCC budget figures to be able to make a proposal that
> is sustainable in the long term. I know “money” is not related to
> policies, but in this case, even if is only rational behind the
> proposal text, I think it is a must.
> 
> Nevertheless, my opinion is that that change may take, as you said, a
> longer period of discussion, and I will like to make sure, meanwhile,
> cases such as Max one, aren’t “in hold” for deploying IPv6.

if you're planning to change this universally some time in the future,
it would be simpler and easier to make a step change (i.e. Max's
suggestions) in the ipv6 assignment policy now rather than making a
fundamental change there first and catching up with other bits of policy
later on.

Nick

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

[Nick Hilliard]

Gert Doering wrote:
> both would work to solve the (real) problem at hand, and Jordi's approach
> would certainly much easier than trying to come up with unambiguous wording
> to "permit some, disallow other" use cases.

this is a restatement of the long-standing question about whether the
RIPE community should continue with the idea of differentiating between
PA and PI address space.

If we're going to go down this road, this is a substantial change to
make, with far-reaching consequences, and it needs a good deal more
attention than a couple of lines in the ipv6 policy doc.

Nick

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

[Nick Hilliard]

Gert Doering wrote:
> So:
> 
>>> We encourage you to read the proposal, impact analysis and draft
>>> document and send any comments to 
>>> before 17 November 2017.
> 
> Please speak up *here* if you have opinions on this proposal.

Looks sensible.  I support the proposal.

Nick

Re: [address-policy-wg] IXP peering lan reachability

[Nick Hilliard]

Gert Doering wrote:
> The *absence* of the route is a very strong indicator that no other
> services than directly peering-related are sitting on that network, no?

or that the holder is squatting the space, or that it's being used for
connectivity which is unrelated to the standard DFZ (e.g. l3vpn p2p
addressing), or that it's just not being used at that time, or...

By all means, the RIPE NCC should flag things as a problem if it sees
server farms configured on an assigned ixp range, or sees traceroutes
ending up in residential customer, or whatever, but the presence or
absence of a prefix in the dfz, per se, does not mean anything.

Nick

[address-policy-wg] IXP peering lan reachability

[Nick Hilliard]

Following up on Andrea's presentation earlier (for the record, ripe75,
apwg session #1, tuesday morning), there aren't compelling reasons for
the RIPE NCC to get involved in whether an IXP announces their peering
LAN prefix into the DFZ.  It's really a matter of local policy for the
ixp as to whether they want this to happen, and if a prefix is announced
into the dfz, this doesn't make any statement one way or another about
what the prefix is used for.  Lots of IXPs announce their peering lan
netblocks and many others choose not to.

The reasons for announcing relate mostly to debugging and problem
diagnosis, e.g. ping / traceroute.  We know of several IXP members at
various INEX LANs who use external reachability checking services to
monitor their service's uptime, which is a good thing to do and they see
a benefit from this, and they particularly don't want to see this
benefit going away.  Regarding traceroute, the udp/icmp replies can be
dropped if the network you're tracing from has uRPF enabled, which makes
problem diagnosis troublesome.

The reason most IXPs don't announce their peering LANs relates to
protecting against DDoS attacks.  Although we've had occasional DDoS
attacks launched against our infrastructures in the past, we have not
had service-affecting problems as a result.  If a service affecting
problem happens, we can announce the blocks with no-export or
no-announce, which would reduce the blast radius - or we could
completely drop the announcement, if that didn't work.

We're aware that the experience at other IXPs - especially larger IXPs -
can be different, but given that announcing the blocks provides useful
telemetry and diagnosis capabilities, and we've not had problems in the
last, we don't see any particular reason to stop announcing the range.
The risk/return ratio doesn't justify it.

The experiences of other IXPs may be different regarding ddos problems,
but many (most?) organisations connected to IXPs use "redistribute
connected" to inject the peering LAN prefix into their IGPs, and the
largest IXPs have visibility to most of the Internet prefixes, so in
practice, not announcing the blocks makes less difference to DDoS than
it might appear.

I'd politely suggest that this is an area that the RIPE NCC should not
get involved in, especially from the point of view of implicitly issuing
recommended practice by implying that there is a problem with doing
this.  The IXP associations are better placed to gather consensus for
creating best practices, and there is no general consensus in the IXP
community on this issue.

As regards using this as a metric for determining whether an ixp address
assignment is being used for legitimate purposes, I'd suggest that this
is of only marginal use at best.  By all means run a port scan to see if
there is any obvious mis-use (e.g. services listening on www/smtp/etc),
but the presence or absence of the route in the dfz doesn't mean
anything one way or another.

Nick
CTO, INEX

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

[Nick Hilliard]

Willy MANGA wrote:
> So again, why do they rely on v4 (only) ? I really want to understand
> hurdles on european continent.
> 
> I hope this time, it will be clearer :)

same reason as in africa: for most organisations it's too much work with
too little return.

Many humans will only react after a crisis hits, even if the cost of
that is higher overall.

Nick

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

[Nick Hilliard]

Willy MANGA wrote:
> being a newbie here can you please explain briefly why, as of today ,
> these people really need IPv4 addresses ?

I'd be tempted to answer, except that you sent this email from an ipv4
address.  So, please deconfigure all IPv4 addresses from your computer,
re-send the email, and then I'll answer.

> Or at least why they cannot
> start a transition process towards IPv6?

Without ipv4 addresses, transition technologies don't work.

Nick

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

[Nick Hilliard]

Randy Bush wrote:
> did it say anything about price?  i missed that?  i did not think
> the AP WG dealt with pricing; so it would be pretty strange.

You're correct in saying that APWG does not deal with pricing, but it's
a bit jesuitical not to acknowledge that the practical impact of this
policy change will be a dramatic increase in RIR-allocated ipv4 addresses.

> but we can postpone the inevitable so folk have time to get in
> the lifeboats.

There is no amount of time that will be enough.

> so do we want to do it in a controlled and managed fashion or 
> chaotically?

I genuinely don't think that this proposal will impact much on this
either way.

Nick

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

[Nick Hilliard]

Marco Schmidt wrote:
> 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.

The rationale for this is to make RIR-allocated ipv4 address space
string out a bit longer by raising the price and dropping the size.

The rationale says:

> Allowing or encouraging intentional run-out of IPv4 addresses is an
> abrogation of the RIPE community's responsibility. Any measures that
> can be taken to postpone this point in time should be seen as
> critical.

It is not convincing to state that allocating /22s instead of /24s is an
abrogation of responsibility, and as a community we should step back
from this sort of overly dramatic language.  A more sober viewpoint is
that any future decision about tweaking the balance between allocation
size and anticipated run-out time is not much more than an exercise in
deck-chair rearrangement.  It's a deck-chair rearrangement because the
ship is going down and nothing can stop it.

The proposal fails to mention the windfall that will ensue for existing
address holders as the baseline RIR price for IPv4 addresses will
increase from around €4.70 to nearly €19.  There is no implication here
that any of the authors has any self-interest in terms of proposing this
sort of policy change, but there are quite a few people in this WG who
would be happy with this sort of change, both brokers and incumbent
address holders.  Because of this, we also need to consider as a
community what part self-interested financial motivation is going to
play in terms of whether people are going to support this proposal or
not, and how compatible this is with good governance of the
policy-making mechanism for global resource allocation.

The policy proposal also only skirts the issue of the cost of making
this change to the Internet core.  The remaining pool of 0.66 * /8 is
~11k /22s or ~43k /24s.  If, as this proposal suggests, we move from a
minimum routable range of /24 to /25 or longer, this is a change that
comes at a cost in terms of reducing the lifetime of any routing device
on the internet which takes a full dfz.

On the flip side, we also need to consider how important this policy is
in absolute terms.  This is quantifiable because it affects 0.66 of a
single /8, which is 0.3% of the entire IANA-allocated ipv4 address
space.  There are single early-adopter organisations out there who, if
they decided to rationalise their address space, would have an effect on
ipv4 depletion far in excess of any policy change that the RIPE
community could make.

Overall, I don't see a compelling case to make this change.

Nick

Re: [address-policy-wg] Password

[Nick Hilliard]

On 9 Apr 2017, at 18:35, Randy Bush  wrote:

>> Need password 
> 
> ofBogDog8\9buw4bXLoGvn.

It's more secure if you change all the "o" characters to "0".

Nick

Re: [address-policy-wg] [policy-announce] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy)

[Nick Hilliard]

Richard Hartmann wrote:
> I would once again urge that the default view in the PDP process
> should be diffs. While I could find diffs between proposal versions on
> the PDP site, there was no obvious way to diff current text against
> current proposal version.

There were easy-to-follow diffs here:

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

Nick

Re: [address-policy-wg] ipv6 assignments

[Nick Hilliard]

Gert Doering wrote:
> But maybe now is the time to go where no man has gone this year, and
> propose an IPv6 related policy proposal - any volunteers? :-)

I'll take a look at it.

Nick

Re: [address-policy-wg] ipv6 assignments

[Nick Hilliard]

Marco Schmidt wrote:
> 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.

Hi Marco,

Thanks for clarifying.  The alternative was awkward:

http://i.imgur.com/J8vJwYR.jpg

It looks like the interpretation and the wording are slightly at
variance, albeit in favour of common sense, so the wording should
probably be regarded as a policy bug which needs to be fixed.

Nick

[address-policy-wg] ipv6 assignments

[Nick Hilliard]

Apropos of one of those endless arguments on the Internet (where
everything is true, because it says it on the Internet), I had a
discussion with Kurtis about the definition of an ipv6 "End Site", which
is specified in section 2.9 of RIPE-655. This says:

> 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.

Section 5.4 and 5.4.1 then state:

> LIRs must make IPv6 assignments in accordance with the following provisions.
>
> End Users are assigned an End Site assignment from their LIR or ISP. 

So the policy appears to state that an IPv6 assignment can only be
issued to an end user if the end user has a transit service to more than
one site, presumably ipv4 because demanding ipv6 connectivity would
create a circular requirement.

In other words, ipv4 connectivity to multiple different sites appears to
be a mandatory prerequisite in order to get an IPv6 assignment.

Could someone in the RIPE NCC please confirm that this policy is being
policed as stated? And if not, when can we expect all non-compliant
assignments in the RIPE NCC service region to be revoked?

Nick

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

[Nick Hilliard]

Riccardo Gori wrote:
> I strongly, strongly and again strongly oppose this proposal.

does this count for three votes?

Nick

[address-policy-wg] Create FAQ? (was: Re: IPv4 reserved space)

[Nick Hilliard]

Tore Anderson wrote:
> If by some miracle you would be able to pull it all off, keep in mind
> that the ~107M addresses gained by the RIPE NCC would all be used up
> within two years if we return to the pre-depletion allocation policy
> and consumption rate. Ask yourself: «then what?»
> 
> Maybe you can now see why folks are telling you that this would be a
> colossal waste of time 

APWG Chairs,

Is there any possibility of creating a FAQ?   There are a bunch of
issues which are coming up repeatedly, of which this is one.

Nick

Re: [address-policy-wg] IPv6 deployment

[Nick Hilliard]

Arash Naderpour wrote:
> That was just an example to let community  knows that it is not only
> technical difficulties preventing some areas sticking to IPv4,
> There are more countries out there (I can prepare a list if you are
> really interested) with similar or other type of non-technical
> limitations.
> 
> RIPE Community does not belongs just to the ones who have possibility
> to deploy IPv6, (even if it is not the community responsibility to
> work around the damages some governments are causing)

Arash,

what do you propose as a solution then?

Nick

Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 June 2016 (Last /8 Allocation Criteria Revision)

[Nick Hilliard]

Roger Jørgensen wrote:
>  We've passed the "it's nice to have" some years ago, now we're down
> to , do you _really_ need 10 addresses? Can you survive with 2 and
> deploy IPv6?

No really, we're not.  The RIPE Community exited the "do you really need
X addresses?" stage in 2014.

We're now at the stage where LIRs need to do what they feel is necessary
to preserve their remaining stocks of IP addresses in the way that they
feel is most appropriate for their long term requirements.

There are training courses, policy documents, endless discussions, ARC
checks and more advice available than you can shake a stick at, all of
which is aimed at helping inform LIRs about depletion and what to do.

But ultimately it is up to the LIRs.  Neither the RIPE Community nor the
RIPE NCC has any business beating them with sticks to get them to plan
for their futures.  If they do not do this, it is not the responsibility
of the RIPE NCC or the RIPE Community to do it for them.

If LIRs need more IPv4 address space after their single allocation from
the RIPE NCC, then they need to look on the open market.

If/when the open market dries up or becomes too expensive, then there
will be no options left except ipv6 and/or even more NAT.

Nick

Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 June 2016 (Last /8 Allocation Criteria Revision)

[Nick Hilliard]

Riccardo Gori wrote:
>> There are no good solutions to the problem at hand, only compromises.
>> If the current policy is changed to something else, the people who
>> benefit in the short term will be happier and the people who pay for
>> this generosity will be disappointed.
> IPv6

If ipv6 provided full backwards compatibility with ipv4, it would be a
solution.

Any organisation which is forced into providing ipv4 connectivity using
an ipv6 transition mechanism will operate at a competitive disadvantage
to an organisation which can provide native ipv4.  This isn't a swipe at
ipv6: it's simply an observation that we have come to depend on features
of ipv4 which cannot be fully replicated using ipv6 transition mechanisms.

This is why I referred to migrating to ipv6 as a compromise.  Long term,
it may be a good compromise and many years down the road, it may even be
better than ipv4.  But as long as there are ipv4 addresses available, it
is condemned to being second best by the legacy of the existing
single-stacked ipv4 install base.

> every policy that makes IPv6 adoption a must can help slow down IPv4
> allocation rate and in the meanwhile will even lower IPv4 maket value
> [...]

I don't believe there is any evidence to support either of these statements.

Also, please bear in mind that if strong policies caused better adoption
of new protocols, we would be having this discussion using X.400.

Nick

Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 June 2016 (Last /8 Allocation Criteria Revision)

[Nick Hilliard]

Gert Doering wrote:
> Right - *but* it might be an interesting idea to turn around this discussion,
> away from haggling about the last scraps, into being able to give more 
> useful guidance to LIRs.
> 
> Like,
> 
>   - if you need to connect end-users, best practice is dual-stack with
> native IPv6 and CGNAT IPv4 (it stinks, but gets the job done while
> content is not IPv6 capable everyhwere)
> 
>   - if you run a data-center, run ipv6-only on the inside, and add 
> Tore-style NAT46 to give each service a single public IPv4 address
> (insert pointer to RFC...)
> 
> etc.
> 
> While not truly *APWG* relevant, we could at least find out where the
> highest pain is, and then throw the ball over to the IPv6 WG to provide 
> solutions :-)  (totally IETF style).

That sounds like an offer to write the document.

Nick

Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 June 2016 (Last /8 Allocation Criteria Revision)

[Nick Hilliard]

Roger Jørgensen wrote:
> Be specific, is it for having more address for the end-users? Datacenter?
> Services? Infrastructure? IPv6-to-IPv4 services? CGN? Proxyes?

[x] all of the above, and more.

This question isn't relevant as it seems - lots of organisations have
their needs and the RIPE NCC cannot and should not be arbiter of whose
need is greatest or should take precedence.

What's relevant is that due to a shortage of IPv4 address space,
businesses are being forced to change business practices.  This impacts
on AP-WG because on the one hand, there are some addresses left at the
bottom of the RIPE NCC barrel, and on the other, many LIRs are looking
at these addresses, realising that if they could only get their hands on
some of them, it would make life a whole lot easier.  AP-WG is seen as a
place that could potentially tilt the balance one way or another, if
only consensus could be gained.

There are no good solutions to the problem at hand, only compromises.
If the current policy is changed to something else, the people who
benefit in the short term will be happier and the people who pay for
this generosity will be disappointed.

And, as has been pointed out repeatedly by many people for many years,
full depletion is only a couple of years down the road, regardless of
what allocation policy is applied.  Any change of policy is little more
than rearranging deck-chairs on the Titanic.

The ship is going down and there is nothing that anyone in the world can
do to prevent this.

Nick

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

[Nick Hilliard]

Like the curate's egg, this proposal is good in parts. Here's the good part:

> - Explicitly state that the current IPv4 allocation policy applies to
> all available IPv4 address space held by the RIPE NCC that has not
> been reserved or marked to be returned to IANA

The rest of the proposal is - like the rest of the curate's egg - best
deposited in the compost bin.

Specifically, it will not deal with the problem that the RIPE NCC was
set up to do, namely to ensure accurate registration of resources.  On
the contrary, it will encourage black-market transfer of /22s and
probably a proliferation of one-allocation-per-shelf-company
allocations, because paying €1400 per annum for 1024 addresses is still
a cheaper option in the medium term than buying addresses outright on
the market (1024/€1400 = €0.73 per address per annum).

At this stage, APWG is being trolled with "let's change the last /8
policy" proposals.  It's clear that there isn't consensus on 2015-05 and
that there won't be any consensus on this proposal either, so I'd
politely like to ask the chairs to do two things:

1. declare their opinion on whether 2015-05 reached consensus

2. use the bunfight which is inevitably going to happen in Copenhagen to
allow them to exercise more restraint about what sort of proposals hit
the mailing list in future so that we don't spend years wasting time
squabbling about the dregs sitting at the bottom of the ipv4 allocation
barrel.

(ap-wg chairs: for the record, this is a "I object" email).

Nick

Re: [address-policy-wg] R: making progress with 2015-05

[Nick Hilliard]

Jim Reid wrote:
> Third, I think it’s unwise to have a firm rule on transfers. Though I
> understand why you’ve suggested this: it’s meant to stop LIRs selling
> off these extra addresses. For one thing, there can be valid reasons
> for transferring space that don’t involve selling IPv4 addresses - a
> business reorganisation for instance. Next, if an LIR wants extra
> /22s in order to sell the addresses, they’d still do that
> irrespective of what the transfer restrictions were in place.

fourth: this suggestion proposes to revert to a "needs" based allocation
policy.  This policy was removed a couple of years ago for good reasons
which are still valid now and it is not realistic to expect that the
clock is going to be turned back on this.

Nick

Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)

[Nick Hilliard]

Adrian Pitulac wrote:
> I think this has not been expressed directly, but IPv6 implementation
> obligations in this policy might be the reason why it could be MUCH
> better than existing policy who offers the opportunities for future
> entrants but does not have a long term solution for the real problem
> (IPv4 exhaustion).

If you think ipv6 implementation obligations are a good idea, then
please feel free to put forward a separate policy to introduce them, but
don't confuse them with changing the last /8 allocation policies because
they are fundamentally different things.

Incidentally, the reason Randy Bush wrote this earlier this morning:

> believing ipv4 allocation as an incentive for ipv6 deployment is yet
> another in a long line of ipv6 marketing fantasies/failures.  sure, give
> them a v6 prefix, and they may even announce it.  but will they convert
> their infrastructure, oss, back ends, customers, ... to ipv6?  that
> decision is driven by very different business cases.

... was because he - and many other people - watched for several years
as top-down policy obligations to implement OSI protocols as
communication standards failed utterly and beyond hope.  They failed
because top-down decrees don't work.

As a separate issue, the RIPE NCC is not in the business of telling its
members how to run their networks.

Nick

Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)

[Nick Hilliard]

Radu-Adrian FEURDEAN wrote:
> You are talking about people addicted to Coca-Cola. You can't just ask
> them to plain stop drinking Coca-Cola, as long as you have some (and
> even if you no longer have, it's still difficult).

People can be as addicted to using ipv4 addresses as they want.  It
changes nothing: the supply of previously unused address blocks is
running out, and the only issue with allocation of the remainder is how
to allocate them rather than the uncomfortable reality that they will
soon disappear completely and we will have no options for internet
connectivity other than ipv6 and the ipv4 address market.

Regarding the current allocation policies, you still have not addressed
the query that several people have raised about why it is better to shut
off opportunities for future internet service market entrants than it is
to make things marginally easier for a small segment of the existing
market for a short period of time, other than "but it hurts".

Nick

Re: [address-policy-wg] Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)

[Nick Hilliard]

Riccardo Gori wrote:
> This proposal aims to address the real need [...]

Nearly everyone has a need for more IP addresses, not just those with
less than /20.  The need that organisations have for more IPv4 addresses
isn't in dispute.  The question is who pays for this need.

2015-05 proposes that we mortgage away the requirements of future market
entrants in order to service the community's need right now.  There are
good reasons why the community should do this and equally - or depending
on your point of view, maybe even better - reasons not to do so.

My personal opinion is that given the problems this will create for
future Internet market entrants, I don't see sufficiently compelling
reasons to change the policy.

I respect the fact that you see things differently.  When you're
scraping the bottom of a barrel, disagreements are bound to happen about
who gets what dregs and when, and these disagreements will continue as
long as there is a single address block remaining in the RIPE NCC IPv4
allocation pool.  One of the few disadvantages with the current policy
that we can all agree on is that it will prolong these disagreements
compared to other policies which favour faster runout.

Nick

Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)

[Nick Hilliard]

Riccardo Gori wrote:
> I think this policy is not for faster exhaustion but for "farier
> exhaustion" and is offering a path to go over IPv4 while still needing
> it to grow.

It was only a matter of time before someone pulled out the word "fair".

"Fair" is a hugely subjective term best left to experts in the field:
namely children below the age of 16, all of whom have extraordinary
skills in the art of determining what is "fair", and more importantly,
what is not.

In order to make things better for one section of the RIPE community,
another part of the community will need to pay the price.  There are
several ways of doing this: we could tilt the policy in favour of larger
organisations at the cost of smaller organisations, or smaller
organisations at the cost of larger organisations, or existing
organisations in favour of future market entrants.

Currently the ipv4 allocation policy gives precedence to future market
entrants and smaller players.  This is an unusually altruistic position,
given that future market entrants have no say in how current policy is
determined.

2015-05 will change this balance further in favour of smaller players at
the expense of future market entrants.

At a helicopter level and speaking as a smaller LIR, I don't believe
that this is a good thing to do and consequently I do not support the
policy change.

Nick

Re: [address-policy-wg] An interesting policy question

[Nick Hilliard]

On 03/12/2015 19:56, Lu Heng wrote:
> I am asking a very specific question to an very specific service example
> here, the only way to be more specific would be naming people. 

you're asking a vague question with very few details and expecting a very
specific answer.

> the only way to be more specific would be naming people. 

which makes this sound like your email is the subject of an open issue with
the RIPE NCC.

If this is the case, it would probably be inappropriate to discuss the
matter on AP-WG because this mailing list doesn't have the full facts
available, nor does it have any mandate to discuss issues which are being
handled by the RIPE NCC.  In other words, this is the RIPE NCC's business.

If you feel that there is a problem with how the RIPE NCC is handling an
case, there is a Conflict Arbitration Procedure which allows an independent
Arbiters Panel to review any decision that the RIPE NCC has made.

Nick

Re: [address-policy-wg] address-policy-wg

[Nick Hilliard]

On 29/10/2015 14:38, Gert Doering wrote:
> Call to order.  Wishing for non-existant technologies to overcome IPv4
> shortage is totally off-topic here.

Can I also humbly suggest adding "let's make the RIPE NCC take existing
IPv4 allocations away from someone else (and give them to me)" to this list?

Nick

Re: [address-policy-wg] 2015-05 New Policy Proposal (Revision of Last /8 Allocation Criteria)

[Nick Hilliard]

On 21/10/2015 21:57, Radu-Adrian FEURDEAN wrote:
> Another thing, how do you define a "hidden transfer" ? Some LIRs do have
> assignments from other LIRs that they announce in the global table with
> their own AS. Those IPs still "belong" to the LIR having the superblock
> even if the superblock is not announced.

you need to address these questions to the authors of the proposal because
as it stands, it's ambiguous and open to a wide variety of interpretations.

Nick

Re: [address-policy-wg] 2015-05 New Policy Proposal (Revision of Last /8 Allocation Criteria)

[Nick Hilliard]

> 3. An equivalent of a /22 allocation can be requested every 18 months
> from the moment of the last allocation if the following conditions are
> met:
> 1. The LIR has not transferred any IPv4 address space out of its registry.

Is this to be interpreted as:

a) the LIR has not transferred any IPv4 address space out of its registry

or

b) the LIR has not registered any IPv4 address space transfer out of its
registry?

Option b is enforceable but largely pointless.

Option a is unenforceable because if the LIR chooses not to register the
transfer, then there is no way for the RIPE NCC to conclusively prove that
a transfer has happened and thus to deny the new allocation.

This proposal as it stands will put selective pressure on LIRs to implement
hidden transfer agreements and then to tell lies to the RIPE NCC in order
to justify getting more IP address space.  This is not good stewardship of
resources.

Nick

Re: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies)

[Nick Hilliard]

This has come up several times before.  There is support for asn32s in bgp
extended communities: you need the "Transitive Four-Octet AS-Specific
Extended Community" values from here:

http://www.iana.org/assignments/bgp-extended-communities

... and you need to hope that this is supported on your router software.
And everyone else's that you plan to talk to.

This can work in some situations where you have tight control over the
entire management plane of everywhere you plan to export these communities
to, but the internet at large is going to have a lot more difficulty with it.

As you point out, you can only support 16b:32b or 32b:16b style communities
with the current community mechanism, not 32b:32b communities.  The latter
will require implementation of draft-ietf-idr-wide-bgp-communities.

So if you have any requirement for 32b:32b communities, you're out of luck.

Nick

On 03/09/2015 18:59, George Michaelson wrote:
> Purely as a point of information, I think its worth remembering that 32 bit
> ASN cannot be used in currently specified BGP4 in communities, because its
> a 32 bit field defined as two 16 bit halves. I believe there is work afoot
> in IETF to fix this. I don't have concrete details.
> 
> Therefore there *is* a quality in 16 bit ASN which may be divorced from its
> association with specific V4 or V6 resources and which makes it a desirable
> thing, in itself, for some people: If you are in the business of doing TE
> in BGP with communities, you can't do it with 32 bit ASN. You have to use
> other mechanisms.
> 
> On that basis, Should you permit transfers of ASN, you might wish to permit
> transfers of ASN independently of any associated routable IP address space:
> people who already have space but need a 16 bit ASN may wish to acquire one.
> 
> I'm not an asset holder in the RIPE region, and I am staff at another RIR,
> so I stress this is purely informational. I'm not trying to directly
> advocate for or against ASN transfers.
> 
> -George
> 
> On 3 September 2015 at 14:38, Nick Hilliard <n...@inex.ie
> <mailto:n...@inex.ie>> wrote:
> 
> On 03/09/2015 18:09, Sascha Luck [ml] wrote:
> > Mind, if yelling loudly is how you get policy made in the RIPE
> > community, rest assured I can yell VERY loudly. I can, in fact,
> > even automate the yelling if need be.
> 
> please don't:  rfc7282 works much better.
> 
> Nick
> 

Re: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies)

[Nick Hilliard]

On 03/09/2015 18:09, Sascha Luck [ml] wrote:
> Mind, if yelling loudly is how you get policy made in the RIPE
> community, rest assured I can yell VERY loudly. I can, in fact,
> even automate the yelling if need be.

please don't:  rfc7282 works much better.

Nick

Re: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies)

[Nick Hilliard]

On 31/08/2015 23:18, Sascha Luck [ml] wrote:
> Can't have it both ways ;p As for myself, I would like to see
> some clarification on this myself.

have cake, eat cake.  As you point out, I changed my mind mid-email.  It
happens.

>> asn transfer policy: added "scarce resources ... cannot be transferred by
>> the resource holder within 24 months".  I don't disagree with this, nor
>> with the genericisation of this transfer restriction.
> 
> I do (disagree). IMO this should be a separate policy change, not
> something to be hidden in a huge re-work.

The only thing that's changing is that asn16s are now be included in the
24m restriction.  IPv4 addresses are already there.

Nick

Re: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies)

[Nick Hilliard]

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

one more issue:

> The rules for Internet number resource transfers (including legacy
> resources) to and from the RIPE NCC service region (often referred to as
> inter-RIR transfers)

It's good that this policy specifically includes legacy resources. It would
be useful to clarify in the policy whether inbound transfers of legacy
resources are subject to regular RIPE community number resource policies or
the "RIPE NCC Services to Legacy Internet Resource Holders" policy.  My
reading would be the latter, but as it's unstated, there is a potential
ambiguity here which has the potential of causing future problems.

Nick

Re: [address-policy-wg] RIPE IPv4 Allocation Policy

[Nick Hilliard]

On 28/08/2015 12:28, SBS - Support wrote:
 The RIPE policy of allocating only a PA /22 to new LIR's and not allocating
 any further IPv4 resources is highly detrimental to the growth of new
 upcoming organisations and protects legacy Telco operators, what are your
 thoughts on reviewing this and coming up with a process to allocate further
 resources to new LIR's if the need can be justified.

Anyone is free to suggest a better mechanism.  If you have some ideas which
are better that what's already there, please feel free to write a proposal.

Nick

Re: [address-policy-wg] Fwd: Suggestions on a new asn assignment policy

[Nick Hilliard]

David,

thanks for your comments.

On 11/08/2015 12:41, David Huberman wrote:
 Respectfully, I think the WG is trying to solve a problem which doesn't
 exist.

the policy has one problem now and is facing ASN16 depletion in the future.

The problem now is that you can only get an ASN if you are multihomed and
there are a bunch of situations where this is causing unnecessary problems.
 People work around this by lying on the application form and this is not
good stewardship of number resources.

Regarding depletion, we have an option of viewing this as a problem, or
not.  I view it as a problem because BGP community support for ASN32 is
very poor, and future entrants to the IP market will be penalised for being
future entrants.

There are substantial regulatory problem associated with existing market
players effectively locking out future players, and given that the RIPE NCC
has a monopoly in ip number resource assignments in this part of the world,
this is an issue which would be best avoided if possible.

 And I STRONGLY dislike policy discussions and text which penalize
 99.9% of the people just trying to operate a network because of the 0.1%
 of idiots who might think it's fun to do something stupid.

The suggestion provides for an ASN32 on demand to anyone who wants one
without any justification.  If you look at the numbers, this means that
about 85% of ASN assignments can be automated fully.  This is a serious win
in terms of registry efficiency which directly benefits those 85% of
assignments.

The remaining 15% will have more relaxed policies in place after their
first ASN assignment until the ASN16 pool has reached a certain point.

Future market entrants will benefit by being given a toe-hold in the door,
in the same way that future market entrants are given a toe-hold in the
door with the last /8 ipv4 allocation policy.  I.e. we already have a
precedent for community support for this.

 I believe ASNs should be given out to LIRs in an on-demand basis without
 cost and in an automated fashion.

At current run-rates, there are a 3-4 years of ASN16s left.  This wouldn't
be a problem if ASN32s were semantically identical to ASN16s, but
unfortunately they are not.  As has been pointed out repeatedly, there is a
root cause problem here which is not being addressed by the IETF and
if/when it's addressed, it will take may years to roll out - far longer
than 3-4 years.

 If at some point in the future, the NCC or community discovers some
 child has abused the system and taken an absurd number of ASNs, the NCC
 has the power to revoke the ASNs under sections 6.3, 9.3, and 9.4 of the
 RIPE NCC Standard Service Agreement.

As Mikael Abrahamsson points out, this is extremely difficult to implement
in practice.

Nick

Re: [address-policy-wg] 2014-03, “Remove Multihoming Requirement for AS Number Assignments”

[Nick Hilliard]

On 27/07/2015 12:53, Nick Hilliard wrote:
 On 27/07/2015 12:55, Saeed Khademi wrote:
 As far as I know, having an AS number is necessary for BGP routing.
 Now my question is that, if a customer doesn't have multiple links ( at
 least 2 )
 what is the use of having an AS number?
 
 they may want to become multihomed in the future.

oops, hit send too quickly.

They may also be providing l3vpn services, or providing BGP-to-customers
for connectivity requirements.  There are plenty of reasons to use an ASN
which don't have anything to do with IP transit.

Nick

[address-policy-wg] ARIN reaches depletion

[Nick Hilliard]

https://www.arin.net/announcements/2015/20150701.html

Nick

Re: [address-policy-wg] RIPE != RIPE NCC

[Nick Hilliard]

On 10/06/2015 14:03, Randy Bush wrote:
 what is missing here is that, if only LIRs decided policy, a few
 thousand folk (likely 10 people on a mailing list), would decide policy
 affecting millions internet users.

~980m.

Nick

Re: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations)

[Nick Hilliard]

On 09/06/2015 12:15, Sascha Luck [ml] wrote:
 This is also the (only) reason why I oppose this proposal. It
 sets a precedent for ex post facto rule changes which is, IMO,
 dangerous, especially in light of other appetites for stricter
 IPv4 rationing that have been voiced in this discussion.

not really, no.  RIPE NCC assigned number resources were and are assigned
on the basis of the resource holder adhering to RIPE policy.  Policy
changes which apply retroactively to existing number resources have been
made in the past, notably 2007-01.  I.e. this policy change doesn't set a
precedent.

Nick

Re: [address-policy-wg] 2015-02 Draft Document and Impact Analysis Published (Keep IPv6 PI When Requesting IPv6 Allocation)

[Nick Hilliard]

On 08/06/2015 14:43, Marco Schmidt wrote:
 The impact analysis that was conducted for this proposal has also been 
 published.
 
 You can find the full proposal and the impact analysis at:
 
 https://www.ripe.net/participate/policies/proposals/2015-02

Looks good.

Nick

Re: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments)

[Nick Hilliard]

On 16/05/2015 03:33, David Huberman wrote:
 If the RIRs don't do anything to preserve 2-byte AS numbers, then things
 are going to start really breaking.

s/RIRs don't do anything to preserve/vendors don't to anything to support/

ASN16 runout is inevitable and is now within sight: IANA's stock is gone.
The RIRs can twiddle policy this way or that, but they can't stop runout
and will find it difficult even to slow it down.

If the vendors are pretending otherwise - either to themselves or their
customers - then they are deluded.  If RIR run-out hits before they have
implemented asn32 support and shaken out all the bugs, then they will find
that their kit is obsolete for new customers and this will have commercial
implications for them.

Nick

Re: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation)

[Nick Hilliard]

Looks good to me.  Support.

Nick

On 14/04/2015 14:52, Marco Schmidt wrote:
 Dear colleagues,
 
 A proposed change to RIPE Document IPv6 Address Allocation and Assignment 
 Policy 
 is now available for discussion.
 
 You can find the full proposal at:
 
 https://www.ripe.net/participate/policies/proposals/2015-02
 
 We encourage you to review this proposal and send your comments to
 address-policy-wg@ripe.net before 13 May 2015.
 
 Regards
 
 Marco Schmidt
 Policy Development Officer
 RIPE NCC
 
 

Re: [address-policy-wg] APNIC temporarily freezing v4 transfers to RIPE NCC?

[Nick Hilliard]

On 12/03/2015 12:45, John Curran wrote:
ARIN's policies only apply to number resources that are contained 
within in the ARIN registry.  To the best of my knowledge, number 
resources which have been transferred to another regional registry 
would be subject to that regional Internet registry's policies.  
  
ARIN's policies most certainly apply to all resources in the ARIN 
registry database, and could easily have implications for ability 
to transfer to another party in the ARIN region or party in another 
region, but once transferred to another region, I am unaware of any 
ARIN policy that would be applicable to transferred number resources.
 
I hope this helps clarify matters.

Hi John,

It clarifies the intent, but to the best of my knowledge is an expression
of opinion rather than a formal statement of policy.  If we're going to
have a working transfer mechanism, given that there is a level of ambiguity
in the text in the ARIN transfer policy, it would be good if this could be
clarified formally so that we can remove any doubt.

Nick

 Thanks!
 /John
 
 John Curran
 President and CEO
 ARIN
 
 p.s.  Note also that the ARIN Policy Development Process (PDP) allows for 
   development of policies for administration of number resources 
   in the ARIN region (and IANA-applicable global number resource 
   policies per the ASO MOU); it is questionable if a policy proposal
   for administration of number resources in another regional registry
   would even be within the scope for the ARIN PDP...
 
 
 
 
 

Re: [address-policy-wg] APNIC temporarily freezing v4 transfers to RIPE NCC?

[Nick Hilliard]

Hi Scott,

On 11/03/2015 19:28, Scott Leibrand wrote:
 That was not the intent of the policy language as drafted.  Rather, than
 clause was meant to apply to 8.4 inter-RIR transfers inbound to the ARIN
 region from a source outside the ARIN region.  So if someone in the RIPE
 region decides for some reason to transfer resources to someone in the ARIN
 region, and the addresses end up registered in the ARIN database, then the
 recipient must sign an RSA and will be subject to current ARIN policies. 

Right, ok.

 This was *not* intended to apply to a transfer from the ARIN region to an
 organization in the RIPE region, where the addresses will end up registered
 in the RIPE NCC database.  So it shouldn't matter whether the recipient
 also has a presence in the ARIN region, or has an ARIN account. The actual
 recipient should be considered to be in the RIPE region (not the ARIN
 region) if the addresses are going to end up registered in the RIPE NCC
 database.
 
 ARIN staff can comment on their interpretation of the language, but
 hopefull it matches our original intent as summarized above.

It would be helpful if we had a clear statement of interpretation from
ARIN.  As it stands, the language is ambiguous enough to allow
misinterpretation of the original intent.

Nick

Re: [address-policy-wg] APNIC temporarily freezing v4 transfers to RIPE NCC?

[Nick Hilliard]

On 11/03/2015 09:38, Tore Anderson wrote:
 Indeed, that's how I understood Paul Wilson's mic comments after
 Andrea's APRICOT 2015 presentation, i.e., even though ARIN and APNIC
 transfer policies are compatible to begin with, the worry is that if
 transfers between the APNIC and RIPE regions commence without
 demonstrated need, than this fact would somehow «infect» the APNIC
 policy such that ARIN would no longer consider it to be sufficiently
 «needs based» and thus incompatible (even though the APNIC policy text
 would not change at all).

that is also my understanding - this should be fixed with the current
transfer proposal.  Although I found the statement from Einar Bohlin
(policy analyst at ARIN) disturbing:

 ARIN does not have policy regarding the relationship between RIPE and 
 APNIC.  So we don't have -- there is no policy text in our policy manual
 regarding that relationship.  There could be in the future but there is
 no such thing at this time.

The RIPE policy operates on the principal that once address space is
transferred in or out of a RIR, that for the duration of the transfer
(whether temporary or permanent), the receiving RIR policy applies and that
the sending RIR has no input on the resources.

Unfortunately, this is not respected in the ARIN inter-rir transfer policy:

https://www.arin.net/policy/nrpm.html#eight4

which includes the text:

Recipients within the ARIN region will be subject to current ARIN policies
and sign an RSA for the resources being received.

In other words, multinational organisations headquartered in the ARIN
region who receive resources transferred to another RIR will be subject to
ARIN policies.

This is potentially a serious problem because transferring policy
encumbrances is likely to cause policy problems in future, if RIR policy
differences crop up.

So the question is: can the RIPE NCC accept transfers from ARIN if the
receiver organisation has signed the ARIN RSA for these resources?  And if
transfers are accepted within these terms and there's a conflict between
RIPE NCC policy and ARIN policy, whose policies takes precedence?  RIPE's
or ARIN's?

Nick