This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] 2013-03: Summary of amendments for version 3.0
- Previous message (by thread): [address-policy-wg] 2013-03 Review Period extended until 14 August (No Need - Post-Depletion Reality Adjustment and Cleanup)
- Next message (by thread): [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Tore Anderson
tore at fud.no
Wed Aug 7 15:24:05 CEST 2013
Hi APWG,
As you all know, during the Review phase a couple of potentially
problematic issues in the proposal was brought up, which I've offered to
improve on by amending the proposal. I want to detail the individual
amendments and how they impact the proposal, so that you can all review
them before we send the new version of the proposal back to the NCC.
I welcome your opinions on the amendments, but please also realise it is
not an invitation to bikeshedding - I'm trying to find a middle ground
the WG will find acceptable, not necessarily perfect. In doing so I hope
that we can ensure that we won't be sending Emilio off on a wild goose
chase when we ask him to create a new Impact Analysis - so if you are
completely unable to live with any of this, then do speak now or forever
hold your peace.
I'd like to especially thank Filiz Yilmaz and Malcom Hutty for
highlighting and elaborating on the issues that resulted in the first
two amendments, and to Andrea, Emilio, and Marco from the NCC for
collaborating with me on writing the texts of the last two amendments and
confirming that there will be no misunderstandings as to their intent
and interpretation.
Amendment 1: Retain "Fairness" goal
===================================
This amendment retains our community's overall philosophical and moral
goal of fair distribution of IPv4 address space to end users operating
networks. Our current IPv4 policy lumps together a "Fairness" and a
"Conservation" goal (unlike our IPv6 policy, which separates the two).
Seeking only to remove the latter, the current version of 2013-03
accidentally removed the former as well.
The amendment makes no attempt to define what constitutes "fair
distribution" in our current environment of scarcity - this will remain
a value judgement each LIR has to make for themselves, just like it is
today.
The benefits of this amendment include:
* Avoids throwing the baby out with the bathwater.
* Guides LIRs to assign address space to end users who are operating
networks, as well as to base any value judgement they would need to make
related to this on their own notion of fairness.
* Ensures that we keep the door open for a potential future discussion
on how to define and possibly enforce fair distribution in an
environment of scarcity.
* Provides "ammunition" for the NCC in their talks and interactions with
critical governments, regulators, or similar entities.
The exact amendment, which is to be inserted into section 3.0 of the
proposed policy, reads:
«Fairness: Public IPv4 address space must be fairly distributed to
the End Users operating networks.»
Note that except for the title, this is the exact same phrase as is
found in our current policy. This is fully intentional, as 2013-03 has
no ambition to alter previously agreed upon consensus in this regard. I
chose the title "Fairness" to match the one used in the IPv6 policy
document (ripe-589).
Amendment 2: Retain "Need" for final /22 allocations
====================================================
This amendment retains the current practice of requiring the LIRs that
seek to obtain their final /22 from the austerity ("last /8") allocation
pool to use it for making assignments to their end users or their own
infrastructure.
This is not in conflict with 2013-03's "No Need" moniker, as changing
the "last /8 policy" is not its ambition. That the current version of
the proposal does so was only due to a layer of indirection, in which
the "last /8" policy made a reference to the "old policy" which 2013-03
did remove as part of its overall clean-up efforts.
In practical terms, the amendment will result in a "check box" or a
"yes/no" question in the allocation request form, where LIRs would
be required to declare this to be their intent in order to receive the
allocation. This interpretation has been confirmed by the NCC.
The benefits of this amendment include:
* Ensures our RIR-to-LIR allocation policy remains pursuant to the
"Fairness" goal described in amendment 1.
* Avoids any confusion leading to an impression that 2013-03 would make
the RIPE NCC start to "sell IPv4 addresses". This in turn leads to the
following benefits:
-- Alleviates concerns that the RIPE NCC may lose its status as a
non-profit membership association with the Dutch tax authorities,
-- Shields the NCC from some of the legal concerns and impacts noted in
the current Impact Analysis' EU Competition Law report,
-- Provides "ammunition for the NCC in their talks and interactions with
critical governments, regulators, or similar entities.
* Ensures the proposed policy remains as much in line with RFC 2050bis'
Allocation Pool Management goal as our current policy is.
* Prevents LIRs from obtaining their last /22 for other purposes than
"networking"; in particular re-sale, stockpiling, or hoarding.
This amendment reads as follows, and is to be inserted as a new bullet
point in the proposed policy's section 5.1:
«The LIR must confirm it will make assignment(s) from the allocation»
Amendment 3: Clarify criteria for IXP assignment expansions
===========================================================
The NCC noted in its Impact Analysis for the current version of the
proposal that the precise criteria for when an IXP may request an
expansion of its peering LAN assignment from "last /8 IXP assignments"
was lost and thus left undefined. This was unintentional and happened
due to the exact same "layer of indirection" problem described above.
As 2013-03 has no ambition to change the "last /8 policy", including the
parts specific to IXPs, and the proposed amendment seeks only to
document and uphold the status quo. The argument in favour of this
amendment is of course to ensure we continue to provide the NCC and its
hostmasters with clear guidance on how our policies should be implemented.
The amendment will be inserted into section 6.1, replacing the fourth
bullet point, and reads as follows:
«New IXPs will be assigned a /24. Should they require a larger
assignment, they must return their current assignment (or existing PI
used as an IXP peering LAN) and receive a replacement /23 or /22. After
one year the utilisation of the new assignment must be at least 50%,
unless special circumstances are defined»
The RIPE NCC has confirmed that this text accurately describes today's
practice, and that it will merely uphold the current status quo.
The amendments are also attached in unified diff format.
Best regards,
Tore Anderson
-------------- next part --------------
--- 2013-03-v2.txt 2013-08-06 21:25:31.425520553 +0200
+++ 2013-03-v3pre.txt 2013-08-07 15:15:44.614150212 +0200
@@ -127,7 +127,9 @@
2. Aggregation: Distributing IPv4 addresses in an hierarchical manner
permits the aggregation of routing information. This helps to ensure
proper operation of Internet routing.
- 3. Registration: The provision of a public registry documenting address
+ 3. Fairness: Public IPv4 address space must be fairly distributed to
+ the End Users operating networks.
+ 4. Registration: The provision of a public registry documenting address
space allocations and assignments must exist. This is necessary to
ensure uniqueness and to provide information for Internet
troubleshooting at all levels.
@@ -178,7 +180,8 @@
2. The sum of all allocations made to a single LIR by the RIPE NCC after
the 14th of September 2012 is limited to a maximum of 1024 IPv4
addresses (a single /22 or the equivalent thereof).
- 3. Allocations will only be made to LIRs if they have already received an
+ 3. The LIR must confirm it will make assignment(s) from the allocation.
+ 4. Allocations will only be made to LIRs if they have already received an
IPv6 allocation from an upstream LIR or the RIPE NCC.
@@ -313,9 +316,11 @@
* IXPs holding other PI IPv4 space for their peering LAN (i.e. they are
seeking a larger assignment), must return their old peering LAN
resources back to this pool within 180 days of assignment.
- * New IXPs will be assigned a /24. IXPs may return this /24 (or existing
- PI used as an IXP peering LAN) should they run out of space and
- receive a larger (/23, or /22 if utilisation requires) assignment.
+ * New IXPs will be assigned a /24. Should they require a larger
+ assignment, they must return their current assignment (or existing PI
+ used as an IXP peering LAN) and receive a replacement /23 or /22. After
+ one year the utilisation of the new assignment must be at least 50%,
+ unless special circumstances are defined.
* IP space returned by IXPs will be added to the reserved pool
maintained for IXP use.
* Assignments will only be made to IXPs who have already applied for, or
- Previous message (by thread): [address-policy-wg] 2013-03 Review Period extended until 14 August (No Need - Post-Depletion Reality Adjustment and Cleanup)
- Next message (by thread): [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]