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

[Davis, Terry L]

Warren

There are some proposals out there to do that, but there are also folks working hard on the seamless layer too.  I can't imagine that developing another network protocol to replace v6 would take less than another decade which is time I don't think we have.

My personal hope is that this transition will have forced us to learn (re-learn) basic software engineering.  With our current generation of apps, we embedded layer 3 networking in our layer 7 apps; thus we can not change the transport without changing the apps.  I'm now a big proponent of "network aware" applications with application level security utilizing an isolation messaging layer which allows routing of message traffic over any transport available.

Take care
Terry

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Warren Johnson
> Sent: Monday, November 16, 2009 12:54 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation
> Process
>
> Instead of spending the next two decades trying to get people migrated
> over
> maybe we should just scrap v6 and create "v7" and make it backwards
> compatible with v4.  I guess we're not at that point yet because we just
> don't know what's going to happen post-runout.
>
>
>
> -----Original Message-----
> From: Davis, Terry L [mailto:terry.l.davis at boeing.com]
> Sent: Monday, November 16, 2009 2:50 PM
> To: 'Warren Johnson'; arin-ppml at arin.net
> Subject: RE: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation
> Process
>
> Warren
>
> My answer would be "we didn't have enough software types in the room
> during
> the discussions on creating v6" to point out the implications of that
> fact.
>
> Although a long term v6 advocate, I did not fully realize what we had done
> to ourselves till I did a Master's project paper on v6 migration a few
> years
> ago.  After doing that, I realized that with current transition
> technologies, we end up with an ugly v4-v6 transition layer consisting of
> many different v4-v6 technologies (and some at the individual app level)
> in
> our IT infrastructure architecture for probably decades.  And that layer
> also has very severe implications for an IT security infrastructure.
>
> If we had a simple straight forward transition mechanism, v6 would have
> taken off years ago.  Hindsight is 20-20; foresight though isn't (maybe
> 20-2000).
>
> Take care
> Terry
>
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> > On Behalf Of Warren Johnson
> > Sent: Monday, November 16, 2009 12:30 PM
> > To: arin-ppml at arin.net
> > Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation
> > Process
> >
> > Stupid question here: why wasn't v6 designed to be backwards
> > compatible with v4?  Just not possible?
> >
> >
> >
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> > On Behalf Of Davis, Terry L
> > Sent: Monday, November 16, 2009 2:03 PM
> > To: 'Steve Bertrand'; arin-ppml at arin.net
> > Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation
> > Process
> >
> > Steve
> >
> > I like it also.  One of our biggest problems is that we simply do not
> > have enough really large scale IPv6 deployments around the globe to
> > begin to understand all the problems or to come up with better
> > migration/integration plans between v4 and v6.  This should spur more
> > use IPv6; as it is today, not even the green field startups are using
> > v6 and this should tell us something about our current assumptions and
> > policies.
> >
> > In retrospect, by not having a seamless, easy to use method, of
> > allowing
> > v4
> > to v6 communications, we have made deploying v6 very costly; migrating
> > our millions of v4 based apps to v6 comes with both a huge price tag
> > for opening and dual-stacking them and a corresponding "risk" factor
> > for business continuity associated with that work.
> >
> > Take care
> > Terry
> >
> > > -----Original Message-----
> > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> > > On Behalf Of Steve Bertrand
> > > Sent: Friday, November 13, 2009 8:20 PM
> > > To: arin-ppml at arin.net
> > > Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation
> > > Process
> > >
> > > Member Services wrote:
> > >
> > > > Policy Proposal 103: Change IPv6 Allocation Process
> > >
> > > I'm very, very interested in this proposal, and would like to give
> > > it a bump in hopes that it will spur more feedback and discussion
> > > than what it's received thus far.
> > >
> > > Truthfully, I would like to get a feel on the number of people who
> > > like it (I certainly do). If anyone has disregarded or overlooked
> > > the proposal because of the recommended financial figures, please
> > > let that be known as well.
> > >
> > > Complete original proposal message has been left intact below.
> > >
> > > Steve
> > >
> > >
> > > > Proposal Originator: William Herrin
> > > >
> > > > Proposal Version: 1.0
> > > >
> > > > Date: 9 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 section 6.9 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.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.
> > > >
> > > > Add NRPM section 6.5.9 as follows:
> > > >
> > > > 6.5.9 IPv6 Allocations
> > > >
> > > > 6.5.9.1 ARIN shall allocate IPv6 address blocks in exactly and
> > > > only the following denominations: /56, /48, /40, /32, /24
> > > >
> > > > 6.5.9.2 No utilization-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.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.
> > > >
> > > > 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 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 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.
> > > >
> > > > 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: immediate
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > 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.
> > >
> > > _______________________________________________
> > > 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.
> > _______________________________________________
> > 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.
> >
> >
> > _______________________________________________
> > 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.
>
>
> _______________________________________________
> 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.