[156526] in North American Network Operators' Group
Re: The Department of Work and Pensions, UK has an entire /8
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Wed Sep 19 08:35:56 2012
Date: Wed, 19 Sep 2012 05:35:22 -0700
From: Leo Bicknell <bicknell@ufp.org>
To: NANOG list <nanog@nanog.org>
Mail-Followup-To: NANOG list <nanog@nanog.org>
In-Reply-To: <CAN3um4zGsbRL9K2snL0N6qDgP7RU_4dw_z1F0RQ3bnbr1H8eDA@mail.gmail.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--BOKacYhQ+x31HxR3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In a message written on Tue, Sep 18, 2012 at 09:11:50PM -0700, Mike Hale wr=
ote:
> I'd love to hear the reasoning for this. Why would it be bad policy
> to force companies to use the resources they are assigned or give them
> back to the general pool?
While I personally think ARIN should do more to flush out addresses
that are actually _not in use at all_, the danger here is very
clear.
Forcing the return of address space that is in use but not in the
"global default free routing table" is making a value judgement
about the use of that address space. Basically it is the community
saying that using public address space for private, but possibly
interconnected networks is not a worthy use of the space.
For a few years the community tried to force name based virtual
hosting on the hosting industry, rather than burning one IP address
per host. That also was a value judegment that turned out to not
be so practical, as people use more than plain HTTP in the hosting
world.
The sippery slope argument is where does this hunt for "underutilized"
space stop? Disconnected networks are bad? Name based hosting is
required? Carrier grade NAT is required for end user networks?
More importantly are the RIR's set up to make these value judgements
about the usage as they get more and more subjective?
There's also a ROI problem. People smarter than I have done the
math, and figured out that if X% of the address space can be reclaimed
via these efforts, that gains Y years of address space. Turns out
Y is pretty darn small no matter how agressive the search for
underutilized space. Basically the RIR's would have to spin up
more staff and, well, harass pretty much every IP holder for a
couple of years just to delay the transition to IPv6 by a couple
of years. In the short term moving the date a couple of years may
seem like a win, but in the long term its really insignificant.
It's also important to note that RIR's are paid for by the users,
the ramp up in staff and legal costs of such and effort falls back
on the community. Is delaying IPv6 adoption worth having RIR fees
double?
If the policy to get companies to look at and return such resources
had been investigated 10-15 years ago it might have been something
that could have been done in a reasonable way with some positive
results. It wasn't though, and rushing that effort now just doesn't
make a meaningful difference in the IPv4->IPv6 transition, particularly
given the pain of a rushed implementation.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--BOKacYhQ+x31HxR3
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iQIVAwUBUFm8CrN3O8aJIdTMAQJnmhAAqEmzyky86j3lRn04X2dAexcziMocdjfU
BPdVpOeI1B1TSzX+0ulbDQFZzMvLol7AzKPnxmuZZyf38cVG6EJKZDpPeSzGvrLf
XOcN6Y+N2+UX3TYmGY2FPT36vZYYIB08F7UbewRJE4nx/PEVwwSoijkeDCfhr7gm
YChVQ5/hU0N0w7QhCcYGnFpAT+wNyt95TjN/yf+1IgGGTfmmUbtutxdqqyWkehAL
IVkCvbG7se59u6o3t500HxxlE1PA+R0vNabzpST0LY+82mYMhF6lVlqQf4zv9Kz5
yDl7jQ+mJisSv/mEIStqzaCF1K0Z/46h2XnOF7+SGiekNzfvx7h/V4YA6fLzoNmT
0MW9TR6MK1UlBMwixpjGHDk8vzc0dsWUnOL92fQSVrYDEGVLCu/MP0CG5Ost5Z5+
DrgJDRUDfyz0geSJfx0kmNDT5PDdGh2DlSzJMTabnSqBJIOFAPW3CS95auXRo4lt
Xpb4peQncPUBvEhx6xl/qBKLFpmNL7Z/nmhiNr5dJ8N1BZh/hu+EAL2/Ld/VZ0tY
gGntkG0FXjp/R46QGz/tLfpCGVc+Y4HIeAoZhWITale21KnMIJVyps2eWr7qdvxj
EhRLhSdetwLDrUIi3ZQhmLLYn2UIX1IFa5lyrahWx0MGuTCzlJIZkR8KpX0d8j09
MlSmG+nwx0U=
=6a+c
-----END PGP SIGNATURE-----
--BOKacYhQ+x31HxR3--
