Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] Summary of proposals: IPv4 Runout Management

Omo Oaiya Omo.Oaiya at
Thu Nov 10 01:20:02 UTC 2016

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

> On Nov 8, 2016, at 09:11 , Omo Oaiya <Omo.Oaiya at> wrote:
> On 7 November 2016 at 18:41, Owen DeLong <owen at> 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 -
> 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? -

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the RPD mailing list