[ppml] Fw: IRS goes IPv6!

[Michael.Dillon at btradianz.com]

> 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. In particular NPRM 4.4 offers /24 microallocations
of IPv4 space when it is known that ISPs do filter /24 prefix lengths.
In addition, some applicants for address space have no intention
of announcing it on the global Internet and therefore routability
is not an issue. In the past, when ARIN reduced the initial ISP
allocation from /19 to /20, the /20 prefixes were NOT routable
because many ISPs filtered such prefixes. Within a short time
after ARIN changed the policy, ISPs adjusted their filtering to
make the addresses routable. Thus, I believe that routability
should not be a responsible of ARIN but should be left squarely
in the hands of the ISPs.

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. 

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. 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. 

I suggest that the ARIN region be divided as follows

Northwest        Central Plains  Northern Midwest  Northeast
Northern Calif.                                    DC and region
Southern Calif.  Southwest       Southern Midwest  Southeast

IPv6 PI allocations will be allocated out of larger reserved
blocks so that they can be aggregated under the larger 
regional block. The following explains the boundaries of 
the regions.

Northwest (Oregon, Washington, Idaho, British Columbia, Alaska, Yukon)
Central Plains (Alberta, Saskatchewan, Manitoba, Northwest Terr.,
                Nunavut, Great Plains states)
Southwest (Nevada, Arizona, NM, Texas)
Northern Midwest (Chicago and surrounding states)
Southern Midwest (St. Louis and surrounding states)
Southeast (American Southeast plus Caribbean)

Rather than worry about precise boundary lines for
these regions, ARIN should suggest the region to the
applicant and ask their approval. Of course, the concept
of aggregation of addresses based on the geographical 
location of their upstream ISP's PoP should be explained.
 
> > ARIN exists to serve the public, not to serve ISPs.
> 
> It is really unhelpful to couch this in "public" vs. "ISP" tones,
> since things are not that simple. I care about having an Internet that
> works (for everyone) and having a bloated route table in which ISPs
> are forced to filter with the end result being loss of connectivity
> for certain classes of end users is not something I want to see happen
> and is not something I believe would serve the public.

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.

--Michael Dillon