[anti-abuse-wg] Bye Bye (was: Re: The Rules)

Hi,

On Thu, Jun 27, 2013 at 02:50:16PM -0700, Ronald F. Guilmette wrote:
> >On Thu, Jun 27, 2013 at 12:58:32PM -0700, Ronald F. Guilmette wrote:
> >> In message <20130627111402.GZ2706 at Space.Net>,=20
> >> Gert Doering <gert at space.net> wrote:
> >> >If you *are* a LIR, and as that LIR have received a /21, the NCC will try
> >> >to ensure that whatever you registered is OK
> >>
> >> Please definie the meaning of "OK" in this context.
> >
> >Technically OK, as in "no overlaps in the network objects", policy-wise
> >OK, as in "no assignments bigger than permitted by your assignment window",
> >and sometimes they ask for the justification documents for a given
> >assignment, aka "the form that needs to be filled in".
> 
> Sometimes??  Why not all the time?

Well, maybe the wording was not so good.  I think they will always pick
"some of the assignments" to look at the paperwork, but for reasons of
scale, they are not asking for the paperwork for *all* your assignments
(because that could be multiple thousand for a medium-sized business ISP).

> >> So, if I am understanding you correctly, if, say, a given LIR obtained,
> >> say, a /17 two years ago, and then just sat on it, and never put a
> >> single thing in it in all that time, there is nothing that can or will
> >> be done about that colossal waste of (supposedly) precious IPv4 space.
> >> Is that correct?  Have I understood you correctly?
> >
> >Yes.
> 
> Am I really the only person on the planet who thinks this is absurd?

There seem to be a few, and we covered that topic in the address policy
WG two meetings ago.  The outcome was that "well, it's not in the policy
documents, so the NCC has no lever to ever ask for return of space on
the basis of it not being used" - which is understandably as these documents
have been written under the assumption that ISPs grow, fill their space,
ask for more, fill that, and ask for more again (and *that* is covered in
great detail).

This outcome was presented, and the WG didn't see the need to change the
policy here - acknowledging, I'd say, the fact that it would cause lots
of effort for minimal gain.

> >(Though I disagree with you on the preciousness of IPv4 space.
> 
> Fine.  I am an authorized Wikipedia Editor.  Please provide me with some
> new correct verbage to replace the following utterly innacurate section
> of the relevant Wikipedia page:
> 
>     http://en.wikipedia.org/wiki/IPv4_address_exhaustion
> 
> 	"On 31 January 2011, IANA announced it had exhausted its free pool
> 	of IPv4 addresses (from which IP blocks were allocated to regional
> 	RIRs), the exhaustion of the RIRs APNIC on 15 April 2011 and
> 	RIPE NCC on 14 September 2012..."
>         ^^^^^^^^
> 
> I suppose that the word "exhaustion" has a different meaning depending
> upon one's own individual situation.  Certainly, if you are one of the
> luck few who had the foresight to start hording and to squirrel away
> a whole lot of IPv4 space some time ago, then right now I am sure that
> you are sitting pretty, and saying to yourself "Shortage?  What shortage?"
> 
> Other people (and companis) may perhaps not have had the same level of
> foresight.

No, you're misunderstanding me.  Whatever we do, 4 billion IPv4 addresses 
will not be sufficient to number Internet access for 6+ billion humans 
on earth.  So it's important to get over the fact that IPv4 is *gone* 
and move ahead to the only alternative we have: IPv6.

Spending lots of resources to stretch IPv4 for a few more months will
mainly achieve a larger installed basis of IPv4-only gear that will then
cause *more* effort converting towards IPv6 - and based on that, the RIPE
community decided (the topic came up multiple times, and the outcome was
always the same) to not invest lots of NCC time = member money in IPv4
reclaim activities.


[..]
> So since that is all true, let's do this... Let's resolve to give away any
> and all remaining IPv4 space to crooks, thieves, and homeless people until
> it really and truly is all gone.  That will force everyone to buy all new
> IPv6 equipment, which will be good for the economy in Europe, and maybe even
> bring it out of its current slump.

Whoever in the RIPE region comes up, unless they are a convicted criminal,
will get a single last /22 for their LIR.  This is expected to last for 
a few more years to give new entrants in the market the chance to have a
few IPv4 addresses to run their NAT64 gear on.  (But I told you that 
already).

> >> And likewise, if said hypothetical LIR obtained the same hypothetical /17
> >> two years ago, and since that time has allocated it to a "customer" who
> >> then proceeded to fill it only with a single physical machine and on
> >> the order of 32,000 utterly phony baloney domain names, either for the
> >> purpose of snowshoe spamming or for the purpose of so-called "blackhat
> >> SEO", then there is nothing that anybody within RIPE, or within RIPE NCC,
> >> or anywhere in all the world either may or will do about that.  Is that
> >> a correct interpretation of what you have said?
> >
> >Yes.
> 
> So basically, the idea that I had of having these kinds of cooks "audited"
> is utterly futile and pointless, yes?

The audit will ensure that the contact data the NCC has is right (so we
know who they are), that the company registration data is right (so we can
sue them, if needed), but it does not ensure that the holder will use their
IP addresses in a way that doesn't offend anyone, right.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 306 bytes
Desc: not available
URL: <https://lists.ripe.net/ripe/mail/archives/anti-abuse-wg/attachments/20130628/5abd11bb/attachment.sig>