Re: minimum IPv6 announcement size

[William Herrin <bill () herrin us>]

On Fri, Sep 27, 2013 at 2:11 PM, William Herrin <bill () herrin us> wrote:
> On Fri, Sep 27, 2013 at 1:04 PM, Randy Carpenter <rcarpen () network1 net> wrote:
> > Therefore, I don't see any reason to artificially inflate
> > the routing table by conserving, and then making
> > orgs come back for additional allocations.
>
> I'm not convinced of that. Suppose the plan was: you start with a /56.
> When you need more you get a /48. Next is a /40. Next a /32. Next a
> /28. You can hold exactly one of each size, never more. And the RIRs
> tell us all which address banks each size comes from.
>
> In such a scenario, the RIR doesn't have to reserve a /28 for
> expansion every time the allocate a /32. 'Cause, you know, that's what
> they've been doing. And you can easily program your router to discard
> the TE routes you don't wish to carry since you know what the
> allocation size was. That means you only have to carry at most 5
> routes for any given organization. You'd want to allow some TE for the
> sake of efficient routing, but you get to choose how much.
>
> As things stand now, you're going to allow those guys with the /19s
> and /22s to do traffic engineering all the way down to /48. You don't
> have a practical way to say "no."


Point is: there are a number of address management practices which
significantly impact the routing table size. The ones that jump to
mind are:


1. Receiving discontiguous blocks from the registry on subsequent
requests. If the blocks can't aggregate then they consume two routes
even if they don't need to.

Registry-level mitigations: allocate in excess of immediate need.
Reserve additional space to allow subsequent allocations by changing
the netmask on the same contiguous block.


2. Registry assignments to single-homed users. Registry assignments
can't aggregate, even if their use shares fate with another AS's
routes.

Registry-level mitigations:minimize allocations to organizations which
are not multihomed.


3. Traffic engineering. Fine tuning how data flows by cutting up an
address block into smaller announced routes.

Registry-level mitigations: Standardize allocation sizes and allocate
from blocks reserved for that particular allocation size. Do not
change a netmask in order to reduce or enlarge an allocation. This
allows the recipients of TE advertisements to identify them and, if
desired, filter them.


4. ISP assignments to multihomed users. In other networks, assignments
to end users from your space are likely to be indistinguishable from
traffic engineering routes. TE filtering is impossible if some of the
announcements are multihomed customers whose fate is not shared with
the ISP to whom the space was allocated.

Registry-level mitigations: Direct assignment to all multihomed
networks. Discourage ISPs from assigning subnets to multihomed
customers.


Note the contradictory mitigations. Standardized block sizes increases
the number of discontiguous blocks. Netmask changes defeat
standardized block sizes. So, it's a balancing act. Does more route
bloat come from filterable TE? Or from discontiguous allocations? The
customer lock-in from being the organization who assigns the
customer's IP addresses turns around and bites you in the form of
unfilterable traffic engineering routes.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin () dirtside com  bill () herrin us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004