[ppml] Fw: IRS goes IPv6!

[Thomas Narten]

Michael.Dillon at btradianz.com writes:

> > In other words, ARIN should
> > not adopt a policy in which users assume they are getting a routable
> > address block, when in fact, there is a real possibility that it will
> > not be routable in the future. 

> Routability is not a feature that ARIN includes with address
> blocks today.

ARIN makes no guarantees (as it can't). But that does not mean that
there aren't general expectations, or that the adopted policies are
understood to have certain (general) results. We shoudl not be blind
to the implications or consequences of our policies.

> If I understand the substance of the routability argument, it
> is that if ARIN gives out lots of small IPv6 PI allocations then
> each one of these allocations will use up a routing table slot.
> At some point in time, too many slots will be used up and ISPs
> will be forced to remove the ROUTABILITY feature for many of these
> addresses.

Bingo!

> The question that we have to ask, as policymakers, is can we mitigate
> against this eventuality in our policy. The answer is cleary, 
> YES WE CAN.

Small correction: You believe we can. Unfortunately, others are not
convinced. I certainly have some doubts.

Rather than to continue shouting "YES WE CAN", I'd suggest listening
to what others are saying and try to work through the implications of
that.

> The only reason why each one of these small allocations
> would need a slot in the routing table is because ARIN allocates
> them more-or-less at random, first come, first served. If, however,
> ARIN would allocate such addresses in a way that they could be agregated
> into a smaller number of routing table slots and still maintain
> routability, then the policy problem is solved.

In order for these prefixes to be aggregated, you'd have to convince
ISPs to aggregate them and carry traffic for the aggregates. Smells a
bit like ARIN telling ISPs what to do.

You are also reinventing geographical addressing (or metro, or
whatever variant it is). Again, this is an old horse, on which the
community does not have agreement that it solves the problem. Or
rather, agreement that ISPs would ever agree to adopt such an
approach.

Saying it obviously solves the problem, when others continue to point
out serious issues with actually deploying such an approach, isn't
helpful.

> Of course a bloated routing table would not serve the public
> but it also does not serve the public when ISPs pretend that
> the routing technology used today is unable to solve this 
> problem. The problem IS SOLVABLE and if customers demand it
> then ISPs will solve it.

You are much more optimistic than I. I'd prefer to actually see a
viable approach (or outline of an approach) than just assume "we'll
figure it out somehow." Been there, done that.

Thomas