[arin-ppml] IPv6 Non-connected networks

[William Herrin]

On Thu, Feb 4, 2010 at 8:45 PM, cja at daydream.com <packetgrrl at gmail.com> wrote:
> 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."

Hi Cathy,

What ARIN policy, past or current, would you cite as an example of
enabling a wide range of possible, rational routing policies, from
which the community coalesced on a particular one? Let's deconstruct
it and see if it really followed course #3.


> 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.

That balance, implemented at ARIN's level, is course #2:

2. Create an addressing policy which is informed by and explicitly
shapes a uniform routing policy.

As you say, we had one routing policy: classful. But we started
running out of class-B's. So we switched to linear allocations of
class C's (they weren't reliably bit aligned IIRC. You can still find
examples in the swamp.). That nearly exploded the routing table. So
the vendors rushed out CIDR in the routing protocols and we started
allocating that way as well.

There was no range of policies here. At each particular time exactly
one policy was possible and those who didn't want to play were broken.


>  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.

Canonical example of path #2. Here''s how that would have gone if we'd
been trying for path #3:

Without estimating routing table impact, ARIN sets aside and publish a
specific then-clean /8 for assignments without a minimum length.
Assignments in all other ARIN spaces would continue to be /19 or
larger. Assignments in the specific /8 would be /20 and shorter only.

ARIN creates a template for ASes to submit their choice of the maximum
prefix length they accept in that /8. ARIN compiles the results and
publishes a regularly updated web page with the percentage of ASes
supporting each prefix length as an FYI for folks requesting addresses
so that they know before paying the likelyhood of their addresses
being routed.

See the difference between course #2 and course #3? In course #3 ARIN
doesn't attempt to make a well-reasoned choice. There's no need.
Instead, it seeks to provide ISPs and registrants with enough
information for them to make well reasoned choices, and then ARIN
steps back and the ISPs and registrants make whatever choices they
darn well please. Initially you have a tug of war between ISPs and
registrants but then it settles out where you have 98% adoption at one
level, 80% adoption at the next and 25% beyond that.


At this point you might say: "So what?'" Well, let's look at what happens next.

On course #2, we know what happened next. We argued and debated some
more and lowered end-user assignments to /22. Now we're arguing and
debating some more and we'll lower multihomed end-user assignments to
/24.

On course #3, I'll have to spin a work of fiction and imagine how it
might have all worked out.

So, we have an unstable situation. Folks are holding or can easily get
IP addresses that are 80% routeable. There's money on the table for
someone who can figure out to get them to the other 20% of the
Internet so that they can dump their ISP-assigned addresses. That's a
recipe for innovation.

Next step, some scrappy inventor figures out that if he can just
introduce a single route for that /8, he can turn around and sell
tunnels to everybody else so they can pick up that final 20%. Not to
mention all the smaller assignments... He shops around and finds a
tier 1 who'll do it. And he's in business. And guess what, in spite of
the slowness from inefficient routing, it grows. What does he care
whether you have a /24 or a /32? You're paying him at a markup so it's
no skin off his back.

Now, the other tier-1's don't like that one bit. Not one bit at all.
Dude's stealing their bread! So, they start a joint venture to do the
same thing, camp it at the major peering points (like MAE-East) and
refuse to honor the /8 route if its announced from anybody else. Sorry
dude! You want service in the small assignments, you pay the joint
venture too.

So now we can have networks of any size right down to /32 and the
worst thing that happens is the packets take a side trip to one of the
peering points. As inefficiency goes, that's pretty darn mild. But it
isn't helpful to Joe. Joe has an ARIN /29, a DSL and a dialup as
backup. The /29 works fine with his DSL but the dialup uses a dynamic
IP address. If only there was a dyndns-like API where he could update
the tunnels quickly with an arbitrary IP address... and he'd need a
tunnel to a friendly ISP to let him source packets past the filter on
the dynamic dialup too...

Cool, so now we have failover from DSL using a $20 dialup using
provider-independent IP addresses and the worst thing that happens is
that our packets take a detour to the nearest major peering point. But
you know, if we could get that tunnel API cut-over time from 60
seconds down to one or two seconds, we could put it on a laptop with
some radio equipment and drive down the road with it. Latch on to the
next tower before we release the trailing one, get a new dynamic IP
and seamlessly move the tunnel forward...

Of course, this is all a work of fiction. When changing the minimum
allocation from /19 to /20, we might not have missed the opportunity
for IP mobility that worked really well. This whole chain of events
could easily have derailed at any step. Even if we'd been smart enough
to offer assignments at any prefix length, we might not have been
clever enough to contain them in a reasonably-sized space someone
could offer a covering announcement for or collect AS data on who
imposed what prefix length limits so that registrants could make
informed choices about it. And just because we were that clever
doesn't mean that the drop-off wouldn't be from 98% to 20% creating no
demand or that the scrappy inventor would have found a tier-1 willing
to accept the /8 announcement or found it affordable if he did.

But it didn't derail at any step. It derailed at the step where
instead of imagining an open-ended assignment process, we made a
well-reasoned decision to lower the minimum assignment from /19 to
/20.

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