forked from randyqx/RIPE-2017-03
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy path2017-3.txt
197 lines (136 loc) · 7.63 KB
/
2017-3.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
Number: 2017-03
Policy Proposal Name:
Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space
for newcomers
Authors: Randy Bush / [email protected] / IIJ
Anna Wilson / [email protected] / HEAnet
Carlos Friacas / [email protected] / FCT|FCCN
Proposal Version: 1.0
Submission Date: TBA
Suggested WG for Discussion and Publication: Address Policy
Proposal Type: Modify
Policy Term: Permanent
Summary of Proposal:
--------------------
Adoption of IPv6 has been slower than desired; therefore, IPv6/IPv4
inter-operation will be with us for a long time. This policy proposal
aims to extend the RIPE NCC's ability to provide a minimum of IPv4 space
to newcomers (hopefully for another decade, at least) to allow use of
transition mechanisms. The current consumption rate can be slowed by
changing the initial IPv4 Allocation size from a /22 to a /24 (or even
further), and not allowing a subsequent IPv4 allocation. If the minimum
globally routable acceptable prefix changes from /24 to a smaller
prefix, the initial IPv4 Allocation should also change to
match. Historically, at a given point in time, the minimum allocation
size (and hence the minimum routing block) was a /19 [see RFC2050], and
this has evolved to the current size of 256 addresses (/24). While
changing the initial and only IPv4 Allocation in the RIPE NCC service
region to a /24 should be the primary goal. The authors anticipate it is
possible to agree on an even smaller initial size, if global agreement
on routing prefixes longer than a /24 is achieved. In that regard, some
research should be performed, in order to test global reachability for
prefixes longer than a /24.
Policy Text:
------------
a. Current Policy text (ripe-680):
5.1 Allocations made by the RIPE NCC to LIRs
Details of how to join the RIPE NCC can be found in the RIPE Document
"Procedure for Becoming a Member of the RIPE NCC".
On application for IPv4 resources LIRs will receive IPv4 addresses
according to the following:
The size of the allocation made will be exactly one /22.
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).
The LIR must confirm it will make assignment(s) from the allocation.
In case an allocation of a single /22 as per clause 1 can no longer be
made, multiple allocations up to an equivalent of a /22 in address space
will be made to fulfill a request.
b. New Policy text (ripe-680):
5.1 Allocations made by the RIPE NCC to LIRs
Details of how to join the RIPE NCC can be found in the RIPE Document
"Procedure for Becoming a Member of the RIPE NCC".
On application for IPv4 resources LIRs will receive IPv4 addresses
according to the following:
The size of the allocation made will be exactly one /24.
The sum of all allocations made to a single LIR by the RIPE NCC is limited
to a maximum of 256 IPv4 addresses (a single /24).
The LIR must confirm it will make assignment(s) from the allocation.
In case an allocation of a single /24 as per clause 1 can no longer be
made, no allocation is to be made. If the minimum allocation size can't be
changed into a smaller size by a future policy proposal, full IPv4 run-out
in the service region should be declared by the RIPE NCC.
Rationale:
----------
The NCC's total run-out of IPv4 addresses is seen as an abrogation of
responsibility, and any measures that can be taken to postpone that point
in time should be seen as critical. By extending the availability of IPv4
addresses to newcomers, the community shows goodwill towards competition
laws & regulations. The global internet is going to be dual-stack for
another decade or two.
An enterprise, ISP or public/governmental organization will not be able to
run without some IPv4 space and some IPv6 space. Pure IPv6 (i.e. IPv6-only)
is not going to be tenable for a long while. Our goal is to keep providing
newcomers with as little IPv4 space as possible and as much use of IPv6
space as possible.
The rationale here is that an organization can operate with a minimal set
of IPv4 out front and NAT64 or other transition technology so they can use
IPv6 internally. If they can't get that bit of IPv4, they simply can't
run on the actual internet of the next decade or two.
There have been experiments about using routing prefixes longer than /24.
In the future large ISPs/Carriers could agree to route prefixes longer than
/24 if they are inside well defined ranges that are easily identifiable and
integrated into ACL automation.
a. Arguments Supporting the Proposal
A /24 prefix is more than enough as a minimum foothold on the IPv4 Internet
for emerging companies almost locked-in into an IPv6 world.
As long as the prefix is globally routable, the allocation can be fully or
partially used for IPv4/IPv6 translation mechanisms.
Reducing the initial/only allocation from /22 to /24 will extend the
time frame during which new companies can obtain some IPv4 address space in
the NCC's service region without the need to trade for address space (at
least during their initial setup).
Opening multiple LIR accounts will be less attractive if this policy is
approved -- because each new LIR would get less IPv4 space for the same
amount of money. Thus, decreasing of the free IPv4 available pool is likely
to slow down.
According to the RIPE NCC there are already around 30 Allocations with size
between a /25 and a /29.
b. Arguments Opposing the Proposal
* Extending the full IPv4 run-out date on the RIPE NCC's service region can be
seen as a way to delay IPv6 deployment.
Mitigation/counter-argument: The aim has not changed since the first
iteration of the last /8 policy; networks require a little IPv4 to use IPv6,
and the purpose of the policy has always been to provide that space so that
IPv6 transition can be facilitated. All that has changed since that
consensus is that we now have more data on the rate of consumption.
* For each /22 (currently allocated), one prefix will only be added to the
global routing system.
Mitigation/counter-argument: this is mostly inaccurate, as any /22 owner can
effectively announce/generate four /24s and many do Fragmentation is
ultimately limited not by the size of a RIR allocation, but by global
agreement on routable prefixes.
* LIRs get less addresses in return for their yearly membership fee. It can
be argued that the adoption of this policy will create unfairness between
newcomers and organizations that became a LIR during the current application
of the last /8 policy.
Mitigation/counter-argument: Older LIRs also received more IPv4 address
space from the RIPE/NCC according to existing rules. Enabling more newcomers
to receive IPv4 address space seems to clearly supersede in importance any
possible sense of unfairness.
* The number of RIPE NCC members will grow even more.
Mitigation/counter-argument: While the management of more members can have
an impact on RIPE NCC, experience drawn from recent years' membership
growth tells us this can be smoothly handled. On the economics side, it will
bring more revenue, and it is easy to foresee lower yearly membership fees
(or larger yearly rebates).
c. Alignment with other RIRs:
* ARIN:
Within ARIN's number resource policy manual (version 2017.4 - 8 August 2017)
ARIN has a dedicated IPv4 block to facilitate IPv6 deployment on 4.10.
(ref: https://www.arin.net/policy/nrpm.html#four10)
* LACNIC:
2017-4 proposal (Modify the minimum size of initial allocations to ISPs) was
ratified on the 16th August, changing the initial allocation size from a /22
to a /24.
(ref: https://politicas.lacnic.net/politicas/detail/id/LAC-2017-4?language=en)