ARIN-PPML Archive

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

Matthew Petach — 2009-11-22T03:21:39Z

>
> 6.5.9.3 ARIN shall register no more than one address block of each
> prefix-length for any single organization. These blocks may be
> registered simultaneously. Renumbering of existing blocks is not
> required to receive additional blocks.

So...I'm a company with a /40 allocation. I buy up 3 companies
with /48 allocations. According to this, ARIN is supposed to drop
the registrations for 2 of the 3 companies, since I can only have
one /40 allocation and one /48 allocation, right? What is the
timeframe allocated for renumbering the acquired companies,
and what should ARIN do to the registrations for the blocks in
the meantime? If my /40 was already full, and doesn't have room
for the 2 new /48s I have to renumber, do I get a /32 allocation
as well, so I can renumber the 2 /48s into the new /32 (thus
coming back into alignment with the requirement to have only
one allocation from each pool size). If that ends my buying
spree, doesn't it seem a bit wasteful to force a company to
get a /32 allocation to accomodate 2 /48s?

Or does the proposal allow me to simply announce the 3 /48s
in additional to the /40 (following more closely the current IPv4
model for handling acquisitions), even if they're from the same
origin ASN?

> 6.5.9.5 For each allocation size, ARIN shall further manage the
> allocation pools such that the pool identity serves to classify
> whether or not the registrant is Multihomed.
>
> 6.5.9.6 ARIN shall offer addresses from pools classified as multihomed
> only to organizations which ARIN has verified are multihomed on the
> public Internet per NRPM 2.7.
>
> 6.5.9.7 Where an organization ceases to be Multihomed it shall
> surrender all address allocations from within pools classified as
> multihomed within 3 months.

I assume this should be re-written to state that the addresses shall
only be required to be surrendered if the organization *remains*
single-homed for the full three month period.

Otherwise, the moment my second upstream provider suffers a
serious fiber cut and my link is down for any real duration (24 hour
fiber cut, on the order of what happened in Silicon Valley last year),
I cease to be "Multihomed", and I get a "you have 3 months to renumber"
letter from ARIN telling me to move off my multihomed space onto the
single-homed pool. 24 hours after that, I get the "oops, sorry, you don't
have to renumber after all" letter from them, when my second upstream
link is restored.

Also note that NRPM 2.7 was designed primarily for ascertaining the
intent to multihome, and does not detail any provisions for ongoing
testing and validation of multihoming (which is a horrible can of worms
to open up! After all, what if one of my 2 upstreams is Cogent, and ARIN
is getting its connectivity from he.net, and only sees one upstream for me,
through HE.net; is it my fault ARIN can't see my other upstream because
HE.net and Cogent are fighting that year?)

>
> Q. Why allow only one allocation of each particular size?
>
> A. Without the address scarcity issue which drives IPv4 policy, the
> primary criteria for IPv6 addressing policy is suppressing the
> disaggregation that drives route count in the IPv4 DFZ (NRPM 6.3.8).
> Such a criteria is not well served if an organization holds dozens of
> discontiguous address spaces as a result of acquisitions, mergers and
> and growing a little bit at a time. This proposal says, in effect,
> once you've consumed your smaller allocation it's time for you to get
> a *much* bigger allocation. The rest of us don't want to pay the
> routing table price for you coming back again and again and again.
>
> The proposal could require some renumbering as a result of mergers and
> acquisitions. However, with only modest planning on the registrant's
> part, the policy its flexible enough to allow that renumbering to
> occur over a long period of time so that both cost and disruption are
> minimized. In many cases, customer churn can be expected to take care
> of much of the renumbering activity all by itself.

I don't see any mention of timeframes in this document; you say that to
minimize cost and disruption, renumbering from multiple smaller pools
obtained due to acquisitions can occur "over a long period of time." Would
a five year renumbering cycle be considered reasonable? What about a
ten year renumbering cycle? Twenty years? At what point does the claim
"I'm renumbering...just very slowly" become specious and indistinguishable
from "I'm just going to announce multiple small blocks...deal with it."

> Q. What happens when organizations merge or split?
>
> A. Entities which merge may renumber out of and return conflicting
> allocations, or they may maintain the existence of the acquired
> organization in order to keep it's addresses. Either way it should be
> a minor hardship.

What about keeping the address blocks within the combined entity?
Is that verboten in this plan? Would this then simply lead to a
proliferation of ORG-IDs, with every block allocated potentially
keeping its own ORG-ID, just so that during mergers and acquisitions
no renumbering would be required? Is there any penalty for an
organization holding dozens of ORG-IDs under one umbrella?

> Entities which split have a bigger problem since the practical effect
> of route filtering may be that only one of them can keep the
> addresses. To a large extent, that problem already exists and is a
> pain in the rump for IPv4 operations today. This policy doesn't solve
> it but it doesn't make it a whole lot worse either. Because
> disaggregates are likely to be filtered, this IPv6 policy does gives
> us a slightly better guarantee that the rest of us won't get stuck
> with the check (in the form of routing slot consumption) when an ISP
> goes bankrupt and gets split up.

It seems to indicate that if I currently have a /40 allocation, and I
split up, as long as the split off portion needs more than a /48, it
can acquire its own /40, right?

> Q. What about reporting requirements for downstream assignments?
>
> A. Reporting requirements were instituted for the purpose of verifying
> eligibility for additional allocations. They have proven useful for
> other purposes and the author encourages ARIN to maintain the SWIP
> system. Nevertheless, this proposal renders the use of SWIP for IPv6
> optional since it is no longer needed to verify eligibility for
> allocations.

Ugh. I think that being able to identify sources of malware and spam
is eminently useful, as is being able to notify registrants of compromised
systems, etc. Not requiring any tracking of downstream number resources
makes it very, very hard to identify who the right points of contact are for
addressing issues with traffic originating from those number resources.
I think reporting requirements for downstream assignments should
still be maintained.

> Implementation notes:
>
> To prevent wasteful consumption of IPv6 address space without a
> complicated eligibility regime, the author recommends an initial and
> annual fee regime for IPv6 address allocations similar to:
>
> /56 -- $10 USD
> /48 -- $100 USD
> /40 -- $1000 USD
> /32 -- $10,000 USD
> /24 -- $100,000 USD

Without some controls in place to justify consumption, at those prices
it would take less than half a billion dollars to consume all of ARIN's
current IPv6 number resources.

It might be worth considering *some* level of control to prevent
large entities from simply choosing to buy up all available address
resources.

> For verification of multihoming, the current way ARIN verifies
> multihoming for other parts of it's policy appears satisfactory.
> Should that change, the author suggests requiring that the AS#
> contacts for at least two AS#'s submit a template indicating that they
> intend to originate or propagate IPv6 BGP routes from the registrant's
> ORG.

That's fine for the initial allocation of space in the multihoming pool;
but you talk about reclaiming space 3 months after a site ceases
to be multihomed; how is that going to be handled? Or will the
upstream ISPs need to send re-affirming letters each month to
establish their ongoing intent to provide transit services?

I see so many issues with this proposal, I don't think I can support
it as it currently stands. Can more work be done to address the
concerns around mergers, acquisitions, divestitures, and how
multihoming determinations are to be handled?

Thanks!

Matt

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

Michael Richardson — 2009-11-20T13:36:02Z

103> Q. What if I don't want to accept /56 routes for
103> single-homed users?

103> A. This policy proposal intentionally and fully places
103> backbone routing policy in the hands of the ISPs who operate
103> the Internet's "Default-Free Zone (DFZ)," colloquially known
103> as the Internet backbone. The author expects that some of
103> the allocations, especially some of the single-homed
103> allocations, *will not* be routable on the public
103> Internet. When we hold a general expectation that all of
103> ARIN's allocations will be routable, we effectively mean
103> that ARIN decides what the Internet routing policy will
103> be. That's precisely the role this proposal removes from
103> ARIN's hands and restores to the ISPs.

HERE! HERE!

IPv6 explicitely supports and encourages multiple prefixes per
interface, so it's entirely reasonable that some "multihomers" will be
happy to do so using several PA from each of their ISPs.
The problem has been --- what address space to use internally,
and this policy finally frees lets even smaller enterprises play.
(All big enterprises were small enterprises at some point..)

103> Q. What about IPv6 addresses for uses which will not be
103> connected to the Internet at all?

103> A. Folks are welcome to get non-multihomed addresses for any
103> purpose whatsoever. If they do eventually decide to connect
103> to the Internet, the routes will follow whatever rules the
103> ISPs have imposed for routes within the single-homed pools.

thank you.

--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the video
then sign the petition.

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

William Herrin — 2009-11-20T12:44:48Z

Here's the diff:

@@ -6,7 +6,7 @@
2. email: bill at herrin.us
3. telephone: 703-534-2652
4. organization: Self
-3. Proposal Version: 1.0
+3. Proposal Version: 1.1
4. Date: 11/2009
5. Proposal type: new
6. Policy term: permanent.
@@ -15,7 +15,12 @@
Strike NRPM sections: 6.2.3, 6.2.4, 6.2.6-6.2.9, 6.4.3, 6.4.4,
6.5.1-6.5.5, 6.5.8, 6.7, 6.10

-Strike NRPM section 6.9 paragraph 2.
+Strike NRPM 6.3.5 sentence 2.
+
+Strike "/NIR" from NRPM section 6.5.6.
+
+In section 6.9 strike NRPM "/LIR" at the end of paragraph 1 and all of
+paragraph 2.

Replace 6.2.5 as follows:

@@ -25,31 +30,57 @@
synonymous. Both terms describe any or all use identified in section
2.5.

+Replace 6.3.4 paragraph 4 with:
+
+Further, RIRs should apply allocation practices that minimize route
+disaggregation.
+
Replace 6.5.7 with:

6.5.7. Existing IPv6 address space holders

Organizations that received IPv6 allocations under the previous IPv6
address policy are entitled to either retain those allocations as is
-or trade them in for an allocation under 6.5.9.
+or trade them in for an allocation under 6.5.9. Where the prefix
+length of such registrations differs from the standard lengths in
+6.5.9.1, it shall count as a registration of the next longer length.
+
+The above notwithstanding, ARIN is authorized to standardize the
+prefix lengths within these previously-allocated address pools in a
+manner approaching 6.5.9.4 by increasing the prefix length of all
+registrants within a particular pool to some specific minimum prefix
+length for the pool.
+
+Add NRPM section 6.2.10 as follows:
+
+6.2.10 Organization
+
+An organization under section 6 is either:
+
+one or more legal entities under common control or ownership, or
+
+one such legal entity which operates strictly separate networks from
+the others.

Add NRPM section 6.5.9 as follows:

-6.5.9 IPv6 Allocations
+6.5.9 Regular IPv6 Allocations

6.5.9.1 ARIN shall allocate IPv6 address blocks in exactly and only
-the following denominations: /56, /48, /40, /32, /24
+the following prefix lengths: /56, /48, /40, /32, /24

-6.5.9.2 No utilization-based eligibility requirements shall apply to
-IPv6 allocations.
+6.5.9.2 No usage-based eligibility requirements shall apply to IPv6
+allocations.

-6.5.9.3 ARIN shall accept registration of no more than one address
-block of each size for any single organization.
+6.5.9.3 ARIN shall register no more than one address block of each
+prefix-length for any single organization. These blocks may be
+registered simultaneously. Renumbering of existing blocks is not
+required to receive additional blocks.

6.5.9.4 ARIN shall allocate IPv6 addresses from pools such that the
-identity of the allocation pool serves to classify the expected size
-of allocations within. ISPs may use that classification to filter or
-otherwise manage their routing tables.
+identity of the allocation pool serves to classify the expected prefix
+length of allocations within. ISPs may use that classification to
+filter or otherwise manage their routing tables.

6.5.9.5 For each allocation size, ARIN shall further manage the
allocation pools such that the pool identity serves to classify
@@ -106,7 +137,7 @@
Benefits of this proposal:

A. Efficient allocation of IP addresses. Orgs get what they need when
-they need it without a great deal of guesswork about actual need.
+they need it without a great deal of guesswork.

B. Efficient utilization of BGP routing slots. No multihomed orgs will
announce more than five unfilterable routes, and that only if they're

@@ -318,8 +354,20 @@
with the check (in the form of routing slot consumption) when an ISP
goes bankrupt and gets split up.

+Q. What happens to the existing (legacy) IPv6 allocations and
+assignments?
+
+A. An organization will be entitled to retain their existing
+allocations indefinitely if they so desire. If the prefix length does
+not match one of the standard prefix lengths then it will be treated
+as the next smaller prefix length for the purposes of determining
+eligibility for further IPv6 allocations. To discourage unnecessary
+disaggregation, the prefix length of this "legacy" allocation will not
+be expanded even if there is room in the pool to do so.
+
Q. What about IPv6 addresses for uses which will not be connected to
the Internet at all?
+
A. Folks are welcome to get non-multihomed addresses for any purpose
whatsoever. If they do eventually decide to connect to the Internet,
the routes will follow whatever rules the ISPs have imposed for routes
@@ -341,12 +389,45 @@
on PPML, seeking a follow-on proposal that establishes address pools
at the /16 level.

+Q. What does standardize prefix lengths within the legacy pools in
+6.5.7 mean?
+
+A. Wes George pointed out that depending on the rules ARIN has
+followed with respect to leaving space between allocations, it may be
+possible to standardize the existing pools on some prefix length as
+well. If it is possible, folks should become able to better filter
+disaggregation in those pools too.
+
+So, for example, if ARIN allocated a /32, a /31 and a /30 from the old
+/32 pool and reserved a /28 for each allocation to expand, ARIN could
+peremptorily increase all three allocations to either /28 and then
+publish that the exact prefix length in that pool is /28.
+
+Another example, if ARIN allocated a bunch of /32's and a /26,
+reserving /28 for each allocated /32, ARIN could increase the /32's to
+/28 and publish that the minimum allocation size for the pool is /28.
+Instead of the /26 registrant being able to disaggregate into 64
+/32's, he might then be constrained to only disaggregate into 4 /28's.
+
+While this proposal does not require ARIN to take that action, it
+authorizes it.
+
Q. What are the struck sections of the current IPv6 policy and why
should they be struck?

A. 6.2.3 - 6.2.9 define terms that have no meaning or use in the
policy as revised by this proposal.

+6.3.4 paragraph 4 gives instructions on accomplishing address
+aggregation which are, if this proposal's rationale is correct,
+counterproductive to encouraging route aggregation. Address
+aggregation only matters to the extent that it helps bring about route
+aggregation.
+
+6.3.5 sentence 2 speaks to documentation issues that are incompatible
+with this proposal. If this proposal's rationale is correct then fees
+alone are sufficient to prevent unnecessary waste.
+
The 6.4.3 notion of a minimum allocation is obsoleted by the
allocation pools of specific size in this proposal.

@@ -398,7 +479,8 @@
intend to originate or propagate IPv6 BGP routes from the registrant's
ORG.

-9. Timetable for implementation: immediate
+9. Timetable for implementation: following an update of ARIN's IPv6
+fee structure.

END OF TEMPLATE

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

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

Member Services — 2009-11-20T12:38:47Z

The proposal originator submitted a revised version of the proposal.

The AC will review this proposal at their next regularly scheduled
meeting and decide how to utilize the proposal. Their decision will be
announced to the PPML.

Regards,

Member Services
American Registry for Internet Numbers (ARIN)

## * ##

Policy Proposal 103: Change IPv6 Allocation Process

Proposal Originator: William Herrin

Proposal Version: 1.1

Date: 20 November 2009

Proposal type: new

Policy term: permanent.

Policy statement:

Strike NRPM sections: 6.2.3, 6.2.4, 6.2.6-6.2.9, 6.4.3, 6.4.4,
6.5.1-6.5.5, 6.5.8, 6.7, 6.10

Strike NRPM 6.3.5 sentence 2.

Strike "/NIR" from NRPM section 6.5.6.

In section 6.9 strike NRPM "/LIR" at the end of paragraph 1 and all of
paragraph 2.

Replace 6.2.5 as follows:

6.2.5 Allocate and Assign

For the purposes of NRPM section 6, allocate and assign are
synonymous. Both terms describe any or all use identified in section
2.5.

Replace 6.3.4 paragraph 4 with:

Further, RIRs should apply allocation practices that minimize route
disaggregation.

Replace 6.5.7 with:

6.5.7. Existing IPv6 address space holders

Organizations that received IPv6 allocations under the previous IPv6
address policy are entitled to either retain those allocations as is
or trade them in for an allocation under 6.5.9. Where the prefix
length of such registrations differs from the standard lengths in
6.5.9.1, it shall count as a registration of the next longer length.

The above notwithstanding, ARIN is authorized to standardize the
prefix lengths within these previously-allocated address pools in a
manner approaching 6.5.9.4 by increasing the prefix length of all
registrants within a particular pool to some specific minimum prefix
length for the pool.

Add NRPM section 6.2.10 as follows:

6.2.10 Organization

An organization under section 6 is either:

one or more legal entities under common control or ownership, or

one such legal entity which operates strictly separate networks from
the others.

Add NRPM section 6.5.9 as follows:

6.5.9 Regular IPv6 Allocations

6.5.9.1 ARIN shall allocate IPv6 address blocks in exactly and only
the following prefix lengths: /56, /48, /40, /32, /24

6.5.9.2 No usage-based eligibility requirements shall apply to IPv6
allocations.

6.5.9.3 ARIN shall register no more than one address block of each
prefix-length for any single organization. These blocks may be
registered simultaneously. Renumbering of existing blocks is not
required to receive additional blocks.

6.5.9.4 ARIN shall allocate IPv6 addresses from pools such that the
identity of the allocation pool serves to classify the expected prefix
length of allocations within. ISPs may use that classification to
filter or otherwise manage their routing tables.

6.5.9.5 For each allocation size, ARIN shall further manage the
allocation pools such that the pool identity serves to classify
whether or not the registrant is Multihomed.

6.5.9.6 ARIN shall offer addresses from pools classified as multihomed
only to organizations which ARIN has verified are multihomed on the
public Internet per NRPM 2.7.

6.5.9.7 Where an organization ceases to be Multihomed it shall
surrender all address allocations from within pools classified as
multihomed within 3 months.

Rationale:

See the implementation notes section below for what should replace
utilization-based eligibility.

The existing IPv6 allocation policy under section 6.5 makes a number
of unproven assumptions about how IPv6 allocations will work.

Unproven: we can make a reasonable guess about how many IPv6 subnets
an organization will need at the outset when they first request IP
addresses. When in all of human history has this ever proven true of
any resource?

Unproven: with sparse allocation, we can allow organizations to expand
by just changing their subnet mask so that they don't have to announce
additional routes into the DFZ. This claim is questionable. With
sparse allocation, we either consume much larger blocks that what we
assign (so why not just assign the larger block?) or else we don't
consume them in which case the org either has to renumber to expand or
he has to announce a second route. Worse, because routes of various
sizes are all scattered inside the same address space, its impractical
to filter out the traffic engineering routes.

Unproven: we can force organizations not to disaggregate for traffic
engineering purposes. Neither any of our experience with IPv4 nor any
of the research in the IRTF Routing Research Group suggests that this
is even remotely practical so long as BGP or any similar system rules
the roost.

Unproven: all non-ISPs can be reasonably expected to get their address
space from ISPs instead of from ARIN. We can certainly operate that
way, but it could prove deadly to the routing table. Any organization
multihomed between two ISPs will need to announce that route via BGP,
regardless of where they get the address space from. We have knobs and
dials in the routers that let us easily filter disaggregates from
distant announcements, but we don't dare do so if there is a
possibility that one of those disaggregates is a multihomed customer
rather than traffic engineering.

Benefits of this proposal:

A. Efficient allocation of IP addresses. Orgs get what they need when
they need it without a great deal of guesswork.

B. Efficient utilization of BGP routing slots. No multihomed orgs will
announce more than five unfilterable routes, and that only if they're
so large that they can afford the price tag for the biggest address
blocks. That's a good thing since IPv6 routes that propagate worldwide
may impose an annual systemic overhead cost on ISPs of as much as US
$16,000 each.

C. Traffic engineering routes are trivially filterable. Any route
longer than the published allocation size can be presumed to be
traffic engineering, not a downstream multihomed customer, thus you
can filter distant small routes with confidence and ease.

D. Fair. No need to define the difference between ISP and not ISP.
Everybody plays by the same rules.

E. No complicated analysis for allocation. You pay for what you want
and get what you pay for. You're either multihomed or you're not.

F. Gets ARIN out of the business of being the gatekeeper for Internet
routing policy. By classifying allocations instead of making
eligibility decisions, ARIN empowers the ISPs to set appropriate
routing eligibility policies instead.

FAQ

Q. Isn't this classfull addressing all over again?

A. Yes.

Classful addressing had a lot of virtues with respect to route
filtering and management. We had to abandon it because there weren't
enough B's for everyone who needed more than one C and there weren't
enough A's period. With IPv6, we don't have that problem. Not yet and
maybe not ever. Perhaps we can have our cake and eat it too.

Q. What if I don't want to accept /56 routes for single-homed users?

A. This policy proposal intentionally and fully places backbone
routing policy in the hands of the ISPs who operate the Internet's
"Default-Free Zone (DFZ)," colloquially known as the Internet
backbone. The author expects that some of the allocations, especially
some of the single-homed allocations, *will not* be routable on the
public Internet. When we hold a general expectation that all of ARIN's
allocations will be routable, we effectively mean that ARIN decides
what the Internet routing policy will be. That's precisely the role
this proposal removes from ARIN's hands and restores to the ISPs.

Q. Spell it out for me. How exactly will pools and size
classifications enable route filtering?

A. Suppose ARIN holds 4000::/12. ARIN might split it up as follows:

4000::/13 -- reserved
4008::/15 -- multihomed /24 allocations
400a::/15 -- non-multihomed /24 allocations
400c::/16 -- multihomed /32 allocations
400d::/16 -- non-multihomed /32 allocations
400e:0000::/18 -- multihomed /40 allocations
400e:4000::/18 -- non-multihomed /40 allocations
400e:8000::/24 -- multihomed /48 allocations
400e:8100::/24 -- non-multihomed /48 allocations
400e:8200::/24 -- multihomed /56 allocations
400e:8300::/24 -- non-multihomed /56 allocations
400e:8400::/22 -- reserved
400e:8800::/21 -- reserved
400e:9000::/20 -- reserved
400e:a000::/19 -- reserved
400e:c000::/18 -- reserved
400f::/16 -- reserved

Now, you're an ISP. Here's a sample routing policy you might choose:

Accept any routes to /32 because anyone paying $10k per year for
addresses is big enough to ride.
For /24 allow 2 bits of traffic engineering too.
Single-homers who won't spend $10k/year on their addresses (smaller
than /32) must use addresses from their ISP. Tough luck.
Accept multihomers down to /48.
The folks paying only $10/year for /56's aren't serious.

Your route filter looks like this:

accept 400e:8000::/24 equal 48
accept 400e:0000::/18 equal 40
accept 400c::/15 equal 32
accept 4008::/14 le 26
reject 4000::/12 le 128

Note how 400e:8000::/24 contains only /48 allocations and you're
allowing only /48 announcements. Since there aren't any /47 or /46
allocations there, nobody in the pool can slip TE routes past you. On
the other hand, you'll get some benefit of traffic engineering from
the super-massive /24 registrants up in 4008::/14 because you're
allowing them to disaggregate down to /26.

Q. If its so expensive to announce routes into the DFZ, why not use
something better than BGP?

A. In 2008 the IRTF Routing Research Group compiled an exhaustive
study attempting to identify the possible ways to improve the routing
system. A draft of the results is at
http://tools.ietf.org/html/draft-irtf-rrg-recommendation-02 . While
there are many promising ideas for how to replace BGP with something
that scales better, we're at least a decade away and probably more
from any significant deployment of a BGP replacement.

Q. Is it really true that multihoming requires announcing a route via
BGP?

A. The short answer is yes. The long answer is more complicated.

Folks have tried very hard to devise multi-vendor multihomed systems
which don't rely on BGP. The only approach that has ever come near
success is dynamically changing DNS records to favor the currently
working Internet connection. "Near" is a relative term here. Such
network architectures are enormously complex and they don't work
especially well. The DNS protocol itself supports quick changes but
the applications which use it often don't. It takes hours to achieve
two-nines recovery from an address change in the DNS and it takes
months to achieve five-nines recovery. Web browsers, for example,
don't immediately recover. Search google for "DNS Pinning."

Q. So the Internet's resulting route policy will be to allow all the
sizes that no major ISP decides to filter and restrict the rest?

A. That's one possible outcome. On the other hand, research in the
routing field suggests that with a sufficiently rich classification
scheme, it may be possible to implement lower priority systems with
provider-independent addresses yet without a global route. Hints for
how such a thing might work can be found in
http://www.cs.cornell.edu/people/francis/va-wp.pdf and
http://bill.herrin.us/network/trrp.html. Such schemes need a rich
classification process at the address allocation level that makes it
possible for ISPs to make reasonable and simple decisions about which
routes should be distributed to every DFZ router and which should not.

Wouldn't that be something: IPv6 provider independent addresses for
everybody without materially increasing the cost of the routing
system.

Q. Why allocate the /48's from a pool only for /48's, /32's from a /32
pool, etc.? Why not allocate from just one pool?

A. If all assignments in a particular pool are /32 then any route in
the /32 pool which is longer than /32 is a traffic engineering (TE)
route. As a router operator you can filter and discard TE routes if
you find they give you insufficient benefit. The routes you filter
don't cost you any money; only the routes you keep carry a price tag.

You can only filter if you're sure they're TE routes... If they're
distinct downstream customer routes and you filter them, there goes
the Internet. Or at least there goes your part of it. See customers.
See customers run... straight to your competitor. Setting up the
distinct pools makes it practical to know with certainty whether the
routes you're filtering are only for TE.

Q. Why allow only one allocation of each particular size?

A. Without the address scarcity issue which drives IPv4 policy, the
primary criteria for IPv6 addressing policy is suppressing the
disaggregation that drives route count in the IPv4 DFZ (NRPM 6.3.8).
Such a criteria is not well served if an organization holds dozens of
discontiguous address spaces as a result of acquisitions, mergers and
and growing a little bit at a time. This proposal says, in effect,
once you've consumed your smaller allocation it's time for you to get
a *much* bigger allocation. The rest of us don't want to pay the
routing table price for you coming back again and again and again.

The proposal could require some renumbering as a result of mergers and
acquisitions. However, with only modest planning on the registrant's
part, the policy its flexible enough to allow that renumbering to
occur over a long period of time so that both cost and disruption are
minimized. In many cases, customer churn can be expected to take care
of much of the renumbering activity all by itself.

Q. What about the IETF recommendations?

A. RFC 3177 recommends that ISPs receive a /32 while downstream
customers receive a /48 assignment by default with so-called "sparse
allocation" to allow those assignments to expand by changing the
netmask. While this proposal supports organizations who wish to follow
those recommendations, it is not this proposal's intention that ARIN
follow RFC 3177.

RFC 3177 is not the gospel truth. It was written back in 2001 when
there was little IPv6 outside of academia and, indeed, little IPv6 at
all. It's an engineers' SWAG about what operations folk should do
that's now 8-years-stale.

This proposal attempts to slow-start IPv6 allocations instead, while
still maintaining the principle of suppressing the routing table size.
As an ISP, consider implementing a slow start for your downstream
customers as well: Give them a /60 initially, add a /56 when they need
it and add a /52 when they run out of the /56. A /60 is 16 /64
subnets. That's an internal LAN, a DMZ and 14 more subnets. Just how
many subnets do you think your normal downstream customer will
actually use?

Q. What happens when organizations merge or split?

A. Entities which merge may renumber out of and return conflicting
allocations, or they may maintain the existence of the acquired
organization in order to keep it's addresses. Either way it should be
a minor hardship.

Entities which split have a bigger problem since the practical effect
of route filtering may be that only one of them can keep the
addresses. To a large extent, that problem already exists and is a
pain in the rump for IPv4 operations today. This policy doesn't solve
it but it doesn't make it a whole lot worse either. Because
disaggregates are likely to be filtered, this IPv6 policy does gives
us a slightly better guarantee that the rest of us won't get stuck
with the check (in the form of routing slot consumption) when an ISP
goes bankrupt and gets split up.

Q. What happens to the existing (legacy) IPv6 allocations and
assignments?

A. An organization will be entitled to retain their existing
allocations indefinitely if they so desire. If the prefix length does
not match one of the standard prefix lengths then it will be treated
as the next smaller prefix length for the purposes of determining
eligibility for further IPv6 allocations. To discourage unnecessary
disaggregation, the prefix length of this "legacy" allocation will not
be expanded even if there is room in the pool to do so.

Q. What about IPv6 addresses for uses which will not be connected to
the Internet at all?

A. Folks are welcome to get non-multihomed addresses for any purpose
whatsoever. If they do eventually decide to connect to the Internet,
the routes will follow whatever rules the ISPs have imposed for routes
within the single-homed pools.

Q. What about reporting requirements for downstream assignments?

A. Reporting requirements were instituted for the purpose of verifying
eligibility for additional allocations. They have proven useful for
other purposes and the author encourages ARIN to maintain the SWIP
system. Nevertheless, this proposal renders the use of SWIP for IPv6
optional since it is no longer needed to verify eligibility for
allocations.

Q. What if I need more than a /24?

A. This proposal's author asserts as obvious: anyone who defines a
need for more than a trillion subnets should make their case publicly
on PPML, seeking a follow-on proposal that establishes address pools
at the /16 level.

Q. What does standardize prefix lengths within the legacy pools in
6.5.7 mean?

A. Wes George pointed out that depending on the rules ARIN has
followed with respect to leaving space between allocations, it may be
possible to standardize the existing pools on some prefix length as
well. If it is possible, folks should become able to better filter
disaggregation in those pools too.

So, for example, if ARIN allocated a /32, a /31 and a /30 from the old
/32 pool and reserved a /28 for each allocation to expand, ARIN could
peremptorily increase all three allocations to either /28 and then
publish that the exact prefix length in that pool is /28.

Another example, if ARIN allocated a bunch of /32's and a /26,
reserving /28 for each allocated /32, ARIN could increase the /32's to
/28 and publish that the minimum allocation size for the pool is /28.
Instead of the /26 registrant being able to disaggregate into 64
/32's, he might then be constrained to only disaggregate into 4 /28's.

While this proposal does not require ARIN to take that action, it
authorizes it.

Q. What are the struck sections of the current IPv6 policy and why
should they be struck?

A. 6.2.3 - 6.2.9 define terms that have no meaning or use in the
policy as revised by this proposal.

6.3.4 paragraph 4 gives instructions on accomplishing address
aggregation which are, if this proposal's rationale is correct,
counterproductive to encouraging route aggregation. Address
aggregation only matters to the extent that it helps bring about route
aggregation.

6.3.5 sentence 2 speaks to documentation issues that are incompatible
with this proposal. If this proposal's rationale is correct then fees
alone are sufficient to prevent unnecessary waste.

The 6.4.3 notion of a minimum allocation is obsoleted by the
allocation pools of specific size in this proposal.

6.4.4 is moot as this proposal does not expect registrants to justify
their IPv6 allocation size.

6.5.1 - 6.5.4 and 6.5.8 are replaced entirely by 6.5.9.

6.5.5 is largely moot since it's no longer necessary to confirm
downstream assignments in order to determine eligibility for
additional addresses.

6.7 is moot as it is unnecessary to compute utilization to justify
addresses under this proposal.

6.9 paragraph 2 is moot since utilization is not a factor in IPv6
policy under this proposal.

6.10 is redundant since micro-allocations are trivially accomplished
under 6.5.9.

Implementation notes:

To prevent wasteful consumption of IPv6 address space without a
complicated eligibility regime, the author recommends an initial and
annual fee regime for IPv6 address allocations similar to:

/56 -- $10 USD
/48 -- $100 USD
/40 -- $1000 USD
/32 -- $10,000 USD
/24 -- $100,000 USD
Legacy -- the lesser of the cost of the next larger size or the cost
of the next smaller size times the number encompassed by the
registration.

The above notwithstanding, it may be advisable to discount /40s and
/32s to a much lower price during IPv6's general deployment process in
order to encourage adoption. Folks who already hold /31's should
probably also get a big break on the $20k fee for a good long while,
perhaps until the first time they request an additional block without
offering a plan to return the legacy addresses.

For verification of multihoming, the current way ARIN verifies
multihoming for other parts of it's policy appears satisfactory.
Should that change, the author suggests requiring that the AS#
contacts for at least two AS#'s submit a template indicating that they
intend to originate or propagate IPv6 BGP routes from the registrant's
ORG.

Timetable for implementation: following an update of ARIN's IPv6
fee structure.

[arin-ppml] Policy Proposal 104: Multiple Discrete Networks for proposal 103

Member Services — 2009-11-20T12:38:31Z

ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with Policy Development
Process.

This proposal is in the first stage of the Policy Development Process.
ARIN staff will perform the Clarity and Understanding step. Staff does
not evaluate the proposal at this time, their goal is to make sure that
they understand the proposal and believe the community will as well.
Staff will report their results to the ARIN Advisory Council (AC) within
10 days.

The AC will review the proposal at their next regularly scheduled
meeting (if the period before the next regularly scheduled meeting is
less than 10 days, then the period may be extended to the subsequent
regularly scheduled meeting). The AC will decide how to utilize the
proposal and announce the decision to the PPML.

In the meantime, the AC invites everyone to comment on the proposal on
the PPML, particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Mailing list subscription information can be found
at: https://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)

## * ##

Policy Proposal 104: Multiple Discrete Networks for proposal 103

Proposal Originator: William Herrin

Proposal Version: 1.0

Date: 20 November 2009

Proposal type: new

Policy term: permanent.

Policy statement:

Add NRPM section 6.5.10 as follows:

6.5.10 Allocations for Multiple Discrete Networks

6.5.10.1 Notwithstanding section 6.5.9, ARIN shall allocate IPv6
address blocks to an organization's second and subsequent networks
where justified by section 6.11 (Multiple Discrete Networks).

6.5.10.2 ARIN shall allocate IPv6 address blocks to an organization's
second and subsequent discrete networks in exactly and only the
following prefix lengths: /40, /32.

6.5.10.3 ARIN shall manage the allocation pools such that the pool
identity serves to classify whether or not an allocation is for a
second or subsequent discrete network regardless of whether it is
single or multihomed.

Rationale:

This updates proposal 103 to support Multiple Discrete Networks as
pending in proposal 2009-5. Offered in parallel so we can debate
exactly how to integrate MDN's without tying up 103 itself.

Timetable for implementation: concurrent with proposal 103.

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

Seth Mattinen — 2009-11-19T12:37:26Z

michael.dillon at bt.com wrote:
>> Can you point me
>> in the right direction for what it would take to get a hold
>> of an archive of IPv4 registration data for the purpose of
>> simulating the action of proposal
>> 103 versus the existing IPv6 policy?
>
> How is a simulation of IPv4 registrations going to illuminate
> a change to the IPv6 policy.
>
> This proposal is just a bad idea in so many ways.
> It is too complex to understand all the implications.
> It is too radical.
> It would disrupt IPv6 deployment while people scramble
> to figure out what it all means.
> It is not needed.
> It is out of sync with the rest of the world.
> It is wasting our time just discussing this non-starter.
> Please take this off the AC's agenda so that they can focus
> on more important issues like IPv4 runout.
>

Applying IPv4 style utilization to IPv6 is also a bad idea, but yet it's
policy.

~Seth

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

George, Wes E [NTK] — 2009-11-19T10:15:28Z

-----Original Message-----
From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin
Sent: Wednesday, November 18, 2009 7:12 PM
To: George, Wes E [NTK]
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process

> [weg] I don't view expanding an existing
> network to match the standardized (and
> only available) netmasks as in any way
> unfair to new entrants.

Oh! You mean expand the legacy prefix lengths to the closest thing to
a uniform length possible rather than let them just sit there, but
restrain the fees until the registrant next asks for more addresses.
That way the two legacy pools may become filterable too and the
reserved address space isn't lost. That's a right good idea.

Would you object to seeing it as a follow-on or parallel proposal
rather than part of the initial proposal? There may be complications
lying in the details of how ARIN has allocated addresses in the legacy
pool. I'd rather those complications not bog down 103.

[weg] Yes, exactly. I'm not necessarily making any comment on fees one way or the other, just thinking in terms of standardizing some of what would now be odd allocation sizes where it's possible to do so. However, I don't think this should be a separate proposal. What I would recommend is language in this proposal that talks to it but that doesn't make it a hard and fast requirement. In other words, give the recommendation that this would be the way to maximize the benefits of this proposal on existing allocations, without writing detailed specs on how it would be handled for all possible cases. Ultimately, that part would be up to ARIN staff to figure out, the proposal simply needs to sketch out the expectation. If it's not possible because of the way certain things are allocated, we're not necessarily any worse off, and you're not advocating renumbering to fix it, so I don't see how it would bog down this proposal.

Thanks
Wes George

This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

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

William Herrin — 2009-11-19T09:16:54Z

On Thu, Nov 19, 2009 at 5:03 AM, wrote:
>> Can you point me
>> in the right direction for what it would take to get a hold
>> of an archive of IPv4 registration data for the purpose of
>> simulating the action of proposal
>> 103 versus the existing IPv6 policy?
>
> How is a simulation of IPv4 registrations going to illuminate
> a change to the IPv6 policy.

Hi Michael,

My intention is to simulate the action over time of both the current
IPv6 allocation policy and in the policy I've proposed by mapping the
actual IPv4 allocations into what that chain of allocations might have
looked like had they occurred under these policies. I wish to start
with the IPv4 data because that's likely to yield results closer to
correct than if I try to generate some sort of randomized data set.

The simulation will require making certain assumptions about the
mapping from IPv4 to IPv6, so I intend to make several reasonable sets
of assumptions for each in order to see how that changes the results.
While the results won't be perfect, it should be possible to identify
patterns in the results which validate or refute this proposal's
claims about address waste and routing table consumption.

> This proposal is just a bad idea in so many ways.

I'm sorry you feel that way. While I respect that the radical nature
of the proposed change would reasonably make anyone suggest that we
_proceed with care_, I hope that the AC elects to move the proposal
forward so that the implications can be analyzed, discussed and should
they ultimately prove persuasive, adopted by ARIN.

By my count it's now 5 enthusiastic, 1 opposed until he sees some data
that justifies the proposal's claims, and you. I would respectfully
suggest that the count merits bringing the proposal forward for formal
discussion and presentation, regardless of whether its current form is
likely to be adopted. We owe it to ourselves to start thinking about
the issues this proposal raises while the IPv6 allocation count is
still small.

Regards,
Bill Herrin

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

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

michael.dillon at bt.com — 2009-11-19T05:03:46Z

> Can you point me
> in the right direction for what it would take to get a hold
> of an archive of IPv4 registration data for the purpose of
> simulating the action of proposal
> 103 versus the existing IPv6 policy?

How is a simulation of IPv4 registrations going to illuminate
a change to the IPv6 policy.

This proposal is just a bad idea in so many ways.
It is too complex to understand all the implications.
It is too radical.
It would disrupt IPv6 deployment while people scramble
to figure out what it all means.
It is not needed.
It is out of sync with the rest of the world.
It is wasting our time just discussing this non-starter.
Please take this off the AC's agenda so that they can focus
on more important issues like IPv4 runout.

--Michael Dillon

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

William Herrin — 2009-11-18T19:11:53Z

On Wed, Nov 18, 2009 at 1:07 PM, George, Wes E [NTK]
wrote:
> [weg] yeah I think that gets to the right ballpark. You
> probably need to assume some percentages as to how
> much deaggregation will still be done as well as how
> much of it will be filtered by ISPs in the DFZ.
> I think you do need to try to capture some scenarios that
> assume some percentage of PI /48s displacing what
> would otherwise be aggregated PD /48s.

Hi Wes,

Let's see what can be done.

[QUESTION FOR THE AC]

I vaguely recall that ARIN offers its registration data set to
researchers trying to do academic analysis about change in the
Internet over time. Do I remember right? Can you point me in the right
direction for what it would take to get a hold of an archive of IPv4
registration data for the purpose of simulating the action of proposal
103 versus the existing IPv6 policy?

> [weg] it's sort of moot what is in my budget. I was
> simply saying that this seems to be quite a lot
> outside of the current fee structure, and fairly
> arbitrary - a simple order of magnitude increase
> as we go up the scale, and I can't exactly see why,

Well, to be frank it *is* fairly arbitrary. It's also just a suggestion.

ARIN has a body whose job is to take all the issues that impact fees
into consideration and then set the fee structure. It's name escapes
me right now, but the point is: those are the folks who will set the
actual fee structure.

My implementation notes are only intended to illustrate the general
kind of demand that the policy places on the fee structure in order
for the policy to work sensibly, since 103's needs are very different
from the needs created by the prior policy.

> [weg] Then what's the point in having /56 as
> an allocation at all, and especially at that
> price point?

There are two subtle yet very important things that the /56 allocation does:

1. It creates an allocation that's effectively PI for all. ISPs *will*
decide not to carry it.

As long as ISPs try to stretch to carry every prefix ARIN allocates,
they'll remain caught in the cost spiral from the constant tug-of-war
between folks who want ARIN to do cheap PI and vendors who expect them
to ante up for bigger TCAMs. I don't want that. I want to see them get
together at NANOG and impanel a committee to study the classifications
and issue a recommendation as to which classes should be carried in
members' DFZ routers. That committee isn't politically possible while
the ISPs are still trying to stretch to carry every ARIN allocation.

2. It creates a void where there's demand, no supply but plenty of
opportunity. We have technologies on the drawing board like LISP and
TRRP ( http://bill.herrin.us/network/trrp.html ) that could, in
theory, create a secondary routing level that acts scalabily without
consuming DFZ slots. But there's no demand to drive the development
and deployment of those technologies because they're only one piece of
the puzzle and the other pieces are also missing.

> [weg] I don't view expanding an existing
> network to match the standardized (and
> only available) netmasks as in any way
> unfair to new entrants.

Oh! You mean expand the legacy prefix lengths to the closest thing to
a uniform length possible rather than let them just sit there, but
restrain the fees until the registrant next asks for more addresses.
That way the two legacy pools may become filterable too and the
reserved address space isn't lost. That's a right good idea.

Would you object to seeing it as a follow-on or parallel proposal
rather than part of the initial proposal? There may be complications
lying in the details of how ARIN has allocated addresses in the legacy
pool. I'd rather those complications not bog down 103.

Regards,
Bill Herrin

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

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

George, Wes E [NTK] — 2009-11-18T13:07:10Z

-----Original Message-----
From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin
Sent: Tuesday, November 17, 2009 5:47 PM
To: arin-ppml at arin.net
Cc: George, Wes E [NTK]
Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process

On Tue, Nov 17, 2009 at 1:09 PM, George, Wes E [NTK]
wrote:

>
> [weg] I think this hits on my concern - Your opinion and my
> opinion as to whether this is a good idea are still just opinions
> without some more analysis. We don't *know* that this will be
> any better. I'd rather you show your work - do some analysis
> of the current routing table to draw some conclusions about
> how much of an improvement we might actually see from something
> like this, both if just one region does it and if all regions do it
> BEFORE we implement it. Even if it's fairly simplistic and
> uses the IPv4 table + classful allocation (allocate the entirety
> of IPv4 space as many times as necessary), I'm not keen on
> recommending such a radical change without more analysis
> to back it up.

Hi Wes,

I think you make a fair point here. And we have lots of time before
the next meeting.

What kind of analysis would you like to see? Assuming ARIN is willing
to provide the data, how about a simulation based on the IPv4
allocation history, repeating it as if under both the current and
proposed IPv6 methods using a couple of different assumption sets and
then looking to see where it comes out in terms of resulting
allocations, free space fragmentation, disaggregability estimates and
so on?

[weg] yeah I think that gets to the right ballpark. You probably need to assume some percentages as to how much deaggregation will still be done as well as how much of it will be filtered by ISPs in the DFZ.
I think you do need to try to capture some scenarios that assume some percentage of PI /48s displacing what would otherwise be aggregated PD /48s.

>>Look at it this way: who am I to tell you how many IP addresses you
>>need to do your job? I'm nobody. You are uniquely well qualified to
>>strike the best balance between cost and size in your particular
>>organization. If it isn't absolutely necessary for me to second guess
>>your judgment in such matters, why should I?
>
> [weg] fair enough, but why are you trying to discourage me from
> asking for a /24 by making it prohibitively expensive then? If
> we're really trying to reduce the amount of overhead and
> justification because IPv6 is so vast and non-scarce, then
> make it easier to justify, don't remove the justification
> altogether and replace it with some pseudo-scarcity pricing model..

The nice thing about cash is that balancing what you want with what
you're willing to pay for is a tried and true method for achieving
respectable efficiency.

If you want a /24 badly enough to pay $100k for it, and more to the
point if you think that's an investment you'll recover well on, then
you should have it. If not, what *is* in your budget?

[weg] it's sort of moot what is in my budget. I was simply saying that this seems to be quite a lot outside of the current fee structure, and fairly arbitrary - a simple order of magnitude increase as we go up the scale, and I can't exactly see why, other than an assumption that those large enough that they could have justified a /24 in the current system must have deep pockets, so they won't notice, and it'll keep "the riffraff" out. I think this precludes the new entries, the innovators on the assumption that $100K isn't a lot in the grand scheme of things. Maybe it would be for some...

In the name of leaving no stone unturned, I'd like to discuss
alternatives. If not cash paid to ARIN directly, would you see annual
Internet services budget as a more reasonable measurement vector?
HD-ratio is truly bizarre but is there another non-cash vector you'd
like to discuss? Perhaps a combination method where the smaller
allocations are simple cash while the larger ones require modest
justification but come with a lower price tag?

I'd also like to hear from anyone who would argue that simple cash
*is* the better choice.
[weg] like I said, I think the best balance would be to still have SOME amount of usage-based justification, probably much less stringent, and make the fee more reasonable, but waive the requirement for justification if someone wants it bad enough to pay an exorbitant fee. That said, I'm still not convinced that pricing is the way to enforce efficiency. If your goal is to make the routing table better, then you can implement rigid allocation models without messing with the justification to get one of said allocations. If your goal is to also make it easier to get IPv6 space in order to spur implementation, you can do that by reducing the current justification requirements. I'm not in favor of eliminating them altogether.

>> To be frank, the whole point of the $10 /56 level is to put you into a
>> position as an ISP where you have to make a choice about filtering
>> because you can't rationally carry those routes on your big iron. I
>> *DO NOT* seriously expect you to carry single-homed /56's in the DFZ.
>
> [weg] I think you have a fundamental flaw in this assumption, and it
>basically breaks routing for any single-homed customer who
>chooses to use PI space.

Upside down. Can't break what never worked. Instead, it sets the
barrier to entry: ISPs don't carry the single-homed /56 block any more
than they carry /26's in the DFZ today. So, just as you have to step
up to a /24 to play in the DFZ for IPv4, you have to step up to some
larger size to be single-homed in IPv6 with PI addresses. Which costs
more. So, you have to make a judgment call about whether not having to
renumber is worth the extra cash outlay.

[weg] Then what's the point in having /56 as an allocation at all, and especially at that price point? It has limited value, primarily for folks that have networks with a requirement for globally unique addresses but no requirement for them to be Internet routable. What I see is far more likely is people raising a ground swell of support for "I have a /56 from ARIN, and you have to route it, because I can't afford to pay you AND pay $1K/year for a /48, you big ISPs are always taking advantage of the little guy..." We didn't always accept /24s in IPv4 either...
Even if I concede that /56 isn't breaking anything not broken today, and maybe it won't end up being routed, I'd argue that even at /48, it presents enough of an incentive that you will increase the number of single-homed PI holders and therefore significantly increase the routing table. At least under the other proposals being discussed, you have to be multihomed to play, so you can make the argument that you're not actively adding something to the routing table that wasn't already there (a multihomed network using PD space is always deaggregated so that you don't have prefix-length matching problems). $1K/year is (usually) still cheaper than a connection to a second provider.

> Also, I'm unclear as to how being able to bring blocks to
> standard sizes through changes in bitmask would make the
> "IPv6 swamp" worse.

For each bit that you increase the mask of your allocation in the
swamp, you double the potential disaggregation you can force on
everybody else. Hence "worse." Also, there's a fairness question.
Grandfathering an existing resource assignment is generally perceived
as fair, but new registrants wouldn't have access to expanding netmask
allocations.

[weg] I don't view expanding an existing network to match the standardized (and only available) netmasks as in any way unfair to new entrants. Plus, I don't see why you couldn't do filtering just the same as you do for the "non-swamp" space to nuke the disaggregation. The more of the swamp space you can get into standardized prefixes, the more you simplify any filtering you attempt to do. Even if there's not discrete blocks allocated for the different sizes, you still can put some assumptions in place about the amount of disaggregation on any of those normalized allocation sizes.

Thanks again,

Wes George

This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

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

William Herrin — 2009-11-17T18:44:17Z

On Tue, Nov 17, 2009 at 6:10 PM, Scott Leibrand wrote:
> You've got a couple months, I think, but we won't be able to ignore the
> issue at the spring meeting. At Dearborn there was near unanimous support
> in the room for the MDN draft policy 2009-5, so the AC voted to move it to
> last call, which completed last week. It will be on the agenda at our AC
> call this week, when I expect we'll recommend it to the Board for adoption.
> Then the Board will need to ratify it, and ARIN staff will need to
> implement it.

Hi Scott,

Nuts. Well, if I have to, I have to. How about this as a starting
point for discussion?

6.5.9.3 Excepting Multiple Discrete Network registrations, ARIN shall
register no more than one address block of each prefix-length for any
single organization.

6.5.9.8 ARIN shall allocate IPv6 address blocks to an organization's
second and subsequent discrete networks (section 6.11) in exactly and
only the following prefix lengths: /40, /32. ARIN shall manage the
allocation pools such that the pool identity serves to classify
whether or not the allocation is for a second or subsequent discrete
network.

I dropped the lower end of the range because I think for now we should
discourage folks from running lots of tiny networks. I dropped /24
because I expect /24 to be modestly disaggregable and want to see if
it turns out that way before including it for MDN's. So, the
single/multi homed classification vector gains a third stop: MDN.

Regards,
Bill Herrin

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

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

Scott Leibrand — 2009-11-17T18:10:24Z

William Herrin wrote:
>
>> Another consideration is Multiple Discrete Networks.
>>
>
> Hi Scott,
>
> If I can duck the issue for now, I'd like to see that addressed in a
> later policy. I don't see Multiple Discrete Networks in current IPv6
> policy. I only see it under NRPM 4.5.
>

You've got a couple months, I think, but we won't be able to ignore the
issue at the spring meeting. At Dearborn there was near unanimous
support in the room for the MDN draft policy 2009-5, so the AC voted to
move it to last call, which completed last week. It will be on the
agenda at our AC call this week, when I expect we'll recommend it to the
Board for adoption. Then the Board will need to ratify it, and ARIN
staff will need to implement it.

> The proposal helps a little by allowing orgs to get several distinct
> blocks. In theory that will at least allow folks with a small number
> of discrete networks to get started. But more work will probably be
> needed to assess what's fair and whether it should be treated as a
> third measurement vector so that ISPs can filter differently.

Taking off my AC hat and putting on the hat of first-hand experience as
a user of the MDN policy:

The routing model of proposal 103 seems to be optimized for a single
organization with a single contiguous network (AS). If an organization
runs multiple discrete networks (with multiple different ASNs), then the
policy either needs to treat each network as a separate entity for
purposes of allocating routable blocks, or we need to explicitly decide
that we would prefer an org with MDNs to get a single allocation and
split it up amongst the MDNs. That, of course, means that any filtering
assumptions we make must take that into account, and we can't rely as
reliably on easy filtering policies. We already have that problem in
IPv6 today with /32s being universally accepted, but more-specific
deaggregates currently being filtered (along with PI /48s) by some networks.

-Scott

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

William Herrin — 2009-11-17T17:46:30Z

On Tue, Nov 17, 2009 at 1:09 PM, George, Wes E [NTK]
wrote:
> From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin
>>I respectfully disagree that we won't see any of the benefits without
>>a global policy. Operators in the RIPE and APNIC regions are just as
>>capable of filtering announcements from the ARIN region on
>>classification boundaries as anyone else is. Whatever benefit there is
>>to be had, we should see 10%-20% of it in a single-region policy. If
>>the benefit proves enough, I think it likely that the other regions
>>will move to adopt similar policies without needing coordination or,
>>frankly, much of a push.
>
> [weg] I think this hits on my concern - Your opinion and my
> opinion as to whether this is a good idea are still just opinions
> without some more analysis. We don't *know* that this will be
> any better. I'd rather you show your work - do some analysis
> of the current routing table to draw some conclusions about
> how much of an improvement we might actually see from something
> like this, both if just one region does it and if all regions do it
> BEFORE we implement it. Even if it's fairly simplistic and
> uses the IPv4 table + classful allocation (allocate the entirety
> of IPv4 space as many times as necessary), I'm not keen on
> recommending such a radical change without more analysis
> to back it up.

Hi Wes,

I think you make a fair point here. And we have lots of time before
the next meeting.

What kind of analysis would you like to see? Assuming ARIN is willing
to provide the data, how about a simulation based on the IPv4
allocation history, repeating it as if under both the current and
proposed IPv6 methods using a couple of different assumption sets and
then looking to see where it comes out in terms of resulting
allocations, free space fragmentation, disaggregability estimates and
so on?

>>Look at it this way: who am I to tell you how many IP addresses you
>>need to do your job? I'm nobody. You are uniquely well qualified to
>>strike the best balance between cost and size in your particular
>>organization. If it isn't absolutely necessary for me to second guess
>>your judgment in such matters, why should I?
>
> [weg] fair enough, but why are you trying to discourage me from
> asking for a /24 by making it prohibitively expensive then? If
> we're really trying to reduce the amount of overhead and
> justification because IPv6 is so vast and non-scarce, then
> make it easier to justify, don't remove the justification
> altogether and replace it with some pseudo-scarcity pricing model..

The nice thing about cash is that balancing what you want with what
you're willing to pay for is a tried and true method for achieving
respectable efficiency.

If you want a /24 badly enough to pay $100k for it, and more to the
point if you think that's an investment you'll recover well on, then
you should have it. If not, what *is* in your budget?

In the name of leaving no stone unturned, I'd like to discuss
alternatives. If not cash paid to ARIN directly, would you see annual
Internet services budget as a more reasonable measurement vector?
HD-ratio is truly bizarre but is there another non-cash vector you'd
like to discuss? Perhaps a combination method where the smaller
allocations are simple cash while the larger ones require modest
justification but come with a lower price tag?

I'd also like to hear from anyone who would argue that simple cash
*is* the better choice.

>> To be frank, the whole point of the $10 /56 level is to put you into a
>> position as an ISP where you have to make a choice about filtering
>> because you can't rationally carry those routes on your big iron. I
>> *DO NOT* seriously expect you to carry single-homed /56's in the DFZ.
>
> [weg] I think you have a fundamental flaw in this assumption, and it
>basically breaks routing for any single-homed customer who
>chooses to use PI space.

Upside down. Can't break what never worked. Instead, it sets the
barrier to entry: ISPs don't carry the single-homed /56 block any more
than they carry /26's in the DFZ today. So, just as you have to step
up to a /24 to play in the DFZ for IPv4, you have to step up to some
larger size to be single-homed in IPv6 with PI addresses. Which costs
more. So, you have to make a judgment call about whether not having to
renumber is worth the extra cash outlay.

>> My intention in the proposal was that you keep the /29 for as long as
>> you want (don't renumber unless you want to!) and it counts under the
>> new policy as your choice of a /32 or a /24, making you eligible to
>> add either a /24 or a /32 but not both.
>>
>> My intention was also that the /29 *would not* be expandable to a /24,
>> even if ARIN reserved enough space to do so. That's the IPv6 swamp and
>> we're stuck with it but let's not make it any worse than it already
>> is.
> [weg] if that's your intention, I didn't read that from the policy or
> implementation notes. You should probably make that clearer.

I'll try to clarify that in the next draft.

> Also, I'm unclear as to how being able to bring blocks to
> standard sizes through changes in bitmask would make the
> "IPv6 swamp" worse.

For each bit that you increase the mask of your allocation in the
swamp, you double the potential disaggregation you can force on
everybody else. Hence "worse." Also, there's a fairness question.
Grandfathering an existing resource assignment is generally perceived
as fair, but new registrants wouldn't have access to expanding netmask
allocations.

>> Another question I do think is largely unanswered is some
>> manner of estimate of how much address space (in terms
>> of number of networks) going back to something like classful
>> address allocation would cost us [...] compared with other
>> options like sparse allocation.
>
> Well, sparse is easy. 200 /56 allocations inside your /29 costs 8 bits
> leaving you with /37 as your largest possible remaining allocation.
> But, each of the /56's is, at that point, also capable of expanding to
> /37 via a netmask change.
>
> With the method described in this proposal, there's no need and indeed
> no reason to leave space between allocations, so the same 200 /56's
> consume part of one /48, leaving the largest remaining allocation in
> your /29 at /30. However, any of the /56's who need more addresses
> will add a /48 instead of being able to expand their /56.
>
> From an address conservation perspective, this proposal's allocation
> method should come out way ahead of sparse. Sparse is incredibly
> wasteful of address space.
>
> [weg] Thanks for that, but I think you missed a fundamental
> distinction - allocated space [is] completely in
> use. Reserved space is not.

Heavily fragmented reserved space creates waste and other problems. In
the sparse example above you needed to assign a /32 to someone, you'd
have to go back for more address space or allocate 32 disaggregate
/37's. With this proposal's method, that /32 is readily doable, as is
a /30. Free space fragmentation is not *as bad* as allocated space
fragmentation, but it's still bad.

On Mon, Nov 16, 2009 at 7:40 PM, Scott Leibrand wrote:
> On Nov 16, 2009, at 4:27 PM, William Herrin wrote:
>> 6.2.10 Organization
>>
>> An organization under section 6 is either:
>>
>> one or more legal entities under common control or ownership, or
>>
>> one such legal entity which operates a strictly separate network from
>> the others.
>>
>>
>> Thoughts? Alternatives?

> Another consideration is Multiple Discrete Networks.

Hi Scott,

If I can duck the issue for now, I'd like to see that addressed in a
later policy. I don't see Multiple Discrete Networks in current IPv6
policy. I only see it under NRPM 4.5.

The proposal helps a little by allowing orgs to get several distinct
blocks. In theory that will at least allow folks with a small number
of discrete networks to get started. But more work will probably be
needed to assess what's fair and whether it should be treated as a
third measurement vector so that ISPs can filter differently.

Regards,
Bill Herrin

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

[arin-ppml] Securing Routing Information

John Schnizlein — 2009-11-17T14:58:39Z

FYI, here's a report from a group of operators who got together and
discussed the issues.

http://www.isoc.org/educpillar/resources/docs/routingroundtable_200909.pdf

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: