[ppml] 2005-1 status
> 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
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.