Return the 172.16.0.0/16 block to the registry (ARIN, APNIC, RIPE or if
no one else IANA) and apply for multiple appropriately sized CIDR blocks
under the current registry allocation guidelines.
==>Return the 172.16.0.0/16 block to the registry (ARIN, APNIC, RIPE or if
==>no one else IANA) and apply for multiple appropriately sized CIDR blocks
==>under the current registry allocation guidelines.
While I fully agree with this approach to deal with the issues mentioned,
it will only exhaust the new address space more quickly. Why should we
give up on 128/2?
/cah
Return the 172.16.0.0/16 block to the registry (ARIN, APNIC, RIPE or if
no one else IANA) and apply for multiple appropriately sized CIDR blocks
under the current registry allocation guidelines.While I fully agree with this approach to deal with the issues mentioned,
it will only exhaust the new address space more quickly. Why should we
give up on 128/2?
because when the registries have different allocation policies in 128/2,
the isps will follow. just as we did in old A space.
randy
==>
==>>> Return the 172.16.0.0/16 block to the registry (ARIN, APNIC, RIPE or if
==>>> no one else IANA) and apply for multiple appropriately sized CIDR blocks
==>>> under the current registry allocation guidelines.
==>> While I fully agree with this approach to deal with the issues mentioned,
==>> it will only exhaust the new address space more quickly. Why should we
==>> give up on 128/2?
==>
==>because when the registries have different allocation policies in 128/2,
==>the isps will follow. just as we did in old A space.
That doesn't address the point -- the point is that these ISP's are forcing
the exchange of these blocks for new, previously unallocated space, and
leaving holes in the old 128/2 space. These ISP's are massively
contributing to the depletion of immediately available address space.
Why not adopt a reasonable policy to accept up to /20's or up to /19's in
the old B space so that organizations who already have these blocks can
use them?
/cah