[arin-ppml] ARIN Multiple Discrete Networks Policy

Jeff Wheeler jsw at inconcepts.biz
Tue Oct 4 08:15:45 EDT 2011

On Mon, Oct 3, 2011 at 9:29 PM, John Curran <jcurran at arin.net> wrote:
>  I think you mistake the role of ARIN staff from that of the
>  community; you're not going to read an email from me making

How ARIN staff interprets and implements policy has always had
significant impact.  I believe ARIN can reduce IPv6 DFZ bloat by doing
a better job of collecting the explicit intent of members receiving
allocations, by paying more attention to its routing registry.

For example, there are an increasing number of small prefixes in the
IPv6 DFZ, as ISPs are generally not sure what filtering is needed or
appropriate.  Today, this is not a severe problem, because the v6 DFZ
is small and deployment remains in its infancy.  This situation may
evolve rapidly in the next several years, to a point where allocations
being made today become a new "swamp" that could eventually be far
worse than its v4 counterpart.

I don't want to see stupidity impact the v6 DFZ because the larger
address space increases risk in this area.  There should not be
organizations with /32 allocations who are announcing /48 networks to
the DFZ, yet there are.  Some of this is certainly done with explicit
intent, but much of it is doubtlessly out of sheer stupidity.
Individual transit networks are not motivated to police their
customers' advertisements because it simply turns customers to their
competitors.  I have one down-stream customer who announces over 100
DFZ routes, yet has three RIR allocations.  This is terrible, but if I
refuse to honor those routes, they will simply go to someone else;
this is made obvious by the fact that they have other transit
providers who gladly accept the routes to get their business.  It is
not hard to imagine a future where this down-stream has even more
de-aggregates, because they can create an awful lot of /48s out of a
/32; and ISPs are not in a good position to police that.

ARIN should start by making it easy and necessary for members to
express what routes they intend to inject to the DFZ when they receive
allocations.  If your IRR was treated as a useful tool for members and
operators, instead of an afterthought (does it have any authentication
mechanism yet?), you would already be there.

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.

Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts

More information about the ARIN-PPML mailing list