[arin-ppml] IPv6 Allocation Planning

[Joel Jaeggli]

On 8/9/10 7:27 PM, William Herrin wrote:
> On Mon, Aug 9, 2010 at 8:23 PM, Joel Jaeggli <joelja at bogus.com> wrote:
>> There are quite a few people on this list who've had deployed dual stack
>> ipv6 networks for longer than it took us to put a man on the moon.
>>
>> Jaded rather than inexperienced is the first thing that some to mind.
> 
> Hi Joel,
> 
> There were plenty of jaded IPv4 gurus in 1993. Those that survived and
> were still acknowledged gurus were far wiser and more knowledgeable in
> 2003.
> 
> My point is: there's a lot about IPv6 policy we can't yet predict with
> a high confidence. We'll do the best we can and we'll change it when
> we learn better, but for now there's still a lot of guesswork
> involved.
> 
> There are, however, two routing factors related to IPv6 addressing
> policy we can evaluate with a high degree of confidence. Because we
> can accurately predict them and because the routing table continues to
> have scarcity issues when the IPv6 address pool doesn't, I propose
> that these predictable routing factors should weigh distinctly more
> heavily than the factors whose prediction is less certain.
> 
> * We can predict the difference in the minimum number of routes in the
> table as a result of a given policy change.
> 
> * We can predict the difference in the maximum number of routes in the
> table as a result of a given policy change.
> 
> Owen's proposal doesn't change the minimum. It's still 1 per ISP.
> 
> Owen's proposal hands out more /32's without offering any mitigation
> to obstruct them from being disaggregately announced as /32's. Thus is
> significantly increases the maximum number of routes possible in the
> table.

In the end they're going to be deaggregated to more specifics than that
for the same reason the are in ipv4.  being able to glob them together
when possible into something shorter than a /32 is nice but it's not
going to prevent the growth of prefix length.

my problem 2001:490::/32 for example has nothing to do with address span
and everything to do with topology.

nor is it going address other reasons entities end up with non
aggregatable prefixes such as M and A, assignments from different RIRs
in multiple regions operation of discontiguous networks and so on.

> Arguably the policy could reduce the total number of blocks held by
> any given ISP by reducing their likelihood of coming back for more. So
> there's the outside possibility that an ISP who would otherwise have
> announced two separate blocks will instead hold and announce only one.
> But even if we could accurately quantify that (and we can't) the ISP
> would still hold at least as many disaggregable /32's.
> 
> No change to the one predictable routing factor (minimum).
> Significantly worsens the other (maximum). Everything else being
> equal, that makes it a bad policy change.
> 
> 
> What, then, would a good policy change look like under this evaluation
> process? Suppose:
> 
> * Allocate or assign addresses only in standard sizes: /48, /40, /32, /28, /24.
> * ARIN rounds up to the smallest standard size that the application justifies.
> * Allocations from published blocks containing allocations of only
> that one standard size.
> 
> The minimum routing table impact remains 1 per ISP.
> 
> Maximum is limited to 1 per allocation. ISPs may choose to allow
> moderate disaggregation of a standard size for the purpose of traffic
> engineering. They may not. But that's their choice. Accepting
> disaggregates for any allocation is no longer an inevitable confluence
> of technology and ARIN policy.
>
> The policy tends towards handing out more addresses (round up) so it
> arguably reduces the rate at which ISPs return for more, as with
> Owen's idea. Still can't accurately quantify that, but we know for
> sure that no ISP will carry a /28 as 16 /32s unless they want to.
> 
> No change to the one predictable routing factor (minimum). Distinct
> improvement the other (maximum). Everything else being equal, that
> makes it a good policy change.
> 
> 
> Now, suppose you did both standard sizes AND you also did Owen's
> change? Well, look at that, with both changes Owen's proposal doesn't
> worsen the maximum routing table impact at all. More addresses are
> handed out but they don't disaggregate.
> 
> See my point?
> 
> Regards,
> Bill Herrin
> 
>