[arin-ppml] IPv6 Non-connected networks

Thu Feb 4 20:45:42 EST 2010

Bill,

I argue that we do try our best to do #3 as you have defined it below

      "3. Create an addressing policy which is an enabler for a broad range
      of rational routing policies and let the overall routing policy find
      its own equilibrium."

There is a balance, however.  The needs of the ARIN community for
assignments and allocations could easily be in conflict with routing needs.
 We have seen that over and over.  For a while it was extremely apparent
when we were running out of "class B" blocks and started allocating bit
aligned blocks of "class Cs" but there was no CIDR.  So the routing table
exploded and the ISPs had to scramble around to deploy BGP that would handle
huge blocks of "class Cs"    It was a very unpleasant time and my customers
at the time were not at all happy with the slowness of the network.

 When we moved the minimum allocation from a /19 to a /20 first we argued at
length about the routing implications and then we actually watched the
routing table over time to see the effects.   There even used to be a
Routing Table Measurement and Analysis (RTMA) working group as part of ARIN
to bring routing table information to the community as a way to help with
address policy decisions.

With IPv4 address space running out I can easily see scenarios where the
ARIN community will want assignments and/or allocations that directly
conflict with routing.    Some will gain consensus and some probably won't.
  WIth IPv6 we have in essence classfull addressing again.  At some point
will we relive these scenarios?  Probably.

It isn't that the ARIN community doesn't consider these things when
developing good policy.  These things are always discussed and considered
but in the end addressing policy has to also meet the needs of the
community. ARIN has meetings jointly with NANOG for that very reason.  It is
essential that addressing policy has input from the communities it affects.

----Cathy

010 at 6:13 PM, William Herrin <bill at herrin.us> wrote:

> On Thu, Feb 4, 2010 at 7:21 PM, Barbara Roseman
> <barbara.roseman at icann.org> wrote:
> > I think that's a fair restatement of what I was saying,
> >except you left out the part about uniqueness vs.
> >routeability. My points were twofold:
> >
> > 1) ARIN can only offer unique registration of IP
> >addresses, they cannot offer unique use of
> >addresses -- nor can anyone else because
> >Bad People tend to ignore the rules, and Ignorant
> >People are, well, ignorant.
>
> Hi Barbara,
>
> Okay. That reads as a reasonable statement to me. I don't follow how
> it bears on the routing policy issue.
>
> Or at least I don't see a way that ARIN could alter its process to
> make announcements inconsistent with the ARIN registrations easily
> filterable. If such a thing was possible, I'd surely want to see an
> ARIN policy proposal as, no doubt, would every ISP on the planet.
>
>
> > 2) The ARIN community and the NANOG community
> >have discussed repeatedly that it's not simple cause
> >and effect from ARIN's allocation/assignment policies
> >to operator's routing policies, though the influence is
> >extreme. If the connectivity provider is large enough,
> >as CJ notes, than they can do whatever they want.
>
> Okay. So because providers are already able, for a time, to make
> unreasonable choices which defy the defacto standards adopted by the
> overwhelming majority of their peers we should not adopt practices
> that enable more flexibility within the set of -reasonable- choices? I
> don't follow.
>
>
> On Thu, Feb 4, 2010 at 7:09 PM, cja at daydream.com <packetgrrl at gmail.com>
> wrote:
> > Bill,
> > I see what you're saying here but the reality for me was that for close
> to a
> > year a very large ISP didn't pay attention to ARIN's allocation of parts
> of
> > 24.0.0.0/8.  They were big and I was little and so they won at least for
> a
> > time.
>
> That's disappointing in this day and age, but then we're talking about
> the same folks who thought their customers wouldn't cry bloody murder
> when they cut off communications with cogent. If you ever have
> problems with them carrying your routes again, drop me a line so I can
> start claiming service credits. That'll get their attention. :)
>
>
> > ARIN has no control over filtering/routing policies.  At a recent NANOG
> > there was a panel where ISPs in no uncertain terms told the community
> that
> > they do not want ARIN policies to include anything about routing policy.
>  I
> > believe at this point that most of the RIRs have removed routing criteria
> > from their IPv6 policies for that very reason.
>
> Hi Cathy,
>
> Poor control is not the same as no control and getting ARIN policy out
> of the way of ISPs setting routing policy is not the same as saying
> and doing nothing about routing policy.
>
> In a very real sense, addressing is routing is addressing. Each
> follows from the structure of the other. An addressing policy which
> does not impact routing policy is simply inconsistent with reality.
>
> I'll repeat that for emphasis: There's no such thing as addressing
> policy which does not impact routing policy. It can't exist.
>
> Thus the choices are:
>
> 1. Create an addressing policy which implicitly shapes routing policy
> through the accidents of its structure.
>
> 2. Create an addressing policy which is informed by and explicitly
> shapes a uniform routing policy.
>
> 3. Create an addressing policy which is an enabler for a broad range
> of rational routing policies and let the overall routing policy find
> its own equilibrium.
>
>
> What we do now is sometimes #1 and sometimes #2. For example:
>
> A. The unfilterability of traffic engineering is an accidental
> side-effect of CIDR address allocations. Because they're all mashed
> together in the same pool, operators can't tell the difference between
> easily filterable TE and unfilterable multihomed downstreams.
>
> B. Accepting /24 reassignments to multihomed customers regardless of
> size is informed by the /24 boundary present in DFZ routing policy.
>
> C. CIDR allocation (instead of simply assigning a linear range of
> addresses) is an explicit attempt to bring about aggregation within
> the routing system. It's routing policy directly encoded as addressing
> policy.
>
>
> I think we'd be wiser to pursue course #3: enable a broad range of
> sensible routing policies and then step back out of the way.
>
> Regards,
> Bill Herrin
>
>
> --
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100204/6ffa06ca/attachment.htm>