On 20-sep-2007, at 21:10, Stephen Sprunk wrote:
First of all, litigation isn't the only way to get something
done, and second, do don't know that until you try.
If you try to revoke someone's /8 or /16, you can bet that they're
going to sue you.
So? The RIRs and ICANN have deep pockets.
But there are other approaches than simply revoking the address
space. For instance, setting up a policy that governs who gets to
keep legacy space that takes into consideration various types of use
and cost of renumbering makes sense. I'm sure some legacy space is
used in a way that's fairly reasonable, while other space isn't used
at all.
Obviously the elephant in the room is the US government that has
about 5% of all address space, which seems excessive even for legacy
holders.
And, for the record, there are over 50,000 of them, not less than
50.
Clarification: 31,386 in ARIN's region. I haven't seen stats for
the other RIRs.
50000 organizations holding nearly 0.5% of the IPv4 space each?
I'm impressed! With that kind of address compression technology
we don't need IPv6 after all.
I'm sure you're aware that different size assignments were made to
different organizations.
I was specifically talking about the /8s, where you get a decent bang
for your reclaiming effort buck. But even that isn't enough anymore
to bother at this point...
Even if true, that point is past. Based on current projections, it
is unlikely we'd be able to recover _any_ /8s before exhaustion
hits due to the protracted litigation that would ensue, and even if
we did manage to get some of them back (which isn't guaranteed, and
would cost millions of dollars in any case),
What would that be, $0.25 per address? Big deal.
IPv6 still won't be deployed and usable in any meaningful way
unless we make more progress in the next two years than we have in
the last ten.
Progress in various aspects of IPv6 has been slow because it didn't
need to be faster. I see no solvable issues with IPv6 deployment that
can't be solved in those 2 years. (No, we still won't have routing
that will take us to the next century by then, but I suggest we don't
wait for that.)
Same thing for repurposing 240/4, by the way.
Decade problem. Come back and discuss that when Windows recognizes
that block as normal unicast addresses by default.
If we had done this two years ago it could have been in Vista and in
an XP update, so the space would have been usable by 2010 or so when
the older Windows versions and other implementations that don't
accept these addresses would have had the time to be updated manually
or replaced.
Maybe the RIRs have
contracts with all new PI holders, but that doesn't automatically
give ARIN the authority to reclaim address space after a policy
change.
Again, I don't know about all RIRs, but that is _explicitly called
out_ in ARIN's Registration Services Agreement
RIRs would still have to show that it's a reasonable thing to do. I'm
still not a lawyer, but I could easily come up with several arguments
why I should be able to keep my addresses despite any contracts.
and AFAIK has been since day one.
I have never heard of a case where an otherwise legitimate
organization (i.e., not a front for a spam outfit or some such) used
address space in a way that wasn't abusive or criminal, but didn't
comply with RIR policies and got those revoked.
As a non-lawyer, I would judge the chances in court for
reclaiming IPv4 /8s higher than those for reclaiming IPv6 PI
space: in the first case, it's the benefit the continued operation
of the IPv4 internet, in the latter case, it's going to look highly
arbitrary.
I'd suggest you review the comments by ARIN's counsel at the last
meeting WRT revoking legacy assignments. It's more complicated
than it appears at first glance, particularly to someone not used
to our legal system.
Isn't everything?
The opinions of one lawyer aren't worth much. As a profession, they
lose 50% of all their cases, so obviously they must be wrong 50% of
the time. (Not sure if engineers do better, though.)
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf