[arin-ppml] ARIN Multiple Discrete Networks Policy

[John Curran]

On Oct 5, 2011, at 2:33 AM, Jeff Wheeler wrote:

> On Tue, Oct 4, 2011 at 2:29 PM, John Curran <jcurran at arin.net> wrote:
>>> It still isn't, and won't be, until a significant portion of ARIN IRR
>>> mntners change their authentication mechanism.
>> 
>> Correct.  What should be done in this area?
> 
> I see several options with different associated headaches.
> 
> The most obvious to me is to eliminate email authentication as a
> supported choice, and replace the auth: attributes of those mntner
> objects with a garbage password.  This would force those mntners to
> contact ARIN (or perhaps use your web site automation?) to "reset
> their password" before their objects can be modified.  This way, the
> current objects will remain in the database; they cannot be
> maliciously altered or erased without non-trivial efforts; but it will
> create some customer support issues which will add work-load.

It also may be possible to do something in combination with 
ARIN Online to minimize the telephone workload level.

>> What useful things do you want us to do to "reduce DFZ bloat"  You have
>> mentioned that twice but not indicated exactly what you are looking for...
> 
> A good starting point would be to have a user-friendly interface to
> ARIN IRR.  MERIT RADB has one that is not bad, but it isn't quite
> "point and click," which would benefit the droves of less
> knowledgeable operators participating in the DFZ today.  It should be
> easy to publish correct IRR information.
> 
> I would like it if ARIN had a bot that emailed the technical contact
> for address spaces when new DFZ advertisements appear (for a sustained
> period of time, say a week) that do not match existing IRR data. 

Got it.

>> Let's look at some options -
>> 
>>  - Do you want ARIN to alter the way in which it does address allocations
>>    so it ties to the state of someone's IRR information?  If so, that
> 
> Yes.
> 
> I would also like members who are going to announce a /24 to the DFZ
> anyway to be able to request a /24.  This should have been done a very
> long time ago.  The reason is not difficult to understand -- if a
> member is going to announce a /24 and they already know that's what
> they are going to do, you can put them into a suitable address space
> where there should generally not be any de-aggregates beyond the
> nominal allocation boundary, e.g. /20.  This ALREADY HAPPENS for
> 2002-3 allocations but not because the network will announce a long
> route to the DFZ, but because 2002-3 allows them to have a pretty
> small allocation and it was the intent of the community to make it
> possible to filter garbage /24s and /22s out of other chunks of the
> address space.
> 
> I further would like members to be able to request de-aggregated
> address space for private interconnections, backbone, etc. that they
> do not want to belong to a larger aggregate DFZ announcement.  For
> example, I don't want a /24 I use for certain circuits to be announced
> to the DFZ at all, but I do want DNS authority for it, and require
> globally unique numbers for it.  I don't have a RIR /24, I have /20s
> and larger.  In order to get this behavior, I have to jump through
> some technical hoops which is not always practical or even possible;
> or de-aggregate a /20 and not announce the aggregate route, but
> instead announce a /21, /22, a /23, and a /24.  I don't do this but I
> also don't get the technical benefit of having some globally unique
> numbers for interconnection without having them be globally reachable.
> 
> I would like ARIN to come out strongly against any de-aggregation at
> all in ISP /32s.  If someone needs to de-aggregate, give them more
> /32s!  Strongly discourage them from announcing /48s because it will
> be necessary for us all to honor these /48s, meaning we cannot simply
> filter everything longer than /32 from the relevant chunks of address
> space.  If members do not feel like they should receive a bunch of
> /32s, then choose a different size and allocate these from special
> space.
> 
> If we do not do something like the above, the IPv6 DFZ will make IPv4
> look great.

These do have tradeoffs in terms of address space issued (from a very
large pool :-) and their benefit in terms of routing bloat.  That is 
the sort of tradeoff that definitely needs community discussion and 
consensus.   Is there an order you'd like to propose these policy 
changes in, and/or do you need help submitting them?

> As I mentioned above, I would like the ARIN IRR to be user-friendly.
> I agree with your idea that it be integrated into the other ARIN
> online tools, and was hoping this would indeed be implemented as you
> indicated earlier this year.  I would also like the data in it to be
> accurate and for rules to exist on what route: objects may be created
> by what user -- I don't think I should be able to insert a route:
> object with origin: AS65555 unless I am logged in to the web site as
> someone with permission to make routes in AS65555.  I also don't think
> I should be able to make route: objects for address space that doesn't
> belong to me.
> 
> I don't think users should even have to understand that they are
> making a route: object, I think it should just say, here are the
> allocations and assignments for you, and you can make IRR entries to
> facilitate BGP routing if you want to.  This system needs to become
> more straight-forward so novice operators can take advantage of it.
> It doesn't have to come with a deck of cards and pressurized peanuts,
> but if IRR is made easy to use, more people will utilize it.  Fewer
> ISPs will dump trash routes into RADB (and then never erase them) and
> fewer ISPs will just do all this manually.
> 
> I further think the ARIN IRR / tools should make it pretty damn easy
> to get a prefix-list for a desired as-set or aut-num, in a way that is
> machine-readable, so you don't have to download the files, generate
> with your own tools, and so on.  It would be pretty nice if it was
> easier for transit networks to take advantage of the data that is
> there (and hopefully, more accurate and safe!) but this is
> surprisingly hard for many of them.

I've got the list, and your timing for such suggestions is perfect
since we're in the midst of planning next year's operating plan,
including all of the development initiatives.

Thanks!
/John