[ppml] 2005-1 status
Say ARIN defines a netblock for PI allocations, and allocates /44 through
/32's out of it (IIRC /44 is the minimum allocation size in the current
policy proposal, not /48). Then say APNIC and RIPE each decide to do the
same, followed by LACNIC and AfriNIC. Now you have 5 different
geographically identifiable ranges from which PI space is allocated. If
at some point we have too many routes for routers to handle, operators in
each region could safely filter smaller routes from the other regions, as
long as they set up aggregate routes pointing in the right direction, or
get their peers in the other regions to advertise the aggregates to them.
That seems to me the extent to which geotopological addressing will be
feasible in the real world, where NSPs operate continental or global
backbones. And if the current iteration of 2005-1 gets approved, we may
end up there sooner than we expect.
IMO giving PI space to anyone multihomed with PA /48's from two providers
is going to dramatically increase the rate of routing table growth over
what we've seen with IPv4. If we're willing to deal with that using
tricks like the one described above, fine, but I think we should seriously
consider only issuing PI space to users whose size or network complexity
makes the use of PA space for multihoming impractical.
On 02/01/06 at 4:57pm -0000, Michael.Dillon at btradianz.com wrote:
> > and yet i don't see ARIN's policy process approving the allocation of
> > significant amount of nonrouteable address space. so while it's not any
> > sort of guaranty, it sure as heck is a guiding principle for
> When we moved from a /19 starter prefix for ISPs to
> a /20 starter prefix, we did not know how many ISPs
> would accept /20 prefixes. It was known that some ISPs
> had filtering policies that would not accept /20s.
> However, ARIN still went ahead with the policy change
> knowing that it was likely that these ISPs would not
> have full routeability. But since we were only moving the
> goalposts a small amount, we expected that the majority
> of those with /19 filters would adjust then to accomodate
> the /20 routes since it was a modest change.
> In the same way, if ARIN starts to hand out /48 PI blocks
> to IPv6 users, we cannot guarantee that they will be routable
> and we know that there are some people who are filtering
> such routes. But because this is a modest change, i.e. it
> has the precondition of owning a v4 PI block, we expect that
> ISPs will adjust their practices. If we include in this policy
> that these /48s will come out of a specific address range which
> will not be used for other types of IPv6 allocation, then it
> is even more likely that ISPs will adjust their practices.
> So it is not necessary for an ISP practice to be in place
> before ARIN changes policy. It merely needs to be technically
> and practically feasible for many ISPs to change their practice
> in order for ARIN to go ahead. In some ways this is similar to
> the opening of a new address range. ARIN does not wait for bogon
> filters to be updated before issuing addresses from the new range.
> ARIN takes reasonable actions, publicizes those actions, and
> expects the rest of the world to take note and adjust to the
> new situation.
> The objection seems to be that there is a threshold beyond
> which the number of /48 prefixes will have a deleterious
> effect on Internet routing. Most agree that this is so and
> we are looking for a way to avoid quickly arriving at that
> situation. However, there is not much we can do about the
> fate-sharing problem given the current practice on the Internet.
> If we issue /48 prefixes from an identifiable range, then
> ISPs can treat those prefixes differently from other /48
> prefixes based on the range. However, if the total number of
> such prefixes exceeds the threshold where it causes pain,
> then the only defensive action available is to filter all
> /48 addresses in the range. Or to randomly pick a subset
> of the range for such filtering. All PI users then share
> the same fate.
> In order to forestall that event, ARIN could define
> MULTIPLE ranges for these /48s defined by geography.
> Then, when we hit the threshold, ISPs have the option
> of only filtering those /48s which are not local to
> them, i.e. not in the same geographical range. This
> is done by proxy aggregation and it is not simple for
> a truly national or international ISP to deal with
> at present, but then this threshold event is not likely
> to hit us right away.
> In the meantime it seems prudent for ARIN to take this
> action which causes no current harm, allows for people
> to experiment with geographical addressing and routing,
> and provides an out in the event that the numbers of
> PI allocations exceed our expectations.
> --Michael Dillon
> PPML mailing list
> PPML at arin.net