[rpd] Summary of proposals: IPv4 Runout Management

[Omo Oaiya]

On 8 November 2016 at 23:40, Owen DeLong <owen at delong.com> wrote:

>
> On Nov 8, 2016, at 09:11 , Omo Oaiya <Omo.Oaiya at wacren.net> wrote:
>
>
> On 7 November 2016 at 18:41, Owen DeLong <owen at delong.com> wrote:
>
>>
>> Any technology which would need this “strategic reserve” is a technology
>> which does not exist yet. From my perspective, the only thing such a
>> provision can do is encourage such technologies to be developed with
>> dependencies on IPv4. This is absolutely wrong-headed.
>>
>
> some future requirement which creates a demand for IPv4 addresses need not
> have anything to do with technology.
>
>
> Please provide an example of something which could create an unforeseen
> demand for IPv4 addresses which has nothing to do with a new use for IPv4
> addresses.
>

How do you explain the secondary market in ARIN region?   A new use for
IPv4 addresses?

The point is to cater for unanticipated use.  Nothing stops us from
repurposing or discarding if not needed but to presume the future is unwise.



>
>
> Otherwise we should consider recalling the equivalent of  34.36 /8
> unadvertised held in ARIN region and make them unusable -
> http://bgp.potaroo.net/iso3166/v4cc.html
>
>
> You are engaging in a logical fallacy here in that you appear to believe
> that unadvertised == unutilized and this simply is NOT the case.
>
> While those addresses are not being advertised on the global internet, it
> is not at all unlikely that they are being utilized in production networks
> that are attached to networks that are advertised to the internet and/or
> otherwise need global uniqueness.
>


ah ha!   We have been teaching the fact that unadvertised  does not mean
unutilised in this community, but keep getting :

 sh ip bgp a.b.c.0/22 lo
%Network not in table

sh bgp ipv6 2001:43f8:XXXX::/48
% Network not in table

And that allocations utilisation reviews can only be done through global
routing table



> and wouldn't need to have the majority of draft policies discussed in the
> ARIN meeting about how to make IPv4 transfers easier.
>
>
> I think this is untrue.
>

Which bit is untrue?  That the majority of the draft policies in the last
ARIN public meeting was about making IPv4 easier to get? -
https://www.arin.net/vault/participate/meetings/reports/ARIN_38/ppm.html



> First, recalling those addresses would actually be quite difficult merely
> from a legal and tactical perspective. Second, even if we were able to
> recall the ones that are not in use, it’s likely less than 10% of that
> amount that would become available.
>

> I’m not sure if 3.44 /8s would even satisfy the current ARIN waiting list.
>


Read again.  34.36 /8 not 3.44 /8s i.e  over 576 million IPv4 addresses
unadvertised in the ARIN region


> We should be encouraging new technologies to be developed WITHOUT
>> dependencies on IPv4 and with full IPv6 support from day 1.
>>
>
> Agreed and we shall.  The IAB statement on this was posted in the
> community list.  They appreciate the need for dual-stack and time reviews
> take.  We have to remember that we are only talking of 1 /8 here.
>
>
> No, we are talking of a /12 under current policy, a /13 under Alain’s
> proposal and nothing at all under Andrew’s proposal.
>

We are talking about the last /8 in the softlanding policy i.e all the
addresses we are dicing and slicing total just about 16 million addresses.


> I favor nothing at all as the time for protecting people from failing to
> deploy IPv6 should be considered past at this point.
>

We should be empowering them to deploy IPv6 and not depriving them of the
IPv4 they need to do this.


> If you couldn’t figure it out in the 25 years of warning that you had or
> in the nearly 3 years since IANA ran out of space, than really, I think
> that the community’s obligations to protect your future developments from
> early obsolescence are past at this point.
>

We also need to ensure that the African community can participate without
being forced to acquire resources they need from prohibitive transfer
markets.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20161110/75957f8f/attachment.html>