[arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process
Warren Johnson
warren at wholesaleinternet.com
Mon Nov 16 16:28:12 EST 2009
I guess at some point post-runout we will have a clearer understanding of
the time frames we're dealing with. We could make a decision at that point.
-----Original Message-----
From: Davis, Terry L [mailto:terry.l.davis at boeing.com]
Sent: Monday, November 16, 2009 3:13 PM
To: 'Warren Johnson'; arin-ppml at arin.net
Subject: RE: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process
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.
More information about the ARIN-PPML
mailing list