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

[David Farmer]

The AC will be voting to abandon or accept this proposal 103 and the 
related proposal 104 on to its docket late next week.  I concur with 
other comments to the effect that the AC would either abandon both 
proposals or merge them and accept them on to the docked as a single 
piece of work.  So I'm dealing with them both in this email.

There hasn't been any posts on either of these proposals since before 
Thanksgiving.  So, as one of the shepherds I though I would summarize 
what I've seen so far, then maybe make a few comments, and see if anyone 
has any comments before the AC votes next week.

So, if you have opinions or arguments at to why the AC should or should 
NOT put this proposal on its docket you should express them soon.

----

Regarding Proposal 103:
31 total posts, 12 individuals, 7 in support, 2 opposed, 22 posts 
furthering the discussion and not explicitly supporting or opposing

Regarding Proposal 104:
5 total posts, 4 individuals, 1 in support, 1 oppose, 3 furthering the 
discussion and not explicitly supporting or opposing

No warranty on those totals, I might have screw up my hatch marks, but 
it should be close.

----

Personally, I find the proposal intriguing.  I believe this proposal 
provides a bold and creative solution to several current problems in 
ARIN's IPv6 policies.

However, at the same time this proposal has several issues;
(FYI, These are my own words, but some of the ideas are borrowed from 
discussions with others, including private discussions)

- Needs Basis

First and probably most important from my personal point of view, I 
don't see a needs basis in this policy, even in the classful IPv4 days 
you had to demonstrate need to get a Class B, or Class A; I believe that 
you had to demonstrate a need for more than 256 host and/or multiple 
subnets to get a Class B, and more than 256 subnets or have a large 
scale backbone to get a Class A.  I may not have that exactly right but 
there was a criteria.  If there wasn't then the first 126 allocation 
would have been for Class As and then next 16,000+ allocations would 
have been for Class Bs leaving only Class C and we would have exhausted 
IPv4 long ago.

So, I believe this proposal would need some kind of needs basis. Maybe 
something as simple as, to get a /32 provide a creditable business plan 
for more than 200 sites in two years, and for a /40 more than 1 site, 
for a /48 a site with more than 256 host, and anyone my request a /56. 
I'd need to think about what you should need to qualify for a /24, but I 
believe it must be more than the ability to write a $100,000 check every 
year.  Maybe, 10,000+ sites assigned within a current /32 or creditable 
business plan for more that 20,000 sites within 2 years.

Need ("operational need", not need as in "I want") is a basic tenet of 
RFC 2050, if we walk away from that we will have big problems.  That 
said we definitely need to change our current IPv4-style thinking on the 
subject of need for IPv6.  And, to be honest I'm not sure anyone truly 
understands the full implications of HD-ratios long-term. But, that 
doesn't mean throwing out the baby out with the bathwater.

- This could encourage the Big Guys to filter the little guys, by maybe 
making it to easy for them to do so.

- As a result, this could encourage the smaller guys to try to get 
bigger blocks than they really need in order to justify having a routing 
slot and not being filtered.

Think this threw a little, by making filtering this easy based on size, 
if there isn't some kind of needs based justification, and there is a 
pricing scheme like described then wouldn't we end up with something 
like you need to pay for a /32 for anyone to accept your route as a 
serious player.  If you can't afford $10,000 they go away you have to be 
my customer.

- Mergers and Acquisitions

Getting people to properly report mergers and acquisitions seems hard 
enough now.  Requiring the single block per size per organization, and 
therefore renumbering, seems like an additional disincentive to proper 
reporting.  Leading to more bad registry data, less transparency to what 
is really going on, and possibly degrading operational response.

- This would make ARIN's IPv6 policies way different than all the other 
RIRs.

William partially answered this; paraphrasing his answer, maybe we 
shouldn't shift the whole world all at once.  There might be an 
advantage for one RIR to go down this road first.

Somebody going first makes sense to me, backing out if it turns out to 
be a bad idea.  But, what if the rest of the world thinks it is a bad 
idea and has no intention to follow to begin with?  Should we still go 
down this road anyway?

- 6.10.1 Micro-allocations for Critical Infrastructure are not moot and 
should be preserved, this allows network operators to create special 
filtering rule, if they wish, for these Critical Infrastructures.  It 
seems prudent to keep some special ranges such as these.  Maybe they 
should be renamed to Critical Infrastructure Allocations.  The term 
micro-allocations probably doesn't fit anymore, but they are still 
Critical Infrastructure.

However, I agree that 6.10.2 Micro-allocations for Internal 
Infrastructure should probably be deprecated.

- These changes are very radical.  It is at least very difficult, if not 
impossible, to predict what the real outcome of these policy changes 
will be.  I believe this will fix some of the issues we have today, but 
I'm not sure we will not just replace those problems with bigger or more 
intractable ones.  Are there some incremental steps we can take toward 
this vision, without jumping off the cliff into a brave but unknown new 
world?

How about creating PI /40 allocations for small providers and PI /40 
assignments for large multi-site end-users, and blessing providers to 
make similar PA assignments.  In Dearborn we couldn't get consensus to 
change the 200 customer in two year justification required to get a /32. 
  And there is nothing explicit for larger multi-site end users either. 
  A /40 seems to fit the bill.

In the Internet2 world we assigned GigaPOPs /40s out of the Internet2 
/32, it worked well. Especially, in the early day of IPv6, when people 
still believed in tighter providers based aggregation for IPv6.  Think 
of GigaPOPs as regional cooperative providers aggregating end-sites into 
the national member owned Internet2 backbone.

This isn't so radical, and if the rest of the world doesn't follow it 
still might be a good idea anyway.

----

One last reminder;

If you have opinions or arguments why the AC should or should not put 
this proposal on its docket you should speak up by the middle of next week.

Thank you for your participation.



Member Services wrote:
> 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.
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================