[arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process - revised

[William Herrin]

On Mon, Dec 14, 2009 at 3:43 PM, John Curran <jcurran at arin.net> wrote:
> Needs-based allocation wasn't "invented ad-hoc halfway through the game"...
> (unless claiming the ARPANET as the starting point for the game :-)
>
> As early as 1990 (in the classful, pre-web, single-default Internet), you
> had to explain your initial, 1, 2, and 5 year address needs in order to
> obtain address space.  See the following DDN NIC application template,
> dated April 1990, for the specifics of question 8 & 9 regarding the
> allocation policy at that time.

John,

I'll concede that the question was asked in the 1990 template. But as
late as 1995 folks requesting fewer than 16 class C's needed only
provide a planned subnet and host count. In fact, the instructions on
justification from the 7/95 template read:

   If you are requesting 16 C's or more (/19 prefix) you
   will need to complete the network topology plan in the format
   shown on the template.

   If you are requesting 256 C's or a Class B (/16 prefix) or more,
   please include a copy of your network diagram.

   Your organization is strongly encouraged to subnet where
   feasible.

Note the emphasis on subnetting so that you wouldn't consume an entire
class C for every LAN segment. That's where the heads were in the game
in 1995. That's what we cared about. Unless you were requesting a lot
of addresses, deeper questions of "need" were CURSORY.

Take a look at the progression of documents:
http://bill.herrin.us/network/templates/

Note the change from the '94 to '95 template where describing your
network became more than cursory if you wanted a large address block.
Then note the dramatic change in language from the '95 template to
ARIN's '97 template where needs-based justification had become a major
factor overall.

Suggesting that needs-based justification predates 1994 is like
suggesting that Verizon's history goes back to AT&T's founding or like
suggesting that the DNC's history started with Thomas Jefferson. You
can trace a line through event points and it makes for a great story.
It's spin-doctoring at its finest. In reality, Verizon's history
started with Bell Atlantic following the '84 divestiture and the US
Democratic Party started as southern reactionaries trading on what
little remained of Jefferson's party following the Civil War.

Needs-based justification for IP addresses hit solidly between 1995
and 1997, halfway through the game.


On the other hand, whether or not you were allowed to connect to the
Internet at all was a major issue in the 1990 template. Declare your
sponsor remained the number one question until 1994. Since then,
justifying your connection to the Internet has been very favorably
resolved with a simple: show me the money. Very favorably resolved.

So favorably resolved that it makes sense to me to seek structures
that use money as the primary arbiter for IP address allocation too.



On Mon, Dec 14, 2009 at 6:30 AM, Owen DeLong <owen at delong.com> wrote:
>> We could restrict the top end of the range with a needs analysis but
>> unless there's at least one level of allocation that we're confident
>> the ISPs won't filter before that kicks in, it would trash the whole
>> function of proposal 103 -- ARIN would once again be the routing table
>> gatekeeper. Besides: if someone wants to pay $100k *per year* for a
>> /24, what's the problem exactly?
>
> But someone who gets that /24 as an assignment doesn't pay $100k/year.
> They pay $100/year, just like someone who gets a /32 or a /48 assigment.

Owen,

Ultimately proposal 103 won't set the fees, but the folks who do set
the fees would have to badly misunderstand proposal 103 to set the
fees up where the annual repeat is insignificant. Such a fee structure
would do little to discourage waste.

As suggested in 103's implementation notes, the fee $100k for a /24 is
*per year*, not once up front. Hold it for 10 years and you've coughed
up seven figures.


>> Not only is that an exceptionally radical suggestion, it was solidly
>> opposed by the participants IRTF Routing Research Group when Heiner
>> Hummel suggested it. You can find a relatively informative iteration
>> of the discussion starting at
>> http://www.ops.ietf.org/lists/rrg/2008/msg01781.html .
>
> The IETF also solidly opposed the idea of PI IPv6 at all.  The IETF is not
> the canonical source for good operational practice and addressing policy.

You might want to read the referenced discussion before casting aspersions.


On Mon, Dec 14, 2009 at 3:05 PM, Tony Hain <alh-ietf at tndh.net> wrote:
> Being the person that did the needs based evaluations for the DoE related
> allocations prior to the RIR formation, your fuzzy description is simply
> wrong. Routers of the day had tiny memories compared to current devices, and
> fitting the routing table was a strong consideration. The classful nature of
> allocation units didn't leave much room for negotiation. When someone needed
> more than a handful of /24's, it was better to give them a /16 than to blow
> the routing system.

Tony,

Having read 103, I'm sure you realize that I'm conversant with the
issues surrounding router memories. I've even owned an AGS and I
assure you I'm well aware just how much closer we were to the line
back then. Nor am I unaware that conserving routing slots was the
driving force behind CIDR with conservation of addresses a distant
secondary consideration.

I respectfully submit that while not as close to the line, current
devices have limited memories as well and as far as the routing table
goes, it would still be better to give /16's to anyone who needs more
than a handful of /24's. The current allocation structure too strongly
favors disaggregation for traffic engineering.

Can't do it for IPv4 any more; we're too strongly invested to make big
changes. But IPv6 is still largely an open book.

Regards,
Bill Herrin


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