[arin-ppml] ARIN Multiple Discrete Networks Policy

John Curran jcurran at arin.net
Tue Oct 4 10:08:26 EDT 2011

On Oct 4, 2011, at 9:33 AM, Jeff Wheeler wrote:
>> (Re: authentication, see last's weeks IRR upgrade announcement:
>> https://www.arin.net/announcements/2011/20110929.html)
> It seems that integration with the ARIN web site / registration
> systems, as I believe was your goal earlier this year, did not happen?
> I think that was a perfectly good idea, but obviously you have
> addressed the security concerns I raised, which is a prerequisite to
> anything more useful.

We have to pace our development efforts, and provide incremental 
improvements in multiple areas at once (ARIN Online registration
capabilities, Online billing support, RESTful enhancements, IRR
improvements, RPKI development, etc.)  We haven't given up on 
further ARIN Online/IRR integration, but need to prioritize the
work and sometimes this means doing things next year to keep this
year's expenses within plan.

> This is certainly true, but you would be surprised how common it is
> for inexperienced operators to leak a bunch of /24s from their new RIR
> allocation simply by mistake.  Many North American networks do not use
> an IRR or rely on their ISP to guess at their intent and create "proxy
> objects," which is why the various IRRs in common use by ARIN-region
> networks are such a mess.  It is a contributor to DFZ bloat.
> If an operator really wants to inject a route to the DFZ, I don't
> think I want ARIN to be in the business of stopping them.  I would
> like ARIN to be in the business of making it easy for transit networks
> to differentiate between intent and accidents.

Makes sense (and was very clearly stated - thanks)

>> If folks want to tie address policy more tightly to declared routing
>> policy, that can be done.  Again, this is not something for ARIN to
>> do without clear community direction in this area.
> I really think it's too late for this to really be fixed where IPv4 is
> concerned, but IPv6 DFZ is "fixable" because it isn't too bad yet, and
> there is plenty of time to institute sensible policies, and for ARIN
> to provide operators with useful tools, like an IRR that is easier to
> use (now that it's secure.)
>>> I believe in the future, the ARIN membership will realize that we need
>>> it to police routing table bloat, or the v4 tables we have today will
>>> look small and orderly by comparison.
>> I highly suggest discussion of these ideas on this mailing list or in person
>> at Philly (both in the hallways and at the open microphone session). ARIN
>> is your organization, and to the extent the membership supports this as a
>> direction, it will happen.
> It may be time to revisit some old lessons that many of us take for
> granted.  I received an off-list mail in response to this thread from
> an operator asking how he could clean up his advertisements.  He has
> common transit at many or all of his locations, and was apparently not
> aware that he could use no-export functionality to avoid injecting his
> de-aggregates to the DFZ.  The reality is that there are thousands of
> networks being run by inexperienced people who may clean up their
> advertisements if they are simply shown how.  The person asked if I
> had any links to presentations or documentation that would provide him
> guidance, and I am sorry to say that I had none, and simply suggested
> some options to him by email.  It's understandable that he was not
> aware of how he could do this better.

There's a group called NANOG, and I'm certain that there's got to be 
at least a few presentations in their archives that would help...
Neither ARIN nor NANOG do extensive outreach to the new network 
operator community; i.e. we occasionally have sessions or training
which addresses such, but don't run a formal "how to get started" 
program or a help resource with the same information organized in
a central place for new service providers. If this is of interest,
to the point where the community thinks it is worth the investment,
then it can be done (either directly, or by some of the more grass
roots team out there than would need funding to make this happen)


John Curran
President and CEO

More information about the ARIN-PPML mailing list