[ppml] NANOG IPv4 Exhaustion BoFRe: NANOG IPv4 Exhaustion BoF
Leo Bicknell
bicknell at ufp.org
Fri Mar 7 13:34:56 EST 2008
In a message written on Fri, Mar 07, 2008 at 12:42:23PM -0500, Joe Maimon wrote:
> Why wouldnt you receive a LOA as part of your black market transaction?
You may, but that system rapidly breaks down.
I think if you ask the people where the rubber meets the road today's
system is cumbersome at best. And it's a system based around a series
of assumptions:
1) The supernet is held by the granting entity for the duration of the
subnet's existance.
That is, I can look up the parent, call them, and verify the LOA is
good.
2) The granting entity is willing to verify the LOA.
People do call and check them. People who get a "UUNet" LOA call
"VerzionBusiness" and ask if it's still valid. Someone has to make,
and take the calls.
The first criteria is easily violated when an entire block is
transferred. Now it's just a block with the wrong name on it.
Transfer it twice and the entity on the record can't verify the
transaction history at all, someone would have to walk through it
step by step.
The second criteria is easily violated by multiple transfers. Party
A transferrs a /16 to Party B, Party B then turns it into /24's to
Parties C-M. Party F shows up at an ISP who looks in whois and
calls party A. They can't verify, and probably do not want to
handle the call volume for C-M. They may refuse to answer as a
result.
There's some hope certificates could make this all easier. On the
one hand I think they could; all of the cases I've described could
be easily captured in certificates.
However, when it goes wrong, it really goes wrong. Consider when
Provider A goes chaper 11, and is bought by Provider B. What are
the chances party B gets the key, and the secret phrase to unlock
it? What are the chances they have enough history to sign things
with the new Provider A key? Who's going to take the time to do
all that work?
In a really bad scenario you have an entire subtree of the space
that is certified, certified wrong.
Could these problems be solved? I think so. There are ways to mitigate
all of these concerns. Can they be solved in time to save IPv4? I
don't think so. Time to look towards IPv6.
--
Leo Bicknell - bicknell at ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080307/75ed21d1/attachment.sig>
More information about the ARIN-PPML
mailing list