[arin-ppml] Encouraging IPv6 route aggregation

[William Herrin]

On Fri, Oct 16, 2009 at 7:47 PM, David Farmer <farmer at umn.edu> wrote:
> On 15 Oct 2009 William Herrin wrote:
>> One ARIN policy problem that's turning this into an IPv6 swamp is the
>> "or shorter" part. Every time ARIN hands out a /40 they've effectively
>> handed out 256 disaggregable /48's. As a community we'd be far better
>> off if everyone who could justify more than a /48 got a /32 from the
>> /32 blocks instead.
>
> This is interesting idea, I'm not convinced just yet, but my initial reaction is it
> might be a good idea.  However,  I realy want to hear what more people think
> about this idea.

Hi David,

There's more than one sensible way to manage IPv6 allocations. The
current ARIN method doesn't happen to be one of them but here's one
that might be:

Have two pools every 8 bits, 1 pool for multihomers and one for
single-homers. 12 pools, 2 each for allocating /56's, /48's, /40's,
/32's, /24's and /16's. Registrant gets an allocation from the
smallest pool that accommodates his justification. So, if he can
justify a multihomed /47, he gets a /40 from the multihomed /40 pool,
not a /47 from the /48 pool.

Two more rules to tweak it just so:

No organization can register more than one allocation at each bit
divide. So, if you have a /48 and you need another /48, you can't get
another /48. Instead, your need for an additional /48 justifies a /40.

If you cease to be multihomed you have 3 months to resume multihoming
or surrender your mutlihomed allocations.


What would be the impact of such a scheme? Allocating in this manner
has the effect of "classifying" each registrant on two vectors:
single/mutli homed and size. That classification is trivially
decodeable at each router by evaluating which pool the prefix falls
in.

Classifying registrants in this manner allows the ISPs a wide range of
flexibility in setting their own routing policies. It also removes
ARIN as the gatekeeper for Internet routing policy: everybody
qualifies for addresses but unlike with IPv4 the addresses you qualify
for *really* might not be routable.


If we're serious about ARIN extricating itself from IPv6 routing
policy then we have to do a good enough and precise enough job
classifying the allocations for ISPs to hang coherent routing policies
on.


>I would be very much opposed to making a similar jump
>from /32 to /24 or shorter, but I can see the logic of going
>from /48 to /32.

Then nibble instead of byteing. Go to from /32 to /28 and then to /24,
but do it with separate pools so that they're usable for
classification purposes within ISP routing policy.


> So then are you opposed to the part of 2009-7 that removes the requirement
> to announce the aggregate allocation?

I'm of the opinion that ARIN shouldn't set routing requirements until
it has exhausted all approaches of the "empowerment" variety that
could make it practical for the ISPs to deal with the bad actors
directly. So in general, I favor removing the ARIN-level requirement
to announce an aggregate.

I'm not so sure about this particular proposal. I haven't scrutinized
the second and third order effects of making just those two
adjustments but it seems like it might be unbalanced, shifting the
overall policy into a worse state instead of a better one.

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