From dean at av8.com  Fri Feb  1 18:17:03 2008
From: dean at av8.com (Dean Anderson)
Date: Fri, 1 Feb 2008 18:17:03 -0500 (EST)
Subject: [ppml] /29 limit for ARIN SWIP whois (fwd)
Message-ID: <Pine.LNX.4.44.0801132331020.12494-100000@citation2.av8.net>


---------- Forwarded message ----------
Date: Sun, 13 Jan 2008 23:28:40 -0500 (EST)
From: Dean Anderson <dean at av8.com>
To: 
Subject: Re: [ppml] ***POSSIBLE SPAM*** Re:  /29 limit for ARIN SWIP whois

On Sun, 13 Jan 2008, xxx wrote:

> Dean Anderson wrote:
> 
> > BTW, Legacy block's don't have to comply with the RSA. "No SWIP" is just
> > one of the many rights that one loses under the Legacy RSA.  Don't sign
> > the Legacy RSA. Contact me, instead.
> 
> It's too late for my organization (xxx), as we've already signed the 
> Legacy RSA.  We were concerned about losing control over our Class x
> address space if we didn't, 

It may not be too late. But spread the word not to sign the Legacy RSA.

The agreement is probably too unfair to enforce.  You should contact
your lawyer immediately though. Your reasoning (fear of losing control)
indicates that you may have been extorted into signing an unfavorable
agreement improperly transferring your property rights to ARIN. This
probably a violation of the Hobbs Act.  See this page on the Hobbs Act:

2403 Hobbs Act -- Extortion By Force, Violence, or Fear

http://www.usdoj.gov/usao/eousa/foia_reading_room/usam/title9/crm02403.htm

The defense of 'right' is prevented by the previous performance by ARIN,
Network Solutions, and SRI (DDN-NIC) of in-addr services and whois
services. ARIN was also asked by ARIN members to get a formal legal
opinion on its right before taking applications or contracts, but ARIN
refused to do so.  ARIN has no reason to think its actions are lawful.
It seems that ARIN has no right to induce such fear, and no right to
transfer rights under such circumstances.

The case Kremen v. Cohen [337 F.3d 1024; (2003)  See also
http://www.nyls.edu/pages/1806.asp] established that domain names are
intangible property subject to conversion.  By the same reasoning, IP
blocks are similarly intangible property. There's more though. Also, In
Kremen v. Cohen, Kremen asserted Network Solutions violated a third
party beneficial contract with the Government. They lost on that claim.
There are stricter standards to meet in order for finding that the
government (as opposed to private parties) created a third party
beneficial contract. ARIN, by contrast with Network Solutions, took over
operations from ICANN (a private corporation operating IANA). ICANN is
not a government agency, so finding that ARIN has a third party
beneficial contract with ICANN is easier than the case with Network
Solutions, which took over from the government.


> and the legacy terms seem pretty reasonable to me.  However, I'd be
> interested in learning why you think it's not a good idea.

I think you didn't read the contract closely, and didn't know what your 
legacy rights were to begin with. Here are some few highlights:

1. The Legacy RSA (LRSA) gives ARIN the right to remove the Class B from
you.  They didn't have that privilege before.

2. ARIN can demand information on your customers. They didn't have that 
right before.

3. "If Legacy Applicant does not provide ARIN with required information,
assistance, or cooperation that ARIN requests, ARIN may [not give you
more space or may terminate the agreement and keep the class B (see
Section 14(e) termination for cause by ARIN--arin gets the number
resources.)]

4. You "agree" that there are no property rights in IP Blocks.  You 
didn't have that before the agreement; you had property rights in 
intangible property.

5. Section 15(i): "This Legacy Agreement will be construed as if it was
jointly drafted by both parties and may not be construed against either
one"  Basically, you "agree" not to challenge the agreement as unfair.  
[I think this provision demonstrates unfairness, actually.]

It goes on and on. ARIN had no rights over Legacy space before.  
Instead, ARIN had obligations that it undertook to obtain the privileges
of operating the registry.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   









From maier1 at us.ibm.com  Fri Feb  1 19:03:38 2008
From: maier1 at us.ibm.com (Robert Maier)
Date: Fri, 1 Feb 2008 17:03:38 -0700
Subject: [ppml] Robert Maier is currently out of the office until 2/4
Message-ID: <OF78D5768A.4C75B5AE-ON872573E3.0000554C-872573E3.0000554C@us.ibm.com>


I will be out of the office starting  02/01/2008 and will not return until
02/04/2008.

Hello, I'll be out of the office Friday 2/1, returning Monday 2/4. If you
have an urgent matter, please contact the AOD service center at
877-737-3700.
Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20080201/eb4de2bd/attachment.html>

From info at arin.net  Mon Feb  4 10:47:45 2008
From: info at arin.net (Member Services)
Date: Mon, 04 Feb 2008 10:47:45 -0500
Subject: [ppml] Deadline for Policy Proposals - 7 February 2008
Message-ID: <47A733A1.7000506@arin.net>

The ARIN XXI Public Policy Meeting will take place 7-8 April 2008 in
Denver. New policy proposals must be submitted by 23:59 EST, 7 February
2008, in order to be considered by the ARIN Advisory Council for
possible inclusion on the ARIN XXI agenda. The ARIN Internet Resource
Policy Evaluation Process requires that proposed policies must be
submitted at least 60 days prior to the meeting.

Those who wish to propose new ARIN number resource policies or
modifications to existing policies must submit a Policy Proposal
Template. Send the template via e-mail to policy at arin.net.

The Policy Proposal Template can be found at:
http://www.arin.net/policy/irpep_template.html

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)




From info at arin.net  Wed Feb  6 10:28:16 2008
From: info at arin.net (Member Services)
Date: Wed, 06 Feb 2008 10:28:16 -0500
Subject: [ppml] ARIN Mailing Lists
Message-ID: <47A9D210.4020409@arin.net>

Dean Anderson's privilege to post and participate in ARIN's various mail 
lists has been suspended until April 7, 2008, 8:00am EST. This decision 
was taken in accordance with the procedures in ARIN's Acceptable Use 
Policy (AUP). Mr. Anderson was previously warned, in writing, in 
November to stop making per se defamatory comments. He recently made 
another "untrue and per se defamatory posting alleging criminal activity."

Regards,

Raymond A. Plzak
President & CEO
The American Registry for Internet Numbers (ARIN)





From Ed.Lewis at neustar.biz  Wed Feb  6 13:50:25 2008
From: Ed.Lewis at neustar.biz (Edward Lewis)
Date: Wed, 6 Feb 2008 13:50:25 -0500
Subject: [ppml] [arin-discuss] Justifiable Censorship?
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAxF+vIc38fkif37Futwk6FcKAAA
	AQAAAAchQNqSc59Uy7o6Gp6NOaLQEAAAAA@xtratyme.com>
References: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAxF+vIc38fkif37Futwk6FcKAAA
	AQAAAAchQNqSc59Uy7o6Gp6NOaLQEAAAAA@xtratyme.com>
Message-ID: <a06240802c3cfad67e437@[10.31.65.153]>

At 12:02 -0600 2/6/08, Kyle Ackerman wrote:

>We live in a country where people can burn flags, where protesters can
>waste considerable time and money, where we have the right to voice our
>opinion.

Prior to the past few ARIN Open Policy Meetings there were long 
discussions on the many proposals put before us, all germane to the 
task ARIN has set out to fulfill.  13 proposals were covered, 12 of 
them new.

We are about 24 or 48 hours before the deadline for new proposals to 
get discussed at the next OPM.  There are currently 8 open proposals, 
6 of them carried forward from the previous meeting.  Just 2 of them 
new.

It's not conclusive evidence of anything, it's not a scientific poll, 
but something seems to have derailed the functioning of ARIN.  I 
looked up these because, it seemed to me, that there's a lot less to 
read in preparation for the next OPM, less that any meeting in recent 
years.

Yet there are so many posts to the ARIN lists.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Mail archives, backups.  Sometimes I think the true beneficiaries of
standards work are the suppliers of disk drives.


From stephen at sprunk.org  Wed Feb  6 14:26:34 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Wed, 6 Feb 2008 13:26:34 -0600
Subject: [ppml] [arin-discuss] Justifiable Censorship?
References: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAxF+vIc38fkif37Futwk6FcKAAAAQAAAAchQNqSc59Uy7o6Gp6NOaLQEAAAAA@xtratyme.com>
	<a06240802c3cfad67e437@[10.31.65.153]>
Message-ID: <00bc01c868f8$c6ce0df0$543816ac@atlanta.polycom.com>

Thus spake "Edward Lewis" <Ed.Lewis at neustar.biz>
> Prior to the past few ARIN Open Policy Meetings there were long
> discussions on the many proposals put before us, all germane to the
> task ARIN has set out to fulfill.  13 proposals were covered, 12 of
> them new.
>
> We are about 24 or 48 hours before the deadline for new proposals to
> get discussed at the next OPM.  There are currently 8 open proposals,
> 6 of them carried forward from the previous meeting.  Just 2 of them
> new.
>
> It's not conclusive evidence of anything, it's not a scientific poll,
> but something seems to have derailed the functioning of ARIN.  I
> looked up these because, it seemed to me, that there's a lot less to
> read in preparation for the next OPM, less that any meeting in recent
> years.
>
> Yet there are so many posts to the ARIN lists.

In contrast, I find that PPML has been comparatively dead for the last 
couple of months.  There were a large number of controversial proposals (as 
well as many editorial ones from the AC or staff) in the last cycle which 
generated quite a bit of discussion, but they were largely dealt with in 
ABQ.  There's only been a few proposals since, which generated a fair bit of 
debate (much of it tangential).  Unless someone's secretly screening 
proposals before they get to PPML (which I do not believe), it just seems 
that everyone decided to take a break for the holidays or we've simply run 
out of new things to propose for a while.

One might consider the latter to be a sign that there's no remaining 
significant problems the community sees with the NPRM.  I'm sure that claim 
will generate some comments of its own, but IMHO that's a good thing: if you 
disagree with my statement, please speak up so that someone can help you get 
a proposal in the works, hopefully before the deadline.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking 



From owen at delong.com  Wed Feb  6 14:57:31 2008
From: owen at delong.com (Owen DeLong)
Date: Wed, 6 Feb 2008 11:57:31 -0800
Subject: [ppml] Proposal for SWIP/RWHOIS extension beyond /29
Message-ID: <A40BD06A-C329-4539-B676-8AE9B5060270@delong.com>

The ARIN AC is about to consider the next steps for the proposal at  
the end of this
message.

In light of that, we would like to get any feedback from the community  
on this
proposal and especially whether it has support or not from members of  
the
community.

In your messages, please indicate if you support the proposal and make
any comments you wish as to why/why not.

Thanks,

Owen DeLong
ARIN AC

> ## * ##
>
>
> Policy Proposal Name: SWIP support for smaller than /29 assignments
>
> Author: Joe Maimon
>
> Proposal Version: 1
>
> Submission Date: Jan 16, 2008
>
> Proposal type: modify
>
> Policy term: permanent
>
> Policy statement:
>
> 4.2.2.1.2.)
>
> "
> ISPs must provide reassignment information on the entire previously
> allocated block(s) via SWIP or RWHOIS server for /29 or larger blocks.
> For blocks smaller
>
> than /29 and for internal space, ISPs should provide utilization data
> using the table format described in Section 4.2.3.7.5.
> "
>
> Replace with
>
> "
> ISPs must provide reassignment information on the entire previously
> allocated block(s) via SWIP or RWHOIS server for /29 or larger blocks.
> For blocks smaller
>
> than /29 and for internal space, ISPs should provide utilization data
> either via SWIP or RWHOIS server or by using the table format  
> described
> in Section 4.2.3.7.5.
> "
>
> 4.2.2.2.1.)
>
> "
> Utilization for blocks smaller than /29 can be documented using the
> format described in Section 4.2.3.7.5.
> "
>
> Replace with
>
> "
> Utilization for blocks smaller than /29 can be documented via SWIP or
> RWHOIS server or by using the format described in Section 4.2.3.7.5.
> "
>
> 4.2.3.7.2.)
>
> "
> For blocks smaller than /29 and for internal space, ISPs should  
> provide
> utilization data using the format described in Section 4.2.3.7.5.
> "
>
> Replace with
>
> "
> For blocks smaller than /29 and for internal space, ISPs should  
> provide
> utilization data via SWIP or RWHOIS server or by using the format
> described in Section 4.2.3.7.5.
> "
>
> 4.2.3.7.5.) Accounting for additional utilization
>
> "
> The following format should be used to provide the required  
> information
> for utilization of blocks smaller than /29 and for describing internal
> networks:
> "
>
> Replace with
>
> "
> The following format should be used to provide the required  
> information
> for utilization of blocks smaller than /29 and for describing internal
> networks when either SWIP or RWHOIS server is not used:
> "
>
> Rationale:
>
> With increasing frequency of smaller than /29 assignements to  
> customers,
> the ability for ISP's to utilize SWIP or RWHOIS as a single
> comprehensive source of their utilization data should be supported. To
> implement this policy change, ARIN SWIP would need to no longer reject
> SWIP templates smaller then /29.
>
> Timetable for implementation: Immediate

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20080206/961bbc4f/attachment.html>

From dsd at servervault.com  Wed Feb  6 15:05:02 2008
From: dsd at servervault.com (Divins, David)
Date: Wed, 6 Feb 2008 15:05:02 -0500
Subject: [ppml] Proposal for SWIP/RWHOIS extension beyond /29
In-Reply-To: <A40BD06A-C329-4539-B676-8AE9B5060270@delong.com>
References: <A40BD06A-C329-4539-B676-8AE9B5060270@delong.com>
Message-ID: <F8B974E70BDE1745ABB27AF04788FA0004D2DB7C@mail1.dulles.sv.int>

Can I please get a clarification, is the following an accurate
statement:
 
This policy simply allows SWIP longer than /29 but does not manadate
such reporting.
 
Thanks,
dsd

David Divins
Principal Engineer
ServerVault Corp.
(703) 652-5955 

________________________________

From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of
Owen DeLong
Sent: Wednesday, February 06, 2008 2:58 PM
To: Public Policy Mailing List
Subject: ***POSSIBLE SPAM*** [ppml] Proposal for SWIP/RWHOIS extension
beyond /29


The ARIN AC is about to consider the next steps for the proposal at the
end of this 
message.

In light of that, we would like to get any feedback from the community
on this
proposal and especially whether it has support or not from members of
the
community.

In your messages, please indicate if you support the proposal and make
any comments you wish as to why/why not.

Thanks,

Owen DeLong
ARIN AC


	## * ##
	



	Policy Proposal Name: SWIP support for smaller than /29
assignments
	


	Author: Joe Maimon
	


	Proposal Version: 1
	


	Submission Date: Jan 16, 2008
	


	Proposal type: modify
	


	Policy term: permanent
	


	Policy statement:
	


	4.2.2.1.2.)
	


	"
	

	ISPs must provide reassignment information on the entire
previously
	

	allocated block(s) via SWIP or RWHOIS server for /29 or larger
blocks.
	

	For blocks smaller
	


	than /29 and for internal space, ISPs should provide utilization
data
	

	using the table format described in Section 4.2.3.7.5.
	

	"
	


	Replace with
	


	"
	

	ISPs must provide reassignment information on the entire
previously
	

	allocated block(s) via SWIP or RWHOIS server for /29 or larger
blocks.
	

	For blocks smaller
	


	than /29 and for internal space, ISPs should provide utilization
data
	

	either via SWIP or RWHOIS server or by using the table format
described
	

	in Section 4.2.3.7.5.
	

	"
	


	4.2.2.2.1.)
	


	"
	

	Utilization for blocks smaller than /29 can be documented using
the
	

	format described in Section 4.2.3.7.5.
	

	"
	


	Replace with
	


	"
	

	Utilization for blocks smaller than /29 can be documented via
SWIP or
	

	RWHOIS server or by using the format described in Section
4.2.3.7.5.
	

	"
	


	4.2.3.7.2.)
	


	"
	

	For blocks smaller than /29 and for internal space, ISPs should
provide
	

	utilization data using the format described in Section
4.2.3.7.5.
	

	"
	


	Replace with
	


	"
	

	For blocks smaller than /29 and for internal space, ISPs should
provide
	

	utilization data via SWIP or RWHOIS server or by using the
format
	

	described in Section 4.2.3.7.5.
	

	"
	


	4.2.3.7.5.) Accounting for additional utilization
	


	"
	

	The following format should be used to provide the required
information
	

	for utilization of blocks smaller than /29 and for describing
internal
	

	networks:
	

	"
	


	Replace with
	


	"
	

	The following format should be used to provide the required
information
	

	for utilization of blocks smaller than /29 and for describing
internal
	

	networks when either SWIP or RWHOIS server is not used:
	

	"
	


	Rationale:
	


	With increasing frequency of smaller than /29 assignements to
customers,
	

	the ability for ISP's to utilize SWIP or RWHOIS as a single
	

	comprehensive source of their utilization data should be
supported. To
	

	implement this policy change, ARIN SWIP would need to no longer
reject
	

	SWIP templates smaller then /29.
	


	Timetable for implementation: Immediate
	



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20080206/0e0ae984/attachment.html>

From owen at delong.com  Wed Feb  6 15:15:52 2008
From: owen at delong.com (Owen DeLong)
Date: Wed, 6 Feb 2008 12:15:52 -0800
Subject: [ppml] Proposal for SWIP/RWHOIS extension beyond /29
In-Reply-To: <F8B974E70BDE1745ABB27AF04788FA0004D2DB7C@mail1.dulles.sv.int>
References: <A40BD06A-C329-4539-B676-8AE9B5060270@delong.com>
	<F8B974E70BDE1745ABB27AF04788FA0004D2DB7C@mail1.dulles.sv.int>
Message-ID: <9E33F99A-2B97-4BFD-95C6-57576B83ED8A@delong.com>

Yes... That is my understanding of it as well.

Owen

On Feb 6, 2008, at 12:05 PM, Divins, David wrote:

> Can I please get a clarification, is the following an accurate  
> statement:
>
> This policy simply allows SWIP longer than /29 but does not manadate  
> such reporting.
>
> Thanks,
> dsd
> David Divins
> Principal Engineer
> ServerVault Corp.
> (703) 652-5955
>
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf  
> Of Owen DeLong
> Sent: Wednesday, February 06, 2008 2:58 PM
> To: Public Policy Mailing List
> Subject: ***POSSIBLE SPAM*** [ppml] Proposal for SWIP/RWHOIS  
> extension beyond /29
>
> The ARIN AC is about to consider the next steps for the proposal at  
> the end of this
> message.
>
> In light of that, we would like to get any feedback from the  
> community on this
> proposal and especially whether it has support or not from members  
> of the
> community.
>
> In your messages, please indicate if you support the proposal and make
> any comments you wish as to why/why not.
>
> Thanks,
>
> Owen DeLong
> ARIN AC
>
>> ## * ##
>>
>>
>> Policy Proposal Name: SWIP support for smaller than /29 assignments
>>
>> Author: Joe Maimon
>>
>> Proposal Version: 1
>>
>> Submission Date: Jan 16, 2008
>>
>> Proposal type: modify
>>
>> Policy term: permanent
>>
>> Policy statement:
>>
>> 4.2.2.1.2.)
>>
>> "
>> ISPs must provide reassignment information on the entire previously
>> allocated block(s) via SWIP or RWHOIS server for /29 or larger  
>> blocks.
>> For blocks smaller
>>
>> than /29 and for internal space, ISPs should provide utilization data
>> using the table format described in Section 4.2.3.7.5.
>> "
>>
>> Replace with
>>
>> "
>> ISPs must provide reassignment information on the entire previously
>> allocated block(s) via SWIP or RWHOIS server for /29 or larger  
>> blocks.
>> For blocks smaller
>>
>> than /29 and for internal space, ISPs should provide utilization data
>> either via SWIP or RWHOIS server or by using the table format  
>> described
>> in Section 4.2.3.7.5.
>> "
>>
>> 4.2.2.2.1.)
>>
>> "
>> Utilization for blocks smaller than /29 can be documented using the
>> format described in Section 4.2.3.7.5.
>> "
>>
>> Replace with
>>
>> "
>> Utilization for blocks smaller than /29 can be documented via SWIP or
>> RWHOIS server or by using the format described in Section 4.2.3.7.5.
>> "
>>
>> 4.2.3.7.2.)
>>
>> "
>> For blocks smaller than /29 and for internal space, ISPs should  
>> provide
>> utilization data using the format described in Section 4.2.3.7.5.
>> "
>>
>> Replace with
>>
>> "
>> For blocks smaller than /29 and for internal space, ISPs should  
>> provide
>> utilization data via SWIP or RWHOIS server or by using the format
>> described in Section 4.2.3.7.5.
>> "
>>
>> 4.2.3.7.5.) Accounting for additional utilization
>>
>> "
>> The following format should be used to provide the required  
>> information
>> for utilization of blocks smaller than /29 and for describing  
>> internal
>> networks:
>> "
>>
>> Replace with
>>
>> "
>> The following format should be used to provide the required  
>> information
>> for utilization of blocks smaller than /29 and for describing  
>> internal
>> networks when either SWIP or RWHOIS server is not used:
>> "
>>
>> Rationale:
>>
>> With increasing frequency of smaller than /29 assignements to  
>> customers,
>> the ability for ISP's to utilize SWIP or RWHOIS as a single
>> comprehensive source of their utilization data should be supported.  
>> To
>> implement this policy change, ARIN SWIP would need to no longer  
>> reject
>> SWIP templates smaller then /29.
>>
>> Timetable for implementation: Immediate
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the  
> ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at info at arin.net  
> if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20080206/7394e83a/attachment.html>

From jmaimon at chl.com  Wed Feb  6 15:49:54 2008
From: jmaimon at chl.com (Joe Maimon)
Date: Wed, 06 Feb 2008 15:49:54 -0500
Subject: [ppml] Proposal for SWIP/RWHOIS extension beyond /29
In-Reply-To: <9E33F99A-2B97-4BFD-95C6-57576B83ED8A@delong.com>
References: <A40BD06A-C329-4539-B676-8AE9B5060270@delong.com>	<F8B974E70BDE1745ABB27AF04788FA0004D2DB7C@mail1.dulles.sv.int>
	<9E33F99A-2B97-4BFD-95C6-57576B83ED8A@delong.com>
Message-ID: <47AA1D72.8090007@chl.com>

Yes, that was the intent behind the proposal.

Thanks,

Joe

Owen DeLong wrote:
> Yes... That is my understanding of it as well.
> 
> Owen
> 
> On Feb 6, 2008, at 12:05 PM, Divins, David wrote:
> 
>> Can I please get a clarification, is the following an accurate statement:
>>  
>> This policy simply allows SWIP longer than /29 but does not manadate 
>> such reporting.
>>  
>> Thanks,
>> dsd
>>
>> David Divins
>> Principal Engineer
>> ServerVault Corp.
>> (703) 652-5955
>>
>> ------------------------------------------------------------------------
>> *From:* ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] *On 
>> Behalf Of *Owen DeLong
>> *Sent:* Wednesday, February 06, 2008 2:58 PM
>> *To:* Public Policy Mailing List
>> *Subject:* ***POSSIBLE SPAM*** [ppml] Proposal for SWIP/RWHOIS 
>> extension beyond /29
>>
>> The ARIN AC is about to consider the next steps for the proposal at 
>> the end of this
>> message.
>>
>> In light of that, we would like to get any feedback from the community 
>> on this
>> proposal and especially whether it has support or not from members of the
>> community.
>>
>> In your messages, please indicate if you support the proposal and make
>> any comments you wish as to why/why not.
>>
>> Thanks,
>>
>> Owen DeLong
>> ARIN AC
>>
>>> ## * ##
>>
>>>
>>>
>>> Policy Proposal Name: SWIP support for smaller than /29 assignments
>>
>>>
>>> Author: Joe Maimon
>>
>>>
>>> Proposal Version: 1
>>
>>>
>>> Submission Date: Jan 16, 2008
>>
>>>
>>> Proposal type: modify
>>
>>>
>>> Policy term: permanent
>>
>>>
>>> Policy statement:
>>
>>>
>>> 4.2.2.1.2.)
>>
>>>
>>> "
>>
>>> ISPs must provide reassignment information on the entire previously
>>
>>> allocated block(s) via SWIP or RWHOIS server for /29 or larger blocks.
>>
>>> For blocks smaller
>>
>>>
>>> than /29 and for internal space, ISPs should provide utilization data
>>
>>> using the table format described in Section 4.2.3.7.5.
>>
>>> "
>>
>>>
>>> Replace with
>>
>>>
>>> "
>>
>>> ISPs must provide reassignment information on the entire previously
>>
>>> allocated block(s) via SWIP or RWHOIS server for /29 or larger blocks.
>>
>>> For blocks smaller
>>
>>>
>>> than /29 and for internal space, ISPs should provide utilization data
>>
>>> either via SWIP or RWHOIS server or by using the table format described
>>
>>> in Section 4.2.3.7.5.
>>
>>> "
>>
>>>
>>> 4.2.2.2.1.)
>>
>>>
>>> "
>>
>>> Utilization for blocks smaller than /29 can be documented using the
>>
>>> format described in Section 4.2.3.7.5.
>>
>>> "
>>
>>>
>>> Replace with
>>
>>>
>>> "
>>
>>> Utilization for blocks smaller than /29 can be documented via SWIP or
>>
>>> RWHOIS server or by using the format described in Section 4.2.3.7.5.
>>
>>> "
>>
>>>
>>> 4.2.3.7.2.)
>>
>>>
>>> "
>>
>>> For blocks smaller than /29 and for internal space, ISPs should provide
>>
>>> utilization data using the format described in Section 4.2.3.7.5.
>>
>>> "
>>
>>>
>>> Replace with
>>
>>>
>>> "
>>
>>> For blocks smaller than /29 and for internal space, ISPs should provide
>>
>>> utilization data via SWIP or RWHOIS server or by using the format
>>
>>> described in Section 4.2.3.7.5.
>>
>>> "
>>
>>>
>>> 4.2.3.7.5.) Accounting for additional utilization
>>
>>>
>>> "
>>
>>> The following format should be used to provide the required information
>>
>>> for utilization of blocks smaller than /29 and for describing internal
>>
>>> networks:
>>
>>> "
>>
>>>
>>> Replace with
>>
>>>
>>> "
>>
>>> The following format should be used to provide the required information
>>
>>> for utilization of blocks smaller than /29 and for describing internal
>>
>>> networks when either SWIP or RWHOIS server is not used:
>>
>>> "
>>
>>>
>>> Rationale:
>>
>>>
>>> With increasing frequency of smaller than /29 assignements to customers,
>>
>>> the ability for ISP's to utilize SWIP or RWHOIS as a single
>>
>>> comprehensive source of their utilization data should be supported. To
>>
>>> implement this policy change, ARIN SWIP would need to no longer reject
>>
>>> SWIP templates smaller then /29.
>>
>>>
>>> Timetable for implementation: Immediate
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the ARIN 
>> Public Policy
>> Mailing List (PPML at arin.net <mailto:PPML at arin.net>).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml
>> Please contact the ARIN Member Services Help Desk at 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 (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues.


From stephen at sprunk.org  Wed Feb  6 16:13:32 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Wed, 6 Feb 2008 15:13:32 -0600
Subject: [ppml] Proposal for SWIP/RWHOIS extension beyond /29
References: <A40BD06A-C329-4539-B676-8AE9B5060270@delong.com><F8B974E70BDE1745ABB27AF04788FA0004D2DB7C@mail1.dulles.sv.int>
	<9E33F99A-2B97-4BFD-95C6-57576B83ED8A@delong.com>
Message-ID: <011e01c86906$5c90c190$543816ac@atlanta.polycom.com>

Thus spake "Owen DeLong" <owen at delong.com>
> On Feb 6, 2008, at 12:05 PM, Divins, David wrote:
>> Can I please get a clarification, is the following an accurate
>> statement:
>>
>> This policy simply allows SWIP longer than /29 but does not manadate
>> such reporting.
>
> Yes... That is my understanding of it as well.

Based on that, I support the proposal.  I think the wording is suboptimal, 
but it appears to achieve the stated goal, which I agree with.

I'm interested in staff's assessment of whether it would result in a 
non-trivial expense increase due to additional server load, since that 
appears to be the reason that longer SWIPs weren't allowed in the first 
place.  That wouldn't necessarily change my mind, but it's something we 
should know.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking 



From briand at ca.afilias.info  Wed Feb  6 16:29:03 2008
From: briand at ca.afilias.info (Brian Dickson)
Date: Wed, 06 Feb 2008 16:29:03 -0500
Subject: [ppml] Proposal for SWIP/RWHOIS extension beyond /29
In-Reply-To: <011e01c86906$5c90c190$543816ac@atlanta.polycom.com>
References: <A40BD06A-C329-4539-B676-8AE9B5060270@delong.com><F8B974E70BDE1745ABB27AF04788FA0004D2DB7C@mail1.dulles.sv.int>	<9E33F99A-2B97-4BFD-95C6-57576B83ED8A@delong.com>
	<011e01c86906$5c90c190$543816ac@atlanta.polycom.com>
Message-ID: <47AA269F.5020901@ca.afilias.info>

Stephen Sprunk wrote:
> Thus spake "Owen DeLong" <owen at delong.com>
>   
>> On Feb 6, 2008, at 12:05 PM, Divins, David wrote:
>>     
>>> Can I please get a clarification, is the following an accurate
>>> statement:
>>>
>>> This policy simply allows SWIP longer than /29 but does not manadate
>>> such reporting.
>>>       
>> Yes... That is my understanding of it as well.
>>     
>
> Based on that, I support the proposal.  I think the wording is suboptimal, 
> but it appears to achieve the stated goal, which I agree with.
>
>   
Ditto.
> I'm interested in staff's assessment of whether it would result in a 
> non-trivial expense increase due to additional server load, since that 
> appears to be the reason that longer SWIPs weren't allowed in the first 
> place.  That wouldn't necessarily change my mind, but it's something we 
> should know.
>
>   
+1

Brian Dickson
> S
>
> Stephen Sprunk         "God does not play dice."  --Albert Einstein
> CCIE #3723         "God is an inveterate gambler, and He throws the
> K5SSS        dice at every possible opportunity." --Stephen Hawking 
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues.
>   



From tedm at ipinc.net  Wed Feb  6 16:42:13 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 6 Feb 2008 13:42:13 -0800
Subject: [ppml] [arin-discuss] Justifiable Censorship?
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAxF+vIc38fkif37Futwk6FcKAAAAQAAAAchQNqSc59Uy7o6Gp6NOaLQEAAAAA@xtratyme.com>
Message-ID: <NABBJOELMNGNJNGPKDDOOEGFHFAA.tedm@ipinc.net>



>-----Original Message-----
>From: arin-discuss-bounces at arin.net
>[mailto:arin-discuss-bounces at arin.net]On Behalf Of Kyle Ackerman
>Sent: Wednesday, February 06, 2008 10:02 AM
>To: arin-discuss at arin.net
>Cc: ppml at arin.net
>Subject: [arin-discuss] Justifiable Censorship?
>
>
>Mr. Plzak,
>
>Many of us would have to agree that Dean Anderson can be outright
>annoying.  He appears to have a significant amount of time to pursue

Just a FYI for anyone considering to post to this thread - Dean's
right to POST has been suspended.  I'm sure he is still getting
mail from the list and is no doubt tickled pink with all the concern
shown over this.  Just keep in mind that by arguing over the suspension
your merely feeding a personality that craves attention.

Ted


From info at arin.net  Thu Feb  7 12:21:40 2008
From: info at arin.net (Member Services)
Date: Thu, 07 Feb 2008 12:21:40 -0500
Subject: [ppml] ARIN XXI Registration Open
Message-ID: <47AB3E24.8060607@arin.net>

ARIN invites you to join us 6-9 April 2008 in Denver, Colorado for the 
ARIN XXI Public Policy and Members Meeting. The meeting will be held at 
the Grand Hyatt Denver and registration is now open. Links to meeting, 
hotel, and remote participation information, as well as other meeting 
information is available at http://www.arin.net/ARIN-XXI/. The special 
room rate of $189(USD) single/double occupancy is available until 14 
March 2008. Reserve your room now as space is limited.

ARIN holds open, biannual Public Policy and Members Meetings, to provide 
an opportunity for the entire Internet community to contribute to 
Internet number resource policy discussion and development, network with 
colleagues, and attend workshops and tutorials. Current policy proposals 
up for discussion at this meeting are available at:

http://www.arin.net/policy/proposals/proposal_archive.html


ARIN XXI Overview

* Sunday, 6 April- Sunday activities will include a luncheon for first 
time ARIN meeting attendees, a session entitled ?Understanding ARIN?s 
Legacy Registration Services Agreement? presented by ARIN General 
Counsel Steven M. Ryan ESQ., the Open Policy Hour, and the 9th Annual 
Foosball Tournament.

* Monday, 7 April ? ARIN Public Policy Meeting, Day 1, evening ARIN Social

* Tuesday, 8 April - ARIN Public Policy Meeting, Day 2

* Wednesday, 9 April - ARIN Members Meeting (open to all ARIN XXI attendees)

ARIN will once again offer remote participation via webcast for those 
that are unable to attend. Remote participation includes the ability to 
send comments to the Public Policy Meeting. Additional agenda details 
and more information about ARIN XXI will be posted on our website as we 
get closer to the meeting, so check back often!

Regards,

Member Services Department
American Registry for Internet Numbers(ARIN)





From info at arin.net  Thu Feb  7 12:36:21 2008
From: info at arin.net (Member Services)
Date: Thu, 07 Feb 2008 12:36:21 -0500
Subject: [ppml] Policy Proposal 2007-22: Expand timeframe of Additional
 Requests - Second Last Call
Message-ID: <47AB4195.6050904@arin.net>

Policy Proposal 2007-22
Expand timeframe of Additional Requests

It has come to the ARIN Advisory Council's (AC) attention that the wrong
version of policy proposal 2007-22 was reviewed in last call. The
history of the proposal is:

Original version:
http://lists.arin.net/pipermail/ppml/2007-August/008838.html
Staff assessment:
http://lists.arin.net/pipermail/ppml/2007-October/009473.html
Presented at ARIN XX:
http://www.arin.net/meetings/minutes/ARIN_XX/PDF/thursday/dan_alexander_2007-22.pdf
Posted for Last Call:
http://lists.arin.net/pipermail/ppml/2007-October/009612.html

The version posed for last call should have included the updated text
presented at ARIN XX. The three versions of text are:

Current Policy statement:

"After a subscriber has been a member of ARIN for one year they may
choose to request a six-month supply of IP addresses."

Original text of proposal mistakenly posted during last call::

"After an organization has been an ARIN member in good standing for one
year, they may choose to request up to a 12 month supply of IP addresses."

Changed text presented and polled upon in Albuquerque:

"After an organization has been a subscriber member of ARIN for one
year, they may choose to request up to a 12 month supply of IP addresses."

Due to this error the AC has decided to send the correct text to the
PPML mailing list for a second Last Call period to ensure the correct
version of the propoal has been considered.

Please accept the AC's apoligies for this mistake.

The policy proposal text is provided below and is also available at:
http://www.arin.net/policy/proposals/2007_22.html

Comments are encouraged. All comments should be provided to
ppml at arin.net. This last call will expire at 23:59, Eastern Time, 20
February 2008.

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal 2007-22
Expand timeframe of Additional Requests

Author: Dan Alexander

Proposal type: modify

Policy term: permanent

Policy statement:

The proposal is to modify section 4.2.4.4 of the NRPM

Current wording: "After a subscriber has been a member of ARIN for one
year they may choose to request a six-month supply of IP addresses."

Change to: "After an organization has been a subscriber member of ARIN
for one year, they may choose to request up to a 12 month supply of IP
addresses."

Rationale:

Currently, all RIR's provide organizations with at least a 12 month
supply of IPv4 address space when making subsequent requests, with the
exception of the ARIN region. The primary reason for this change is for
continuity among all RIR. In doing so, all established organizations
have a more consistent access to IP resources.

The adjustment does not change demand on IPv4 address space. It only
changes the frequency in which established organizations need to request
address space.

This would allow for fewer potential aggregates allocated to an
organization providing more consolidated routing announcements.

This does not change the requirement on new organizations where
established growth trends have yet to be established.

Timetable for implementation: Immediate



From jmorrison at bogomips.com  Thu Feb  7 14:26:37 2008
From: jmorrison at bogomips.com (John Paul Morrison)
Date: Thu, 07 Feb 2008 11:26:37 -0800
Subject: [ppml] patching bigmama
Message-ID: <47AB5B6D.5050301@bogomips.com>

putting some patches on, no reboot required


From info at arin.net  Thu Feb  7 16:31:27 2008
From: info at arin.net (Member Services)
Date: Thu, 07 Feb 2008 16:31:27 -0500
Subject: [ppml] ARIN Advisory Council Policy Proposal
Message-ID: <47AB78AF.9050303@arin.net>

In October of 2007 the ARIN Board of Trustees asked the Advisory Council
to consider a set of broad questions around the depletion of the free
pool of IPv4 addresses, the transition to IPv6 for Internet address
needs in the future, and ARIN's possible role in easing the transition.

Over the past few years the AC has spent a great deal of time reflecting
on these issues as a group, as individuals, and in consultation with the
community.  One output from this process is a policy proposal the AC
will be submitting for consideration at the next meeting.  We are
proposing some changes to existing ARIN policy regarding the transfer of
IP address block registrations between subscribers.  This will allow for
the emergence of transfers in IPv4 address space, with ARIN to provide a
listing service for address blocks available for transfer under the
revised transfer policy.

We are aware that this proposal, if adopted, will mark a major change in
ARIN's role in the community and the Internet. While the AC as a whole
believes the policy proposal to be well written and carefully
considered, we are not unanimous in all aspects of the policy proposal,
nor even are we united in the view that the proposed policy should be
adopted. We hope this policy proposal will spark debate and discussion,
and we look forward to getting additional community input on the topic.
  The AC as members of the ARIN community believe in the bottom up
process, and we urge the community to give this proposal the same
consideration and discussion they would give any other proposal.

We expect the AC's policy proposal to appear on ppml on Monday February
11th.  We encourage all members of the community to carefully read the
proposal and post comments.

Respectfully,

Leo Bicknell, Chair
For the ARIN Advisory Council



From info at arin.net  Fri Feb  8 15:11:12 2008
From: info at arin.net (Member Services)
Date: Fri, 08 Feb 2008 15:11:12 -0500
Subject: [ppml] Policy Proposal: 200-reduction-6.5.1.1.d - Withdrawn by
	author
Message-ID: <47ACB760.3040302@arin.net>

Policy Proposal Name: 200-reduction-6.5.1.1.d

The author withdrew their proposal. The proposal is closed.

The policy proposal text is provided below and is also available at:
http://lists.arin.net/pipermail/ppml/2007-October/009581.html

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal Name: 200-reduction-6.5.1.1.d

Author: Brian Dickson

Proposal Version: 1

Submission Date: Oct 18, 2007

Proposal type: modify

Policy term: permanent

Policy statement:

In 6.5.1.1 d), where 2007-25 proposes:

"be an existing, known ISP in the ARIN region or have a plan for making
at least 200 end-site assignments to other organizations within 5 years."

replace with"
"be an existing, known ISP in the ARIN region or have a plan for making
at least 20 end-site assignments to other organizations, or for
providing IPv6 transit to one or more IPv6 PI blocks belonging to other
organizations, within 5 years."

Rationale:

The purpose of the text is to establish reasonable ways for an ISP to
demonstrate that it is in fact an ISP. Any of the above listed
conditions satisfy that need, and the intent is to avoid having the text
of the policy prevent any legitimate ISP from receiving an initial IPv6
allocation.

It does lower the bar, but in a justifiable fashion. It is not necessary
for an ISP to have lots of PA assignments. It is necessary for an ISP to
be announcing PA *or* PI blocks to the internet, and relaxing the
criteria to recognize both possibilities jointly, makes the policy
reflect the actual realities for any number of large regional ISPs, who
may have sold off portions of their business but who still operate
significant infrastructure.

Timetable for implementation: Immediate



From info at arin.net  Fri Feb  8 15:18:02 2008
From: info at arin.net (Member Services)
Date: Fri, 08 Feb 2008 15:18:02 -0500
Subject: [ppml] Policy Proposal 2007-23: End Policy for IANA IPv4
 allocations to RIRs - Revised Text
Message-ID: <47ACB8FA.4090002@arin.net>

Policy Proposal 2007-23, End Policy for IANA IPv4 allocations to RIRs,
has been revised. This proposal is open for discussion on this mailing
list and will be on the agenda at the upcoming ARIN Public Policy meeting.

The current policy proposal text is provided below and is also available
at: http://www.arin.net/policy/proposals/2007_23.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


### * ###


Policy Proposal 2007-23
End Policy for IANA IPv4 allocations to RIRs

Proposal Version: Version 2 (8 February 2008)

Author: Roque Gagliano, ANTEL; Francisco Obispo, CENIT; Haitham EL
Nakhal, MCIT; Didier Allain Kla, ISOC Cote d'Ivoire; JPNIC IPv4
countdown policy team: - Akinori Maemura - Akira Nakagawa - Izumi
Okutani - Kosuke Ito - Kuniaki Kondo - Shuji Nakamura - Susumu Sato -
Takashi Arano - Tomohiro Fujisaki - Tomoya Yoshida - Toshiyuki Hosaka

Proposal type: new

Policy term: temporary

Policy statement:

This is a revised version of;

prop-046: IPv4 countdown policy proposal

prop-051: Global policy for the allocation of the remaining IPv4 address
space

This policy describes the process for the allocation of the remaining
IPv4 space from IANA to the RIRs. When a minimum amount of available
space is reached, one /8 will be allocated from IANA to each RIR,
replacing the current IPv4 allocation policy.

In order to fulfill the requirements of this policy, at the time it is
adopted, one /8 will be reserved by IANA for each RIR. The reserved
allocation units will no longer be part of the available space at the
IANA pool. IANA will also reserve one /8 to any new RIR at the time it
is recognized.

The process for the allocation of the remaining IPv4 space is divided in
two consecutive phases:

4.1. Existing Policy Phase:

During this phase IANA will continue allocating IPv4 addresses to he
RIRs using the existing allocation policy. This phase will continue
until a request for IPv4 address space from any RIR to IANA either
cannot be fulfilled with the remaining IPv4 space available at the IANA
pool or can be fulfilled but leaving the IANA remaining IPv4 pool empty.

This will be the last IPv4 address space request that IANA will accept
from any RIR. At this point the next phase of the process will be initiated.

4.2. Exhaustion Phase:

IANA will automatically allocate the reserved IPv4 allocation units to
each RIR (one /8 to each one) and respond to the last request with the
remaining available allocation units at the IANA pool (M units).

4.2.1. Size of the final IPv4 allocations:

During this phase IANA will automatically allocate one /8 to each RIR
from the reserved space defined in this policy. IANA will also allocate
M allocation units to the RIR that submitted the last request for IPv4
addresses.

4.2.2. Allocation of the remaining IPv4 Address space:

After the completion of the evaluation of the final request for IPv4
addresses, IANA MUST:

A) Immediately notify the NRO about the activation of the second phase
of this policy.

B) Proceed to allocate M allocation units to the RIR that submitted the
last request for IPv4 address space.

C) Proceed to allocate one /8 to each RIR from the reserved space.

Rationale: The exhaustion of IPv4 address space is projected to take
place within the next few years. This proposal seeks to focus on
measures that should be taken globally in the address management area in
order to prepare for the situation in all RIR regions.

To continue applying a global coordinated policy for distribution of the
last piece(s) of each RIR's unallocated address block does not match the
reality of the situation in each RIR region.

Issues each RIR region will face during the exhaustion period vary by
region as the level of development of IPv4 and IPv6 are widely
different. As a result, applying a global co-ordinated policy may not
adequately address issues in a certain region while it could be work for
the others.

For example, in a region where late comers desperately need even small
blocks of IPv4 addresses to access to the IPv4 Internet, a policy that
defines the target of allocations/assignments of IPv4 address space to
be late comers would be appropriate in such region. This would allow
availablilty of IPv4 address space for such requirements for more years.

Another example comes from difference in IPv6 deployment rate. For a
region where IPv6 deployment rate is low, measures may be necessary to
prolong IPv4 address life for the existing business as well as for new
businesses until networks are IPv6 ready. Some regions may have strong
needs to secure IPv4 address space for translators.

A globally coordinated policy which addresses all the issues listed
above to meet the needs for all RIR regions may result in not solving
issues in any of the regions.

Timetable for implementation: after approval by ICANN board



From michael.dillon at bt.com  Fri Feb  8 16:00:30 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 8 Feb 2008 21:00:30 -0000
Subject: [ppml] Policy Proposal 2007-23: End Policy for IANA IPv4
	allocations to RIRs - Revised Text
In-Reply-To: <47ACB8FA.4090002@arin.net>
References: <47ACB8FA.4090002@arin.net>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B001EC571B@E03MVC4-UKBR.domain1.systemhost.net>


> This policy describes the process for the allocation of the remaining
> IPv4 space from IANA to the RIRs. When a minimum amount of 
> available space is reached, one /8 will be allocated from 
> IANA to each RIR, replacing the current IPv4 allocation policy.

This is a deeply unfair policy. It means that when we near the point
of exhaustion of IPv4, IANA will give some people a 3 year supply
and some people a 3 month supply.

It would be much fairer to reduce the size of IANA allocations from
a full /8 to a smaller block size. In this way IANA can ensure that
everyone runs out of IPv4 addresses at the same time.

I suggest that the block size be based on the RIR whose yearly
allocation of IPv4 addresses is the smallest, and be some defined
fraction of that RIR's yearly fraction. For instance, if the 
5 RIRs have the following annual allocation rates:

A. /7
B. /8
C. /16
D. /10
E. /9

Then the smallest RIR issues a /16 in one year. For instance we
could say that when there are no more than 5 full /8 blocks left
in the IANA free pool (an easy and unambiguous measure) that
we would change the IANA allocation size from /8 to x times 
the minimal of the 5 RIR yearly allocation rates. In this case
it would be x times /16. We could either define x as a constant
or have some formula to define x. If we decide that x should be 1,
the the IANA allocation size shifts from /8 to /16.

This does not mean that an RIR cannot receive more than a single
/16 from IANA. It means that we move to a system more like the
RIR allocations to ISPs/LIRs. If RIR A can show that it needs
5 /16s to handle the next half-year of allocations then that is what
they should receive.

Blocks would be adjacent to previous ones whenever possible.

But 2007-23 is bad policy, and inherently unfair. I strongly oppose it.

--Michael Dillon


From arin-contact at dirtside.com  Fri Feb  8 18:02:49 2008
From: arin-contact at dirtside.com (William Herrin)
Date: Fri, 8 Feb 2008 18:02:49 -0500
Subject: [ppml] Policy Proposal 2007-23: End Policy for IANA IPv4
	allocations to RIRs - Revised Text
In-Reply-To: <47ACB8FA.4090002@arin.net>
References: <47ACB8FA.4090002@arin.net>
Message-ID: <3c3e3fca0802081502l43465e50oed16c816376ae097@mail.gmail.com>

On Feb 8, 2008 3:18 PM, Member Services <info at arin.net> wrote:
> Policy Proposal 2007-23
> End Policy for IANA IPv4 allocations to RIRs

As with the prior versions, I support this proposal. However slightly,
it yields more warning at the end. If we can't have the free pool last
forever, at least we can have an extra couple of months forewarning
when it finally hits.


On Feb 8, 2008 4:00 PM,  <michael.dillon at bt.com> wrote:
> This is a deeply unfair policy. It means that when we near the point
> of exhaustion of IPv4, IANA will give some people a 3 year supply
> and some people a 3 month supply.

With the sole exception of AfriNIC, the difference in supply won't
extend IPv4 long enough for any of the RIRs to care about This was
discussed ad nauseam in the last go-round. I for one have no problem
with the folks in Africa catching a mild break this once.


> I suggest that the block size be based on the RIR whose yearly
> allocation of IPv4 addresses is the smallest, and be some defined
> fraction of that RIR's yearly fraction. For instance, if the
> 5 RIRs have the following annual allocation rates:

This is neither more nor less fair than the authors' proposal of
exactly one /8 per RIR. It is more complicated and if offers an extra
formula whose fairness we'd have to argue about. Shouldn't registries
who've taken action to slow the consumption of IP addresses for, lets
call it less critical needs, shouldn't those registries have the
privilege of running out later than the rest?

Regards,
Bill Herrin


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


From drc at virtualized.org  Fri Feb  8 21:34:43 2008
From: drc at virtualized.org (David Conrad)
Date: Fri, 8 Feb 2008 18:34:43 -0800
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one."
Message-ID: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>

http://www.networkworld.com/news/2008/020608-ipv4-address-depletion.html

Regards,
-drc



From jcurran at istaff.org  Fri Feb  8 22:34:14 2008
From: jcurran at istaff.org (John Curran)
Date: Fri, 8 Feb 2008 22:34:14 -0500
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
 one."
In-Reply-To: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>
Message-ID: <p06240807c3d2cca2ae28@[192.168.3.76]>

At 6:34 PM -0800 2/8/08, David Conrad wrote:
>http://www.networkworld.com/news/2008/020608-ipv4-address-depletion.html

The article highlights results of a 2007 survey of network
managers' views on IPv6; one interesting data point is:
 
  "The number of survey respondents who said IPv6 does
    not provide benefits to their network infrastructures rose
    from 33% in 2005 to 49% in 2007."

Certainly reflects reality today, so the real question is when
does the carrier community tell their customers that increasing
numbers of new Internet sites are likely to be reachable only
via IPv6? 

They might want to resurvey the same network managers
immediately after that announcement.

/John


From randy at psg.com  Fri Feb  8 22:48:49 2008
From: randy at psg.com (Randy Bush)
Date: Sat, 09 Feb 2008 12:48:49 +0900
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
 one."
In-Reply-To: <p06240807c3d2cca2ae28@[192.168.3.76]>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>
	<p06240807c3d2cca2ae28@[192.168.3.76]>
Message-ID: <47AD22A1.4060803@psg.com>

John Curran wrote:
 > when does the carrier community tell their customers that increasing
 > numbers of new Internet sites are likely to be reachable only via
 > IPv6?

i am sure our marketing departments will all be in a rush to be the 
first to tell our customers we can not serve them.

randy


From drc at virtualized.org  Fri Feb  8 23:34:27 2008
From: drc at virtualized.org (David Conrad)
Date: Fri, 8 Feb 2008 20:34:27 -0800
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
	one."
In-Reply-To: <p06240807c3d2cca2ae28@[192.168.3.76]>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>
	<p06240807c3d2cca2ae28@[192.168.3.76]>
Message-ID: <FF6031B2-AAED-45DB-830B-2C0FD1E5439E@virtualized.org>

John,

On Feb 8, 2008, at 7:34 PM, John Curran wrote:
> when does the carrier community tell their customers that increasing
> numbers of new Internet sites are likely to be reachable only
> via IPv6?

When there actually are sites their customers might care about that  
are only reachable via IPv6?

Regards,
-drc



From jcurran at istaff.org  Fri Feb  8 23:36:32 2008
From: jcurran at istaff.org (John Curran)
Date: Fri, 8 Feb 2008 23:36:32 -0500
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
 one."
In-Reply-To: <FF6031B2-AAED-45DB-830B-2C0FD1E5439E@virtualized.org>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>
	<p06240807c3d2cca2ae28@[192.168.3.76]>
	<FF6031B2-AAED-45DB-830B-2C0FD1E5439E@virtualized.org>
Message-ID: <p0624080ac3d2ddfcbfd0@[192.168.3.76]>

At 8:34 PM -0800 2/8/08, David Conrad wrote:
>On Feb 8, 2008, at 7:34 PM, John Curran wrote:
>>when does the carrier community tell their customers that increasing
>>numbers of new Internet sites are likely to be reachable only
>>via IPv6?
>
>When there actually are sites their customers might care about that are only reachable via IPv6?

Wouldn't you actually want to tell them before, so that
they could have enough time to plan accordingly?

/John


From drc at virtualized.org  Fri Feb  8 23:40:04 2008
From: drc at virtualized.org (David Conrad)
Date: Fri, 8 Feb 2008 20:40:04 -0800
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
	one."
In-Reply-To: <p0624080ac3d2ddfcbfd0@[192.168.3.76]>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>
	<p06240807c3d2cca2ae28@[192.168.3.76]>
	<FF6031B2-AAED-45DB-830B-2C0FD1E5439E@virtualized.org>
	<p0624080ac3d2ddfcbfd0@[192.168.3.76]>
Message-ID: <4E6BB0C5-1E43-41A5-B0C7-08A38296868B@virtualized.org>

On Feb 8, 2008, at 8:36 PM, John Curran wrote:
> Wouldn't you actually want to tell them before, so that they could  
> have enough time to plan accordingly?

See Randy's comment.

Regards,
-drc



From gih at apnic.net  Fri Feb  8 23:42:52 2008
From: gih at apnic.net (Geoff Huston)
Date: Sat, 09 Feb 2008 15:42:52 +1100
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
 one."
In-Reply-To: <p0624080ac3d2ddfcbfd0@[192.168.3.76]>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>	<p06240807c3d2cca2ae28@[192.168.3.76]>	<FF6031B2-AAED-45DB-830B-2C0FD1E5439E@virtualized.org>
	<p0624080ac3d2ddfcbfd0@[192.168.3.76]>
Message-ID: <47AD2F4C.3040108@apnic.net>



John Curran wrote:
> At 8:34 PM -0800 2/8/08, David Conrad wrote:
>> On Feb 8, 2008, at 7:34 PM, John Curran wrote:
>>> when does the carrier community tell their customers that increasing
>>> numbers of new Internet sites are likely to be reachable only
>>> via IPv6?
>> When there actually are sites their customers might care about that are only reachable via IPv6?
> 
> Wouldn't you actually want to tell them before, so that
> they could have enough time to plan accordingly?

As far as I can tell right now there is a large amount of faith out 
there that all of this is just a beat up and that NATs will do the 
protocol translation magic without any major fuss. The reality injection 
will take some time in the face of the accumulated inertia we've 
accreted with IPv4.


   Geoff





From jcurran at istaff.org  Fri Feb  8 23:48:23 2008
From: jcurran at istaff.org (John Curran)
Date: Fri, 8 Feb 2008 23:48:23 -0500
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
 one."
In-Reply-To: <4E6BB0C5-1E43-41A5-B0C7-08A38296868B@virtualized.org>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>
	<p06240807c3d2cca2ae28@[192.168.3.76]>
	<FF6031B2-AAED-45DB-830B-2C0FD1E5439E@virtualized.org>
	<p0624080ac3d2ddfcbfd0@[192.168.3.76]>
	<4E6BB0C5-1E43-41A5-B0C7-08A38296868B@virtualized.org>
Message-ID: <p0624080cc3d2df6a15bd@[192.168.3.76]>

At 8:40 PM -0800 2/8/08, David Conrad wrote:
>On Feb 8, 2008, at 8:36 PM, John Curran wrote:
>>Wouldn't you actually want to tell them before, so that they could have enough time to plan accordingly?
>
>See Randy's comment.
>
>(randy) "i am sure our marketing departments will all be in a rush to be the first to tell our customers we can not serve them."

It impacts everyone at the same time; i.e. it doesn't
matter if it's your ISP or another one now using IPv6
for new customers, you won't be able to reach them
without IPv6 connectivity (or transition mechanism).

That's not telling customers you can't serve them, only
that they may need to also have IPv6 if they want to
reach the entire Internet, since pieces of it are using
IPv6 to connect.

/John


From randy at psg.com  Sat Feb  9 00:10:18 2008
From: randy at psg.com (Randy Bush)
Date: Sat, 09 Feb 2008 14:10:18 +0900
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
 one."
In-Reply-To: <p0624080cc3d2df6a15bd@[192.168.3.76]>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>	<p06240807c3d2cca2ae28@[192.168.3.76]>	<FF6031B2-AAED-45DB-830B-2C0FD1E5439E@virtualized.org>	<p0624080ac3d2ddfcbfd0@[192.168.3.76]>	<4E6BB0C5-1E43-41A5-B0C7-08A38296868B@virtualized.org>
	<p0624080cc3d2df6a15bd@[192.168.3.76]>
Message-ID: <47AD35BA.3030807@psg.com>

can we get real here?  what is the likelihood of someone *major* putting 
up a service only reachable over ipv6?

people will move when it is in their business interest to do so.  what 
does it take to make your enterprise dual stack?  john, how far have you 
progressed?  given the government is your big customer, i presume you 
have gone in early and big.  care to tell us how easy it was and how 
much it really benefits beyond a check-box?

we went in early, in fact the earliest commercial roll.  and we have 
regressed, i.e. some services are not maintained over ipv6 that used to 
be because no one used them and they caused pain.  try an smtp service 
with no ipv6 dnsbl, etc..  we're working on changing that, but it's not 
easy to justify.

drc, with great political and bureaucratic pain, has been rolling ipv6. 
so he has his money where his mouth is.  how are the rest of the mouths 
here?

roam.psg.com:/usr/home/randy> dig +short arin.net. mx
10 smtp2.arin.net.
20 smtp1.arin.net.
30 smtp3.arin.net.
roam.psg.com:/usr/home/randy> host smtp1.arin.net
smtp1.arin.net has address 192.149.252.33
roam.psg.com:/usr/home/randy> host smtp2.arin.net
smtp2.arin.net has address 192.149.252.32
roam.psg.com:/usr/home/randy> host smtp3.arin.net
smtp3.arin.net has address 199.43.0.197

before getting on high horse, check for saddle or be damned good at 
bareback on a damned tough horse.

randy


From bicknell at ufp.org  Sat Feb  9 08:39:43 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Sat, 9 Feb 2008 08:39:43 -0500
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
	one."
In-Reply-To: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>
Message-ID: <20080209133943.GA54068@ussenterprise.ufp.org>

In a message written on Fri, Feb 08, 2008 at 06:34:43PM -0800, David Conrad wrote:
> http://www.networkworld.com/news/2008/020608-ipv4-address-depletion.html

I've posted similar comments elsewhere, but why not here as well....

IPv6 is not a flag day; there is a dual stack transition period and
ALG's can easily bridge the two.  There are more than a few enterprise
networks designed with RFC1918 space internally and a small DMZ
network with dual homed mail servers, VPN servers, web proxy servers,
and the like.  At least in the short term these enterprises will
be well served by getting a /48 from their upstream, putting IPv6
on the outside interfaces of the 10 or so boxes in the DMZ, and
leaving the rest of their 10,000 internal systems alone on IPv4
RFC1918 space.

They will be able to send e-mail and browse web sites on IPv6 only
boxes just fine.  The VPN servers will allow someone with IPv6 only
at home to create an IPv4 tunnel back to the internal corporate
network.

I think we need to be careful with our message.  IPv6 is a "right
now" problem for ISP's and for major content providers.  However
IPv6 may also be a "in another couple of years" problem for an
Enterprise in the situation I describe above.  We need to focus our
efforts where they will do the most good.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20080209/0dbbc088/attachment.bin>

From jcurran at istaff.org  Sat Feb  9 08:45:47 2008
From: jcurran at istaff.org (John Curran)
Date: Sat, 9 Feb 2008 08:45:47 -0500
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
 one."
In-Reply-To: <47AD35BA.3030807@psg.com>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>
	<p06240807c3d2cca2ae28@[192.168.3.76]>
	<FF6031B2-AAED-45DB-830B-2C0FD1E5439E@virtualized.org>
	<p0624080ac3d2ddfcbfd0@[192.168.3.76]>
	<4E6BB0C5-1E43-41A5-B0C7-08A38296868B@virtualized.org>
	<p0624080cc3d2df6a15bd@[192.168.3.76]> <47AD35BA.3030807@psg.com>
Message-ID: <p0624080dc3d35bae3648@[192.168.3.76]>

At 2:10 PM +0900 2/9/08, Randy Bush wrote:
>can we get real here?  what is the likelihood of someone *major* putting up a service only reachable over ipv6?

I expect the likelihood is pretty high, once they have no other choice?

>people will move when it is in their business interest to do so.  what does it take to make your enterprise dual stack?  john, how far have you progressed?  given the government is your big customer, i presume you have gone in early and big.  care to tell us how easy it was and how much it really benefits beyond a check-box?
>...
>before getting on high horse, check for saddle or be damned good at bareback on a damned tough horse.
>(queries over at arin.net)

Randy -

My day job is over here, thanks...

[...:~] jcurran% dig +short servervault.com aaaa
2610:60::1002:203:47ff:fe73:b1f7
2610:60::1002:203:47ff:fe73:b21f

We haven't put the MX records in yet, but that is in progress.

And to answer your specific question, IPv6 enablement has
been painless so far.

/John






From jcurran at istaff.org  Sat Feb  9 08:53:58 2008
From: jcurran at istaff.org (John Curran)
Date: Sat, 9 Feb 2008 08:53:58 -0500
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
 one."
In-Reply-To: <20080209133943.GA54068@ussenterprise.ufp.org>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>
	<20080209133943.GA54068@ussenterprise.ufp.org>
Message-ID: <p06240800c3d35f480e79@[192.168.3.76]>

At 8:39 AM -0500 2/9/08, Leo Bicknell wrote:
>IPv6 is not a flag day; there is a dual stack transition period and
>ALG's can easily bridge the two.  There are more than a few enterprise
>networks designed with RFC1918 space internally and a small DMZ
>network with dual homed mail servers, VPN servers, web proxy servers,
>and the like.  At least in the short term these enterprises will
>be well served by getting a /48 from their upstream, putting IPv6
>on the outside interfaces of the 10 or so boxes in the DMZ, and
>leaving the rest of their 10,000 internal systems alone on IPv4
>RFC1918 space.
>
>They will be able to send e-mail and browse web sites on IPv6 only
>boxes just fine.  The VPN servers will allow someone with IPv6 only
>at home to create an IPv4 tunnel back to the internal corporate
>network.

Complete agreement.   In fact, there's an I-D out there
</draft-jcurran-v6transitionplan-02.txt> where I outline
this sort of overall Internet transition.

>I think we need to be careful with our message.  IPv6 is a "right
>now" problem for ISP's and for major content providers.  However
>IPv6 may also be a "in another couple of years" problem for an
>Enterprise in the situation I describe above.  We need to focus our
>efforts where they will do the most good.

Alas, "being careful" with the message doesn't actually sell
newpapers or generate webclicks...  (which is what we see
from the referenced article).  The loss of availability of large
contiguous address blocks from the free pool is most
certainly not an issue for the enterprise network manager,
it's an issue the ISP community.   The catch is that unless
the ISP starts advocacy of IPv6 enablement of their existing
customers edge servers (web, mail), then they won't have
the ability to use to use IPv6 to connect new clients when
they need to...

/John


From randy at psg.com  Sat Feb  9 08:56:42 2008
From: randy at psg.com (Randy Bush)
Date: Sat, 09 Feb 2008 22:56:42 +0900
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
 one."
In-Reply-To: <p0624080dc3d35bae3648@[192.168.3.76]>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>
	<p06240807c3d2cca2ae28@[192.168.3.76]>
	<FF6031B2-AAED-45DB-830B-2C0FD1E5439E@virtualized.org>
	<p0624080ac3d2ddfcbfd0@[192.168.3.76]>
	<4E6BB0C5-1E43-41A5-B0C7-08A38296868B@virtualized.org>
	<p0624080cc3d2df6a15bd@[192.168.3.76]> <47AD35BA.3030807@psg.com>
	<p0624080dc3d35bae3648@[192.168.3.76]>
Message-ID: <47ADB11A.3070409@psg.com>

> We haven't put the MX records in yet, but that is in progress.

and you don't seem to have the AAAAs for the nameservers.  when you do, 
you may have some hope of getting glue at the parent, as you use netsol 
as a registrar.  but do tell how that one goes.

> And to answer your specific question, IPv6 enablement has
> been painless so far.

i am impressed.  i think most of the rest of us have hit speedbumps.  we 
got over them, but we're glad we did not assign it to a grad student.  i 
suspect that we just have a different definition of painless.

randy


From jcurran at istaff.org  Sat Feb  9 09:14:10 2008
From: jcurran at istaff.org (John Curran)
Date: Sat, 9 Feb 2008 09:14:10 -0500
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
 one."
In-Reply-To: <47ADB11A.3070409@psg.com>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>
	<p06240807c3d2cca2ae28@[192.168.3.76]>
	<FF6031B2-AAED-45DB-830B-2C0FD1E5439E@virtualized.org>
	<p0624080ac3d2ddfcbfd0@[192.168.3.76]>
	<4E6BB0C5-1E43-41A5-B0C7-08A38296868B@virtualized.org>
	<p0624080cc3d2df6a15bd@[192.168.3.76]> <47AD35BA.3030807@psg.com>
	<p0624080dc3d35bae3648@[192.168.3.76]> <47ADB11A.3070409@psg.com>
Message-ID: <p06240801c3d36248c266@[192.168.3.76]>

At 10:56 PM +0900 2/9/08, Randy Bush wrote:
>>We haven't put the MX records in yet, but that is in progress.
>
>and you don't seem to have the AAAAs for the nameservers.  when you do, you may have some hope of getting glue at the parent, as you use netsol as a registrar.  but do tell how that one goes.

>From the Nanog thread, it's clear the versign/registry can handle such,
so if it's just phone loops with netsol/registrar to get them to push the
glue, I've got quite a bit of patience...  I'll make sure to provide any
updates/insights to Jeroen for the Sixxs-IPv6glue page.  Who knows,
if we end up changing registrars over it, it'll be one more data point
for netsol to consider support.

>>And to answer your specific question, IPv6 enablement has
>>been painless so far.
>
>i am impressed.  i think most of the rest of us have hit speedbumps.  we got over them, but we're glad we did not assign it to a grad student.  i suspect that we just have a different definition of painless.

I expect it's going to be several years before any of this can
be safely delegated.

/John


From randy at psg.com  Sat Feb  9 09:35:26 2008
From: randy at psg.com (Randy Bush)
Date: Sat, 09 Feb 2008 23:35:26 +0900
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
 one."
In-Reply-To: <p06240801c3d36248c266@[192.168.3.76]>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>
	<p06240807c3d2cca2ae28@[192.168.3.76]>
	<FF6031B2-AAED-45DB-830B-2C0FD1E5439E@virtualized.org>
	<p0624080ac3d2ddfcbfd0@[192.168.3.76]>
	<4E6BB0C5-1E43-41A5-B0C7-08A38296868B@virtualized.org>
	<p0624080cc3d2df6a15bd@[192.168.3.76]> <47AD35BA.3030807@psg.com>
	<p0624080dc3d35bae3648@[192.168.3.76]> <47ADB11A.3070409@psg.com>
	<p06240801c3d36248c266@[192.168.3.76]>
Message-ID: <47ADBA2E.9030303@psg.com>

> From the Nanog thread, it's clear the versign/registry can handle
> such, so if it's just phone loops with netsol/registrar to get them
> to push the glue, I've got quite a bit of patience.

i flagged as a <troll> the nanog posting that started the thread
because, though i know i can subvert or manipulate the system to my
needs, that is neither a fair or useful exercise.  we need to make the
system work for everyone.  and simply and easily.

so i am gonna sit here and sulk and whine loud and long until the iana 
and opensrs/tucows fix it. :)

> I expect it's going to be several years before any of this can be
> safely delegated.

the key thing we, who have some handle on the administrative and 
technical infrastructure, can do to ease transition is to remove the 
administrative obstacles to transition.  e.g. bleeping glue records.

we need more folk to tell the tales of their transition and the bumps 
they hit which could be removed so that we can look at smoothing them.

[ and no i do not mean encouraging routing table pollution because i
   deserve my own /32 so i will not have to renumber some day ]

randy


From Lee.Howard at stanleyassociates.com  Sat Feb  9 10:05:26 2008
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Sat, 9 Feb 2008 10:05:26 -0500
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently
	noone."
In-Reply-To: <FF6031B2-AAED-45DB-830B-2C0FD1E5439E@virtualized.org>
Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com>

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of David Conrad
> > when does the carrier community tell their customers that 
> increasing 
> > numbers of new Internet sites are likely to be reachable only via 
> > IPv6?
> 
> When there actually are sites their customers might care 
> about that are only reachable via IPv6?

Isn't it incumbent on the network newly connecting to the 
Internet to be able to communicate with the networks already
on it?  

I'm an ISP customer.  My IPv4 network isn't growing (maybe
I add a /28 per year).  Tell me why I care about IPv6.

Devils need advocates, too.

Lee



From jcurran at istaff.org  Sat Feb  9 10:16:01 2008
From: jcurran at istaff.org (John Curran)
Date: Sat, 9 Feb 2008 10:16:01 -0500
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently
 noone."
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com>
Message-ID: <p06240803c3d3720b741f@[192.168.3.76]>

At 10:05 AM -0500 2/9/08, Howard, W. Lee wrote:
>I'm an ISP customer.  My IPv4 network isn't growing (maybe
>I add a /28 per year).  Tell me why I care about IPv6.

You don't, until some ISP is wedged in such a tight corner that
they need to connect new customers with just IPv6 (because
they can't seem to obtain&route additional IPv4 space at any
realistic cost).

Your organization is likely to be able to get email to and from
new-co-IPv6-only and hopefully have them reach your website
via proxy (if the ISP is making an effort to minimize the pain),
but they won't be able to run any other applications which need
end-to-end IP...   Does this matter to you?  I guess it depends on
how a given business interacts with its suppliers and customers.

/John


From vixie at isc.org  Sat Feb  9 12:35:05 2008
From: vixie at isc.org (Paul Vixie)
Date: 09 Feb 2008 17:35:05 +0000
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently
	noone."
In-Reply-To: <p06240803c3d3720b741f@[192.168.3.76]>
References: <369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com>
	<p06240803c3d3720b741f@[192.168.3.76]>
Message-ID: <g3wspe3ueu.fsf@sa.vix.com>

jcurran at istaff.org (John Curran) writes:

> At 10:05 AM -0500 2/9/08, Howard, W. Lee wrote:
> >I'm an ISP customer.  My IPv4 network isn't growing (maybe
> >I add a /28 per year).  Tell me why I care about IPv6.
> 
> You don't, until some ISP is wedged in such a tight corner that
> they need to connect new customers with just IPv6 (because
> they can't seem to obtain&route additional IPv4 space at any
> realistic cost).
> ...

so there's an opportunity here for IPv4-rich ISP's to delay their
own IPv6 transition, including dual-stack, so as to acquire customers
and cash flows from IPv4-poor ISP's, during a transition period that
can be deliberately extended by such delay?
-- 
Paul Vixie


From jcurran at istaff.org  Sat Feb  9 12:52:54 2008
From: jcurran at istaff.org (John Curran)
Date: Sat, 9 Feb 2008 12:52:54 -0500
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
 one."
In-Reply-To: <g3wspe3ueu.fsf@sa.vix.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com>
	<p06240803c3d3720b741f@[192.168.3.76]> <g3wspe3ueu.fsf@sa.vix.com>
Message-ID: <p06240804c3d395dfda1f@[192.168.3.76]>

At 5:35 PM +0000 2/9/08, Paul Vixie wrote:
>so there's an opportunity here for IPv4-rich ISP's to delay their
>own IPv6 transition, including dual-stack, so as to acquire customers
>and cash flows from IPv4-poor ISP's, during a transition period that
>can be deliberately extended by such delay?

Interesting thought...  the answer is likely yes, but it actually may
be more likely an opportunity for smaller ISP's as it's the ratio of
supply over usage rate that determines how long one can stretch an
IPv4-only connectivity model.  It changes to more of an opportunity
for deeply-funded entities in the presence of a market-like transfer
policies.

/John


From bmanning at vacation.karoshi.com  Sat Feb  9 14:11:40 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Sat, 9 Feb 2008 19:11:40 +0000
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
	one."
In-Reply-To: <20080209133943.GA54068@ussenterprise.ufp.org>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>
	<20080209133943.GA54068@ussenterprise.ufp.org>
Message-ID: <20080209191140.GA18897@vacation.karoshi.com.>

> IPv6 is not a flag day; there is a dual stack transition period and
> ALG's can easily bridge the two.  There are more than a few enterprise
> networks designed with RFC1918 space internally and a small DMZ
> network with dual homed mail servers, VPN servers, web proxy servers,
> and the like.  At least in the short term these enterprises will
> be well served by getting a /48 from their upstream, putting IPv6
> on the outside interfaces of the 10 or so boxes in the DMZ, and
> leaving the rest of their 10,000 internal systems alone on IPv4
> RFC1918 space.
> 
> They will be able to send e-mail and browse web sites on IPv6 only
> boxes just fine.  The VPN servers will allow someone with IPv6 only
> at home to create an IPv4 tunnel back to the internal corporate
> network.
> 
> -- 
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/



	right model, but (imho) 180 degrees out of phase.
	think IPv6 only islands w/ a thin veneer of IPv4
	(say a /28) on the outside.  the ALG's to support
	this are not well defined, with the IETF reconsidering
	work in this area.  some call this NAT-PT, my favorite
	is the CERN-IVI box... which might see the light of
	day 3q08...

--bill



From jcurran at istaff.org  Sat Feb  9 14:36:31 2008
From: jcurran at istaff.org (John Curran)
Date: Sat, 9 Feb 2008 14:36:31 -0500
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
 one."
In-Reply-To: <20080209191140.GA18897@vacation.karoshi.com.>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>
	<20080209133943.GA54068@ussenterprise.ufp.org>
	<20080209191140.GA18897@vacation.karoshi.com.>
Message-ID: <p06240808c3d3aff5f74e@[192.168.3.76]>

At 7:11 PM +0000 2/9/08, bmanning at vacation.karoshi.com wrote:
>
>	right model, but (imho) 180 degrees out of phase.
>	think IPv6 only islands w/ a thin veneer of IPv4
>	(say a /28) on the outside.  the ALG's to support
>	this are not well defined, with the IETF reconsidering
>	work in this area.  some call this NAT-PT, my favorite
>	is the CERN-IVI box... which might see the light of
>	day 3q08...

Bill -

Is it safe to presume that these are architectures proposed for
new customer connections?  It is hard to imagine an existing
Internet connected (via IPv4) site having any reason to evolve
its internal network into an IPv6 island intentionally in the near
future...

/John


From jcurran at istaff.org  Sat Feb  9 15:19:34 2008
From: jcurran at istaff.org (John Curran)
Date: Sat, 9 Feb 2008 15:19:34 -0500
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
 one."
In-Reply-To: <47AE0648.6090108@bogus.com>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>
	<20080209133943.GA54068@ussenterprise.ufp.org>
	<20080209191140.GA18897@vacation.karoshi.com.>
	<p06240808c3d3aff5f74e@[192.168.3.76]> <47AE0648.6090108@bogus.com>
Message-ID: <p0624080ac3d3b77abaa6@[192.168.3.76]>

At 12:00 PM -0800 2/9/08, Joel Jaeggli wrote:
>John Curran wrote:
>
>>Is it safe to presume that these are architectures proposed for
>>new customer connections?  It is hard to imagine an existing
>>Internet connected (via IPv4) site having any reason to evolve
>>its internal network into an IPv6 island intentionally in the near
>>future...
>
>Actually if you recover the v4 address currently consumed by your infrastructure you can continue to provide them to your customers which may by a substantial incentive to produce a network which is subtantially ipv6 only.

Interesting; this presumes that that one's willing to depart
from 'ships in the night' IPv4/IPv6 backbone approach, and
"transparently" alter the transport of your existing production
IPv4 customer traffic...

I'm not saying it won't happen (as depletion will eventually
force some very hard decisions) but it's not the traditional
risk-adverse approach used by the carriers, who loathe to do
anything that could result in even a small percentage of their
business customers complaining/switching/leaving.

Of course, it's opportunities like that which nimble/brave firms
use to gain advantage (and not dissimilar to the recent switch
that some carriers did with production POTS trunks to VoIP for
cost advantages...), and if there's sufficient IPv4 address space
to be to recovered, it could be one possible route which allows
IPv4 growth while also making progress on transition.

/John


From bmanning at vacation.karoshi.com  Sat Feb  9 17:56:08 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Sat, 9 Feb 2008 22:56:08 +0000
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
	one."
In-Reply-To: <p06240808c3d3aff5f74e@[192.168.3.76]>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>
	<20080209133943.GA54068@ussenterprise.ufp.org>
	<20080209191140.GA18897@vacation.karoshi.com.>
	<p06240808c3d3aff5f74e@[192.168.3.76]>
Message-ID: <20080209225608.GA20753@vacation.karoshi.com.>

On Sat, Feb 09, 2008 at 02:36:31PM -0500, John Curran wrote:
> At 7:11 PM +0000 2/9/08, bmanning at vacation.karoshi.com wrote:
> >
> >	right model, but (imho) 180 degrees out of phase.
> >	think IPv6 only islands w/ a thin veneer of IPv4
> >	(say a /28) on the outside.  the ALG's to support
> >	this are not well defined, with the IETF reconsidering
> >	work in this area.  some call this NAT-PT, my favorite
> >	is the CERN-IVI box... which might see the light of
> >	day 3q08...
> 
> Bill -
> 
> Is it safe to presume that these are architectures proposed for
> new customer connections?  It is hard to imagine an existing
> Internet connected (via IPv4) site having any reason to evolve
> its internal network into an IPv6 island intentionally in the near
> future...
> 
> /John

	i think a safe presumption is that this may be a 
	predominant structure as long as there are "arrogant
	twits" who maintain the fiction that only IPv4 transport
	is needed to get to their content/eyeballs.  e.g. if 
	facebook never supports IPv6 transport, this will be common.
	Facebook will never see IPv6 demand and claim "all is well"
	with IPv4 and the IPv6 hype is just that.

	I expect it will be common for new builds - so they can
	participate with that "other" address family.  Less common
	for existing builds - in part because the clients/content
	are already there.  UNTIL ... some compelling new content
	or feature is brought up ONLY on IPv6... then the installed
	base has to decide how to move.

	the middle ground, that you have espoused, where some content/
	applications are available over -both- address families - will
	be the predominant mode - but such will be an operational 
	suite from outerdarkness...  because the transports are non-overlapping.


--bill
	


From jcurran at istaff.org  Sat Feb  9 18:34:53 2008
From: jcurran at istaff.org (John Curran)
Date: Sat, 9 Feb 2008 18:34:53 -0500
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
 one."
In-Reply-To: <20080209225608.GA20753@vacation.karoshi.com.>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>
	<20080209133943.GA54068@ussenterprise.ufp.org>
	<20080209191140.GA18897@vacation.karoshi.com.>
	<p06240808c3d3aff5f74e@[192.168.3.76]>
	<20080209225608.GA20753@vacation.karoshi.com.>
Message-ID: <p06240801c3d3e0df6e6b@[192.168.3.76]>

At 10:56 PM +0000 2/9/08, bmanning at vacation.karoshi.com wrote:
>
>	i think a safe presumption is that this may be a
>	predominant structure as long as there are "arrogant
>	twits" who maintain the fiction that only IPv4 transport
>	is needed to get to their content/eyeballs.  e.g. if
>	facebook never supports IPv6 transport, this will be common.
>	Facebook will never see IPv6 demand and claim "all is well"
>	with IPv4 and the IPv6 hype is just that.

Facebook, Yahoo!, Google, MSN, Youtube, .... the list goes on and on.
I wouldn't expect any of them to see measurable demand for IPv6
until there's a sizable IPv6-only user community.

An IPv6-only user community is definitely going to happen (my own
opinion) but it's years away and occurs when ISP's have no real cost-
effective alternative for extending growth via IPv4.  Even if some user
communities go dual-stack before then, that's not exactly a compelling
reason for content providers to invest in IPv6 infrastructure since dual-
stack implies that they can already get the same users over IPv4.

Can you explain why there will be a significant base of IPv6-only users
before then?

Without IPv6-only users or some compelling benefits for IPv6 versus IPv4
transport, it's hard to see why the content community would invest ahead
of time.  Existing enterprises, consumers, and content providers all have
working infrastructure that still meets their needs once there is no readily
available free pool; it's the ISP business growth model that gets impacted
and hence the ISP community that needs to drive any desired transition.

/John


From dwhite at olp.net  Sat Feb  9 18:51:06 2008
From: dwhite at olp.net (Dan White)
Date: Sat, 09 Feb 2008 17:51:06 -0600
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
 one."
In-Reply-To: <20080209225608.GA20753@vacation.karoshi.com.>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>	<20080209133943.GA54068@ussenterprise.ufp.org>	<20080209191140.GA18897@vacation.karoshi.com.>	<p06240808c3d3aff5f74e@[192.168.3.76]>
	<20080209225608.GA20753@vacation.karoshi.com.>
Message-ID: <47AE3C6A.3050605@olp.net>

bmanning at vacation.karoshi.com wrote:
> 	i think a safe presumption is that this may be a 
> 	predominant structure as long as there are "arrogant
> 	twits" who maintain the fiction that only IPv4 transport
> 	is needed to get to their content/eyeballs.  e.g. if 
> 	facebook never supports IPv6 transport, this will be common.
> 	Facebook will never see IPv6 demand and claim "all is well"
> 	with IPv4 and the IPv6 hype is just that.
> 
> 	I expect it will be common for new builds - so they can
> 	participate with that "other" address family.  Less common
> 	for existing builds - in part because the clients/content
> 	are already there.  UNTIL ... some compelling new content
> 	or feature is brought up ONLY on IPv6... then the installed
> 	base has to decide how to move.
> 
> 	the middle ground, that you have espoused, where some content/
> 	applications are available over -both- address families - will
> 	be the predominant mode - but such will be an operational 
> 	suite from outerdarkness...  because the transports are non-overlapping.

It's interesting that you should pick facebook as your example 
popular site:

http://slashdot.org/article.pl?sid=08/02/08/1627201

I believe the focus on the PC access paradigm might be missing 
the potential for IPv6 adoption. As an ISP admin, I expect it 
will be years after the exhaustion of the IPv4 pool before most 
of my customers will be concerned about dual stacking, even
though they may not be able to access some content.

The potential for IPv6 probably rests in the hands of mobile, 
embedded and networking devices. If providers build these types 
of devices, and the next generation of services, on IPv6 and the 
advantages it provides, then those services will bootstrap the 
rest of the industry - "You mean I can do *that* on my PC?".

As someone who gets excited about tech, I hope it's not the stick 
(IPv4 is running out!) that moves us along but rather the 
potential services and devices that we create that get us there.

- Dan White


From Nathan.Nieblas at quebecorworld.com  Sat Feb  9 18:58:20 2008
From: Nathan.Nieblas at quebecorworld.com (Nathan.Nieblas at quebecorworld.com)
Date: Sat, 9 Feb 2008 17:58:20 -0600
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
	one."
In-Reply-To: <p06240801c3d3e0df6e6b@[192.168.3.76]>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>	<20080209133943.GA54068@ussenterprise.ufp.org>
	<20080209191140.GA18897@vacation.karoshi.com.>	<p06240808c3d3aff5f74e@[192.168.3.76]>
	<20080209225608.GA20753@vacation.karoshi.com.>,
	<p06240801c3d3e0df6e6b@[192.168.3.76]>
Message-ID: <OFB0AE2785.A259098B-ON862573EA.0083AB99-862573EA.0083AF3A@qwinc.com>

Is the reserved Class E address space not being considered? Would it take
to much effort vs. the effort of implementing IPv6?

Nathan

-----ppml-bounces at arin.net wrote: -----


To: bmanning at vacation.karoshi.com
From: John Curran <jcurran at istaff.org>
Sent by: ppml-bounces at arin.net
Date: 02/09/2008 03:34PM
cc: Public Policy Mailing List <ppml at arin.net>
Subject: Re: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
one."

At 10:56 PM +0000 2/9/08, bmanning at vacation.karoshi.com wrote:
>
>    i think a safe presumption is that this may be a
>    predominant structure as long as there are "arrogant
>    twits" who maintain the fiction that only IPv4 transport
>    is needed to get to their content/eyeballs.  e.g. if
>    facebook never supports IPv6 transport, this will be common.
>    Facebook will never see IPv6 demand and claim "all is well"
>    with IPv4 and the IPv6 hype is just that.

Facebook, Yahoo!, Google, MSN, Youtube, .... the list goes on and on.
I wouldn't expect any of them to see measurable demand for IPv6
until there's a sizable IPv6-only user community.

An IPv6-only user community is definitely going to happen (my own
opinion) but it's years away and occurs when ISP's have no real cost-
effective alternative for extending growth via IPv4.  Even if some user
communities go dual-stack before then, that's not exactly a compelling
reason for content providers to invest in IPv6 infrastructure since dual-
stack implies that they can already get the same users over IPv4.

Can you explain why there will be a significant base of IPv6-only users
before then?

Without IPv6-only users or some compelling benefits for IPv6 versus IPv4
transport, it's hard to see why the content community would invest ahead
of time.  Existing enterprises, consumers, and content providers all have
working infrastructure that still meets their needs once there is no
readily
available free pool; it's the ISP business growth model that gets impacted
and hence the ISP community that needs to drive any desired transition.

/John
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN
Public Policy
Mailing List (PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml
Please contact the ARIN Member Services Help Desk at info at arin.net if you
experience any issues.



From michael at rancid.berkeley.edu  Sat Feb  9 19:13:35 2008
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Sat, 09 Feb 2008 16:13:35 -0800
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
 one."
In-Reply-To: <OFB0AE2785.A259098B-ON862573EA.0083AB99-862573EA.0083AF3A@qwinc.com>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>	<20080209133943.GA54068@ussenterprise.ufp.org>	<20080209191140.GA18897@vacation.karoshi.com.>	<p06240808c3d3aff5f74e@[192.168.3.76]>	<20080209225608.GA20753@vacation.karoshi.com.>,
	<p06240801c3d3e0df6e6b@[192.168.3.76]>
	<OFB0AE2785.A259098B-ON862573EA.0083AB99-862573EA.0083AF3A@qwinc.com>
Message-ID: <47AE41AF.6050504@rancid.berkeley.edu>

Nathan.Nieblas at quebecorworld.com wrote:
> Is the reserved Class E address space not being considered? Would it take
> to much effort vs. the effort of implementing IPv6?

It is being considered in some corners for things like private 
addressing[1].  IMO, to make that space useful for globally-routable 
unicast services, it would take enough work and extend the life of the 
IPv4 free pool for a short enough time that our efforts are better spent 
in deploying IPv6.

michael

[1]http://www.ietf.org/internet-drafts/draft-wilson-class-e-01.txt


From bmanning at vacation.karoshi.com  Sat Feb  9 19:19:00 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Sun, 10 Feb 2008 00:19:00 +0000
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
	one."
In-Reply-To: <p06240801c3d3e0df6e6b@[192.168.3.76]>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>
	<20080209133943.GA54068@ussenterprise.ufp.org>
	<20080209191140.GA18897@vacation.karoshi.com.>
	<p06240808c3d3aff5f74e@[192.168.3.76]>
	<20080209225608.GA20753@vacation.karoshi.com.>
	<p06240801c3d3e0df6e6b@[192.168.3.76]>
Message-ID: <20080210001900.GA21368@vacation.karoshi.com.>

On Sat, Feb 09, 2008 at 06:34:53PM -0500, John Curran wrote:
> At 10:56 PM +0000 2/9/08, bmanning at vacation.karoshi.com wrote:
> >
> >	i think a safe presumption is that this may be a
> >	predominant structure as long as there are "arrogant
> >	twits" who maintain the fiction that only IPv4 transport
> >	is needed to get to their content/eyeballs.  e.g. if
> >	facebook never supports IPv6 transport, this will be common.
> >	Facebook will never see IPv6 demand and claim "all is well"
> >	with IPv4 and the IPv6 hype is just that.
> 
> Facebook, Yahoo!, Google, MSN, Youtube, .... the list goes on and on.
> I wouldn't expect any of them to see measurable demand for IPv6
> until there's a sizable IPv6-only user community.

	actually, I never expect them to see a demand for
	IPv6 - at least from the trenches. Folks will 
	"wrap" IPv6 access in/around NAT-PT or IVI and
	all they will see is IPv4 access requests.

> An IPv6-only user community is definitely going to happen (my own
> opinion) but it's years away and occurs when ISP's have no real cost-
> effective alternative for extending growth via IPv4.  Even if some user
> communities go dual-stack before then, that's not exactly a compelling
> reason for content providers to invest in IPv6 infrastructure since dual-
> stack implies that they can already get the same users over IPv4.
> 
> Can you explain why there will be a significant base of IPv6-only users
> before then?

	some communities are already in that situation... at least on
	a global scale. and they are the ones active in the development
	and fine tuning of the ALG's that provide "seamless" migration
	btwn address families.  and in this situation, the content providers
	will -never- see IPv6 demand as a groundswell.

> Without IPv6-only users or some compelling benefits for IPv6 versus IPv4
> transport, it's hard to see why the content community would invest ahead
> of time.  Existing enterprises, consumers, and content providers all have
> working infrastructure that still meets their needs once there is no readily
> available free pool; it's the ISP business growth model that gets impacted
> and hence the ISP community that needs to drive any desired transition.

	I expect the content community will be complacent in their
	rich IPv4 mesh.  And at some point, in one of those IPv6 only
	enclaves, something new will emerge that is available on IPv6
	only.  Folks will want that feature/capability.  And low'n'behold,
	the ALG that lets the IPv6 only crowd out to the IPv4 world will
	let the IPv4 world into the IPv6 world.  Then the question will be
	one of ALG scalability.   :)

> /John

	
--bill (my own opinions as well)


From bmanning at vacation.karoshi.com  Sat Feb  9 19:23:26 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Sun, 10 Feb 2008 00:23:26 +0000
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
	one."
In-Reply-To: <47AE3C6A.3050605@olp.net>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>
	<20080209133943.GA54068@ussenterprise.ufp.org>
	<20080209191140.GA18897@vacation.karoshi.com.>
	<p06240808c3d3aff5f74e@[192.168.3.76]>
	<20080209225608.GA20753@vacation.karoshi.com.>
	<47AE3C6A.3050605@olp.net>
Message-ID: <20080210002326.GB21368@vacation.karoshi.com.>

On Sat, Feb 09, 2008 at 05:51:06PM -0600, Dan White wrote:
> bmanning at vacation.karoshi.com wrote:
> >     {picking on facebook as a typical content provider}
> 
> It's interesting that you should pick facebook as your example 
> popular site:
> 
> http://slashdot.org/article.pl?sid=08/02/08/1627201
> 
> I believe the focus on the PC access paradigm might be missing 
> the potential for IPv6 adoption. As an ISP admin, I expect it 
> will be years after the exhaustion of the IPv4 pool before most 
> of my customers will be concerned about dual stacking, even
> though they may not be able to access some content.

	amen.
> 
> The potential for IPv6 probably rests in the hands of mobile, 
> embedded and networking devices. If providers build these types 
> of devices, and the next generation of services, on IPv6 and the 
> advantages it provides, then those services will bootstrap the 
> rest of the industry - "You mean I can do *that* on my PC?".

	er... surely you intended, "...You mean I CAN'T to *that on
	my PC?"

	I'm persuaded that you have identified the next round of 
	connectable devices.

> As someone who gets excited about tech, I hope it's not the stick 
> (IPv4 is running out!) that moves us along but rather the 
> potential services and devices that we create that get us there.

	i beleive that both carrot and stick are needed for 
	this beast'o'burden to get moving. 
> 
> - Dan White

--bill


From michael at rancid.berkeley.edu  Sat Feb  9 19:25:01 2008
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Sat, 09 Feb 2008 16:25:01 -0800
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
 one."
In-Reply-To: <p06240801c3d3e0df6e6b@[192.168.3.76]>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>	<20080209133943.GA54068@ussenterprise.ufp.org>	<20080209191140.GA18897@vacation.karoshi.com.>	<p06240808c3d3aff5f74e@[192.168.3.76]>	<20080209225608.GA20753@vacation.karoshi.com.>
	<p06240801c3d3e0df6e6b@[192.168.3.76]>
Message-ID: <47AE445D.6010202@rancid.berkeley.edu>

John Curran wrote:

> Without IPv6-only users or some compelling benefits for IPv6 versus IPv4
> transport, it's hard to see why the content community would invest ahead
> of time.  Existing enterprises, consumers, and content providers all have
> working infrastructure that still meets their needs once there is no readily
> available free pool; it's the ISP business growth model that gets impacted
> and hence the ISP community that needs to drive any desired transition.

In the R&E community, there is still a credible belief that we will see 
IPv6-only resources in the fairly near future.  For example, the Large 
Tokamak project in Asia is reputed to be IPv6-only once it becomes 
operational.  Researchers elsewhere who need data from it will need v6 
or some sort of proxy.

I do believe that we will see IPv6-only users in parts of the developing 
world, where they won't be able to afford increasing prices for IPv4 
addresses once the free pool run-out occurs and we (maybe) move to a 
market system.  In the R&E community, there are a bunch of us who 
believe we need to make our resources available to that segment, but, 
like any other sector, do not speak with one voice.

I am glad to see that John has had good luck in his conversion, but I 
agree with Randy that there are many bumps in the road.  See:

http://events.internet2.edu/2008/jt-hawaii/sessionDetails.cfm?session=3607&event=278

(video stream at http://winmedia.internet2.edu/jointtechs-w08/jtw08-18.wmv )

My point in that talk is that there are bumps even in places where you 
don't expect them, such as applications that _do_ support IPv6 (but not 
easy dual-stack) or registrars that, to their credit, have implemented 
AAAA glue for years (but had some bugs in their implementation and there 
hasn't been sufficient use of the registration system to tickle those 
bugs).  However, for me and my organization, that has been justification 
for moving ahead now.  It's precisely because with think there WILL be 
some pain, bumps, and delays in converting to dual-stack that we feel we 
need to get started now.  We still have a little bit of time before the 
crunch comes; if we move now, we believe we will be in a much better 
position than if we wait until we absolutely have to migrate.

As for transitions, given the cloud that now hangs over NAT-PT (via RFC 
4966), and Iljitsch van Beijnum's point in "Running IPv6"--that 
applications that support IPv6 will tend to have ALGs and proxies that 
those that don't have ALGs and proxies won't support IPv6 from the 
client side anyway--I am moving toward a combined v4-NAT and v6 model. 
My idea (for large workstation lans and residence services) is to have a 
one-armed NAT gateway to do the v4 translation, while v6 would be just 
routed through the regular routing infrastructure, with no middleboxes. 
  I am in the process of a POC now.  (If anyone else has tried this let 
me know off-list, as that's more of an ops issue.)  This still requires 
clients to be dual-stack and it still has the yuckiness of v4 NAT, but 
it does give clients an end-to-end transparency option (and thus an 
incentive to use IPv6) plus a v4 fallback option, and it could reduce 
pressure on IPv4 address space in the future.  It seems like it might be 
useful on large client networks, WiFi nets, residential nets, etc.

michael


From paul at vix.com  Sat Feb  9 21:24:15 2008
From: paul at vix.com (Paul Vixie)
Date: Sun, 10 Feb 2008 02:24:15 +0000
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
	one."
In-Reply-To: Your message of "Sat, 09 Feb 2008 12:52:54 EST."
	<p06240804c3d395dfda1f@[192.168.3.76]> 
References: <369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com>
	<p06240803c3d3720b741f@[192.168.3.76]> <g3wspe3ueu.fsf@sa.vix.com>
	<p06240804c3d395dfda1f@[192.168.3.76]> 
Message-ID: <5384.1202610255@sa.vix.com>

> >so there's an opportunity here for IPv4-rich ISP's to delay their
> >own IPv6 transition, including dual-stack, so as to acquire customers
> >and cash flows from IPv4-poor ISP's, during a transition period that
> >can be deliberately extended by such delay?
> 
> Interesting thought...  the answer is likely yes, but it actually may
> be more likely an opportunity for smaller ISP's as it's the ratio of
> supply over usage rate that determines how long one can stretch an
> IPv4-only connectivity model.  It changes to more of an opportunity
> for deeply-funded entities in the presence of a market-like transfer
> policies.

i wasn't saying large vs. small, which is often unrelated to ipv4-rich
vs. ipv4-small (think cogent).  in the absence of a market-like transfer
policy, ipv4-rich means latently-larger whereas ipv4-poor means latenyly-
smaller, unless and only unless the ipv4-poor start out so large that they
make a "voting bloc" that content providers will pander do by dual-stacking.

at the moment i don't see any ipv4-poor.  and, alain durand's mechanisms may
work so well that ipv6-only endpoints can work as well as ipv4-natted
endpoints work now, but with the added advantage of using ipv6 where the other
end speaks it (think gaming and peer-to-peer, where both-ends-natted is
painful, and where there is no content provider per se).

there may in other words be a soft landing in spite of the things we all
don't do, and the routing table growth will continue to be nonexplosively
incremental the way it has been for the last ten years.  the networks who
have to grow to live are not going to wait for IETF or ARIN to save them,
and they aren't going to come to ARIN with proposals that would save them,
they're just going to engineer their way around it, exactly as happened
with NAT.


From rjoffe at centergate.com  Sun Feb 10 09:50:54 2008
From: rjoffe at centergate.com (Rodney Joffe)
Date: Sun, 10 Feb 2008 07:50:54 -0700
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
	one."
In-Reply-To: <47AE445D.6010202@rancid.berkeley.edu>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>	<20080209133943.GA54068@ussenterprise.ufp.org>	<20080209191140.GA18897@vacation.karoshi.com.>	<p06240808c3d3aff5f74e@[192.168.3.76]>	<20080209225608.GA20753@vacation.karoshi.com.>
	<p06240801c3d3e0df6e6b@[192.168.3.76]>
	<47AE445D.6010202@rancid.berkeley.edu>
Message-ID: <B10CA6E7-CAF0-41E8-880B-01EA4ED62424@centergate.com>


To throw a little accelerant on the fire....

http://www.icann.org/announcements/announcement-2-10feb08.htm

"ICANN Recovers Large Block of Internet Address Space

16 million unused IPv4 address now available for use on the Internet

10 February 2008

MARINA DEL REY, Calif.: The Internet Corporation for Assigned Names  
and Numbers has found a little breathing room in the IPv4 address  
space with its recovery of a block of 16 million IPv4 addresses.

The IP addresses recovered were once used to connect older protocol  
packet-data networks with the fledgling Internet. The block of  
addresses, technically referred to as 14.0.0.0/8, is also known as  
Net-14. " ...

Perhaps we'll begin to see a little more of this.


From leo.vegoda at icann.org  Sun Feb 10 10:43:51 2008
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Sun, 10 Feb 2008 07:43:51 -0800
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently
	no	one."
In-Reply-To: <B10CA6E7-CAF0-41E8-880B-01EA4ED62424@centergate.com>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>
	<20080209133943.GA54068@ussenterprise.ufp.org>
	<20080209191140.GA18897@vacation.karoshi.com.>
	<p06240808c3d3aff5f74e@[192.168.3.76]>
	<20080209225608.GA20753@vacation.karoshi.com.>
	<p06240801c3d3e0df6e6b@[192.168.3.76]>
	<47AE445D.6010202@rancid.berkeley.edu>,
	<B10CA6E7-CAF0-41E8-880B-01EA4ED62424@centergate.com>
Message-ID: <5751D739B8779944939698FBC816B7CE214F9889C9@EXVMBX016-2.exch016.msoutlookonline.net>

Hi,

Rodney Joffe wrote:

> MARINA DEL REY, Calif.: The Internet Corporation for Assigned Names
> and Numbers has found a little breathing room in the IPv4 address
> space with its recovery of a block of 16 million IPv4 addresses.
>
> The IP addresses recovered were once used to connect older protocol
> packet-data networks with the fledgling Internet. The block of
> addresses, technically referred to as 14.0.0.0/8, is also known as
> Net-14. " ...
>
> Perhaps we'll begin to see a little more of this.

I think it is unlikely that we'll see any more whole /8s returned to the IANA,
although it's possible that longer prefixes could be returned to a free pool
and be made available for allocation to someone else.

But as I wrote here, that address recovery is unlikely to extend the free pools'
lifetimes by more than a few months.

http://blog.icann.org/?p=271

Regards,

Leo


From michael.dillon at bt.com  Sun Feb 10 16:25:35 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Sun, 10 Feb 2008 21:25:35 -0000
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
	one."
In-Reply-To: <47AD35BA.3030807@psg.com>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>	<p06240807c3d2cca2ae28@[192.168.3.76]>	<FF6031B2-AAED-45DB-830B-2C0FD1E5439E@virtualized.org>	<p0624080ac3d2ddfcbfd0@[192.168.3.76]>	<4E6BB0C5-1E43-41A5-B0C7-08A38296868B@virtualized.org><p0624080cc3d2df6a15bd@[192.168.3.76]>
	<47AD35BA.3030807@psg.com>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B001EC577A@E03MVC4-UKBR.domain1.systemhost.net>

> what does it take to make your enterprise dual stack?  

Where will your enterprise get the IPv4 addresses required
to go dual stack?

There are many companies whose networks are not growing and
for these companies, dual-stacking is a possibility although
it does tend to lock them into not growing their network. But
for ISPs, whose network is constantly growing, and for whom
growth is a part of the network model, dual-stack is a risky
approach. Of course, if you lose IPv4 customers then you can
use those addresses to continue growing your network but this
cannibalisation strategy is complex and risky.

If a network operator has already moved to MPLS in the core, or
is in a position to implement MPLS without great pain over the
next couple of years, then they can painlessly implement IPv6
services using 6PE with no requirement to dual-stack. And even
if a network does not go to MPLS, you can implement something
similar to 6PE using GRE tunnels or PWE3 to interconnect IPv6
edge routers across an IPv4 core. These strategies using 6PE,
GRE or PWE3 allow you to limit the impact of IPv6 to only those
PoPs and devices that are needed to provide IPv6 service. 
This makes it easier to incrementally add IPv6 to the network
as and when needed.

> we went in early, in fact the earliest commercial roll.  and 
> we have regressed, i.e. some services are not maintained over 
> ipv6 that used to be because no one used them and they caused 
> pain.

We have done similar, i.e. shutting down the UK6x exchange because
there was no business case to keep it going. Also because it was
research and there is no need for basic IPv6 networking research
any more. It's ready for production and we had customers wanting
to buy commercial IPv6 services, so we are in the process of 
migrating the IPv6 services to a proper commercial footing.
Right now the demand is for IPv6 access to the IPv6 Internet
so that is what we are providing. The demand is not there to
provide SMTP over IPv6 so we don't bother with that right now.
I expect that within a couple of years there will be customer
demand for email delivery over IPv6 and we will provide some
kind of SMTP proxy service with DNSBL etc.

A lot of people are complaining that IPv6 is a problem because
there are still some IPv4 services that are not usable over
IPv6 yet. This is a red herring, since these kinds are services
are easy to make available, once the demand is there.

--Michael Dillon


From michael.dillon at bt.com  Sun Feb 10 16:32:48 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Sun, 10 Feb 2008 21:32:48 -0000
Subject: [ppml] "Who's afraid of IPv4 address depletion?
	Apparentlynoone."
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com>
References: <FF6031B2-AAED-45DB-830B-2C0FD1E5439E@virtualized.org>
	<369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B001EC577B@E03MVC4-UKBR.domain1.systemhost.net>


> I'm an ISP customer.  My IPv4 network isn't growing (maybe I 
> add a /28 per year).  Tell me why I care about IPv6.

A) If your ISP does not have IPv6 services ready when they can't
get IPv4 addresses any more, they will be unable to add new 
customers. When word of this gets out, and it will, then they
will begin to lose customers who are nervous about the whole
situation, and that could lead to bankruptcy, and to you losing
your upstream connection on short notice.

B) You probably don't need to care a whole lot about IPv6 yet.
For an end customer whose network is not growing and who can 
rely on their ISP for gateway services to the IPv6 Internet,
there is no big crisis looming. There will be rough waters in
two years, but many companies will keep on trucking without
being IPv6 pioneers.

--Michael Dillon


From ppml at rs.seastrom.com  Sun Feb 10 16:51:57 2008
From: ppml at rs.seastrom.com (Robert E. Seastrom)
Date: Sun, 10 Feb 2008 16:51:57 -0500
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
	one."
In-Reply-To: <47ADBA2E.9030303@psg.com> (Randy Bush's message of "Sat,
	09 Feb 2008 23:35:26 +0900")
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>
	<p06240807c3d2cca2ae28@[192.168.3.76]>
	<FF6031B2-AAED-45DB-830B-2C0FD1E5439E@virtualized.org>
	<p0624080ac3d2ddfcbfd0@[192.168.3.76]>
	<4E6BB0C5-1E43-41A5-B0C7-08A38296868B@virtualized.org>
	<p0624080cc3d2df6a15bd@[192.168.3.76]> <47AD35BA.3030807@psg.com>
	<p0624080dc3d35bae3648@[192.168.3.76]> <47ADB11A.3070409@psg.com>
	<p06240801c3d36248c266@[192.168.3.76]> <47ADBA2E.9030303@psg.com>
Message-ID: <86tzkga39e.fsf@seastrom.com>


Randy Bush <randy at psg.com> writes:

> so i am gonna sit here and sulk and whine loud and long until the iana 
> and opensrs/tucows fix it. :)

Amen.  I want @!$^@%$ v6 glue for my nameservers to go with my v6
hostnames.  This is not rocket science.

d75:~ rs$ dig +short seastrom.com. mx
10 valhalla.seastrom.com.
d75:~ rs$ dig +short valhalla.seastrom.com. aaaa
2610:178:1:1:203:47ff:fe94:2c10
d75:~ rs$ dig +short seastrom.com. ns
asgard.seastrom.com.
alfheim.seastrom.com.
bifrost.seastrom.com.
d75:~ rs$ dig +short asgard.seastrom.com. aaaa
d75:~ rs$ dig +short bifrost.seastrom.com. aaaa
d75:~ rs$ dig +short alfheim.seastrom.com. aaaa
d75:~ rs$ 

This is holding up progress.  Elliott, Ross, are you guys with the
program or do I need to find a new registrar and tell all my friends
to do the same?

                                        ---rob



From mksmith at adhost.com  Sun Feb 10 17:11:36 2008
From: mksmith at adhost.com (Michael Smith)
Date: Sun, 10 Feb 2008 14:11:36 -0800
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently
	noone."
In-Reply-To: <g3wspe3ueu.fsf@sa.vix.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com>
	<p06240803c3d3720b741f@[192.168.3.76]> <g3wspe3ueu.fsf@sa.vix.com>
Message-ID: <0ECB41A1-17E9-49E7-8011-85925869ABE8@adhost.com>


On Feb 9, 2008, at 9:35 AM, Paul Vixie wrote:

> jcurran at istaff.org (John Curran) writes:
>
>> At 10:05 AM -0500 2/9/08, Howard, W. Lee wrote:
>>> I'm an ISP customer.  My IPv4 network isn't growing (maybe
>>> I add a /28 per year).  Tell me why I care about IPv6.
>>
>> You don't, until some ISP is wedged in such a tight corner that
>> they need to connect new customers with just IPv6 (because
>> they can't seem to obtain&route additional IPv4 space at any
>> realistic cost).
>> ...
>
> so there's an opportunity here for IPv4-rich ISP's to delay their
> own IPv6 transition, including dual-stack, so as to acquire customers
> and cash flows from IPv4-poor ISP's, during a transition period that
> can be deliberately extended by such delay?
> --  
> Paul Vixie

Indeed.  As a smaller hosting company, I have need for a /19 every 12  
months or so.  My guess is I *might* be able to get one more before  
the pool is gone, given the rate of uptake from the big guys.  I'm  
implementing IPv6 now across our network, but no one is requesting  
IPv6 services (well, one guy for testing).  So, here's the scenario I  
see.

1) None of the big content players implement IPv6 because "there is no  
demand."
2) None of the big eyeball providers get full-on IPv6 support for any  
number of reasons.
3) IPv4 addresses run out
4) (1) and (2) above have a reasonable reserve to carry them for some  
period of time.
5) Smaller content providers have to start putting hosts on IPv6 only  
because they're out of addresses.  New customer doesn't sign up  
because they know that they are not reachable by most folks.  Since  
most of our sites are SSL-enabled, we really can't use shared-IP  
resources for these hosts, so this is a very real problem.
6) Little provider tanks or is purchased for pennies on the dollar.

The is not a problem that is going to be solved by a bunch of small to  
medium size providers taking up the torches and threatening to burn  
down the village.  If the big players, both on the network and content  
side don't take the lead and start implementing and espousing the  
benefits of IPv6 it's going to be hell for the rest of us.  I hope  
this is not the business plan of bigger players.

Regards,

Mike Smith
Adhost Internet, LLC


From jmaimon at chl.com  Sun Feb 10 17:12:57 2008
From: jmaimon at chl.com (Joe Maimon)
Date: Sun, 10 Feb 2008 17:12:57 -0500
Subject: [ppml] "Who's afraid of IPv4 address
	depletion?	Apparentlynoone."
In-Reply-To: <D03E4899F2FB3D4C8464E8C76B3B68B001EC577B@E03MVC4-UKBR.domain1.systemhost.net>
References: <FF6031B2-AAED-45DB-830B-2C0FD1E5439E@virtualized.org>	<369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com>
	<D03E4899F2FB3D4C8464E8C76B3B68B001EC577B@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <47AF76E9.8010805@chl.com>



michael.dillon at bt.com wrote:
>>I'm an ISP customer.  My IPv4 network isn't growing (maybe I 
>>add a /28 per year).  Tell me why I care about IPv6.
> 
> 
> A) If your ISP does not have IPv6 services ready when they can't
> get IPv4 addresses any more, they will be unable to add new 
> customers. 

There are more than enough tricks for an ISP to keep going in the face 
of global ipv4 shortage crunch, which will probably happen akin to a 
series of ever higher brick walls that will be hit and then scaled over.

1) Loosen up allocation requirements now

2) Churn will free them up when they are needed more

3) Scavenge all /30 public serial assignments

4) Offer unnumbered serial networking, possibly one public Loopback.

5) Offer only loopback public IP addresses or one to one natted over a 
barrier private network for the most common case of deployment.

6) customer firewalls become more uniformly usable with the only public 
ip addresses on loopback interfaces

7) Bring your own IP. Lots of different examples for this, I am 
specificaly referring to situations where ISP A has the customers and 
turns them up through ISP B, who up to the crunch was kind enough to 
address them out of B space, but will most likely not do that anymore.

8) /24 will likely cease to be a de-facto cutoff point from the BGP 
table if this continues past a certain point

8) Cross ISP tunneling of customer-carried-with IP blocks will likely 
become more common, if/when burden of providing anything more than 
de-minimis ipv4 addresses falls to the customer.


So for an example, an ISP who normal mode of assignment works like this.

T1/Leased line Customer, one /30 for WAN and one /29 for LAN, where the 
customer has its own firewall, can conceivably replace this inefficient 
waste of space with a couple /32's routed to loopback or over rfc1918 
barrier networks.

Scavenge/Churn one customer, turn up three to six more.

Broadband aggregation? Convert all your applicable users (all broadband 
agg ISP's have large percentages of these) to rfc1918, stick them behind 
a nat. Offer them ipv6 if they even want it. Easily done with pppoe 
customers.

Offer inbound port by port incoming service for that class of customer.

Pain? Effort? Aggravation? Greater turnup complexity? Yes to all of the 
above. But if resistance to ipv6 conversion continues, it may well prove 
to be worth it, for at least some ISP's.

And if most ISP's are in the same boat at the same time, then it wont be 
the huge competitive advantage it might otherwise be.

Globaly, there will be plenty of scavenging opportunities. And when the 
first brick wall in ipv4 availability is hit, allocation guidelines will 
probably change dramatically. The resulting scavenging will then have a 
much higher impact then, than it were, would it be done now, with 
current allocation guidelines.

Those with space from before will conceivably get much greater ground 
from these scavenging and miserly assignemnt strategies after the first 
brick wall is hit.

I think its unlikely that global ipv4 shortage would result in any 
technicaly proficient ISP from being able to turn up most new customers.

As a side benefit, the more pain involved in continuing with ipv4 
deployments, the more traction ipv6 will gain.

The real question I see, is does it become a good idea to preempt the 
scavenging neccessity and clamp the allocations and guidelines to 
produce scavenging sooner rather than later?

Sorta like highway driving while running low on gas, looking for that 
gas station open late night....when do you put the higher mpg tricks 
into effect, before or after you are in high adrenalin mode?

Joe


From jcurran at istaff.org  Sun Feb 10 21:08:05 2008
From: jcurran at istaff.org (John Curran)
Date: Sun, 10 Feb 2008 21:08:05 -0500
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently
 noone."
In-Reply-To: <0ECB41A1-17E9-49E7-8011-85925869ABE8@adhost.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com>
	<p06240803c3d3720b741f@[192.168.3.76]> <g3wspe3ueu.fsf@sa.vix.com>
	<0ECB41A1-17E9-49E7-8011-85925869ABE8@adhost.com>
Message-ID: <p06240803c3d55da6af74@[192.168.3.76]>

At 2:11 PM -0800 2/10/08, Michael Smith wrote:
>...
>So, here's the scenario I  see.
>
>1) None of the big content players implement IPv6 because "there is no 
>demand."
>2) None of the big eyeball providers get full-on IPv6 support for any 
>number of reasons.
>3) IPv4 addresses run out
>4) (1) and (2) above have a reasonable reserve to carry them for some 
>period of time.
>5) Smaller content providers have to start putting hosts on IPv6 only 
>because they're out of addresses.

So, (obligatory question), is there a change to allocation
policy which would address your concern?

/John


From kloch at kl.net  Sun Feb 10 21:29:38 2008
From: kloch at kl.net (Kevin Loch)
Date: Sun, 10 Feb 2008 21:29:38 -0500
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
 one."
In-Reply-To: <p06240801c3d36248c266@[192.168.3.76]>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>	<p06240807c3d2cca2ae28@[192.168.3.76]>	<FF6031B2-AAED-45DB-830B-2C0FD1E5439E@virtualized.org>	<p0624080ac3d2ddfcbfd0@[192.168.3.76]>	<4E6BB0C5-1E43-41A5-B0C7-08A38296868B@virtualized.org>	<p0624080cc3d2df6a15bd@[192.168.3.76]>
	<47AD35BA.3030807@psg.com>	<p0624080dc3d35bae3648@[192.168.3.76]>
	<47ADB11A.3070409@psg.com> <p06240801c3d36248c266@[192.168.3.76]>
Message-ID: <47AFB312.7020200@kl.net>

John Curran wrote:
> At 10:56 PM +0900 2/9/08, Randy Bush wrote:
>>> We haven't put the MX records in yet, but that is in progress.
>> and you don't seem to have the AAAAs for the nameservers.  when you do, you may have some hope of getting glue at the parent, as you use netsol as a registrar.  but do tell how that one goes.
> 
>>From the Nanog thread, it's clear the versign/registry can handle such,
> so if it's just phone loops with netsol/registrar to get them to push the
> glue, I've got quite a bit of patience...  I'll make sure to provide any
> updates/insights to Jeroen for the Sixxs-IPv6glue page.  Who knows,
> if we end up changing registrars over it, it'll be one more data point
> for netsol to consider support.

I just went through this with Enom.  Their web app lets you
set IPv6 OR IPv4 address glue for nameservers but not both at the
same time.  A support ticket was resolved within 24 hours with
some engineer manually adding the AAAA record.

- Kevin


From jlewis at lewis.org  Sun Feb 10 21:45:37 2008
From: jlewis at lewis.org (Jon Lewis)
Date: Sun, 10 Feb 2008 21:45:37 -0500 (EST)
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently
 noone."
In-Reply-To: <p06240803c3d55da6af74@[192.168.3.76]>
References: <369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com>
	<p06240803c3d3720b741f@[192.168.3.76]> <g3wspe3ueu.fsf@sa.vix.com>
	<0ECB41A1-17E9-49E7-8011-85925869ABE8@adhost.com>
	<p06240803c3d55da6af74@[192.168.3.76]>
Message-ID: <Pine.LNX.4.61.0802102128280.3306@soloth.lewis.org>

On Sun, 10 Feb 2008, John Curran wrote:

> At 2:11 PM -0800 2/10/08, Michael Smith wrote:
>> ...
>> So, here's the scenario I  see.
>>
>> 1) None of the big content players implement IPv6 because "there is no
>> demand."

Some of them will/already have because they have massive deployments of 
"back-end" servers and not enough IPv4 addresses to easily manage them 
all, yet they don't use IPv6 for public facing machines.

>> 3) IPv4 addresses run out
>> 5) Smaller content providers have to start putting hosts on IPv6 only
>> because they're out of addresses.

Before that happens, as mentioned, we're going to get awfully stingy and 
creative with IP assignments, and use more NAT.  But eventually, we're 
going to hit the wall and unless there are significant changes to the way 
IPv4 addressing/utilization is handled, we just won't be able to get more 
IPv4.

Interestingly, at an interview I had just months ago with a senior network 
engineer with a household name .com who's stock has never split, I was 
told the above scenario will never happen...that we're just not going to 
run out of IPv4 addresses and that there's never going to be a need for 
IPv6 in general on the internet.  I don't know where he thinks we're going 
to get IPv4 addresses from when ARIN and the other RIRs tell us they have 
no more to give us.  Maybe he thinks that'll never happen either.

> So, (obligatory question), is there a change to allocation
> policy which would address your concern?

I don't see how that's going to affect the top content providers as long 
as they have enough public IPv4 to keep their public facing systems 
online.  I don't know how you get their heads out of the sand.

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________


From plzak at arin.net  Mon Feb 11 00:19:08 2008
From: plzak at arin.net (Ray Plzak)
Date: Mon, 11 Feb 2008 00:19:08 -0500
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently
 noone."
In-Reply-To: <p06240803c3d3720b741f@[192.168.3.76]>
References: <369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com>
	<p06240803c3d3720b741f@[192.168.3.76]>
Message-ID: <FEA070315E40A3489D38398C35FE7BB20298B1E2AC@EDAMAME.arin.net>



> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of
> John Curran
> Sent: Saturday, February 09, 2008 10:16 AM
> To: Howard, W. Lee
> Cc: Public Policy Mailing List
> Subject: Re: [ppml] "Who's afraid of IPv4 address depletion? Apparently
> noone."
>
> end-to-end IP...   Does this matter to you?  I guess it depends on
> how a given business interacts with its suppliers and customers.

It might matter to grandma who wants to webcam/chat with the grandkids or the person who wants to do uTube or etc.

Ray



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



From mje at pop.co.za  Mon Feb 11 03:14:53 2008
From: mje at pop.co.za (Mark Elkins)
Date: Mon, 11 Feb 2008 10:14:53 +0200
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently
	no	one."
In-Reply-To: <86tzkga39e.fsf@seastrom.com>
References: <D15FF2A6-C743-4BF0-98CC-6AF251A54314@virtualized.org>
	<p06240807c3d2cca2ae28@[192.168.3.76]>
	<FF6031B2-AAED-45DB-830B-2C0FD1E5439E@virtualized.org>
	<p0624080ac3d2ddfcbfd0@[192.168.3.76]>
	<4E6BB0C5-1E43-41A5-B0C7-08A38296868B@virtualized.org>
	<p0624080cc3d2df6a15bd@[192.168.3.76]> <47AD35BA.3030807@psg.com>
	<p0624080dc3d35bae3648@[192.168.3.76]> <47ADB11A.3070409@psg.com>
	<p06240801c3d36248c266@[192.168.3.76]> <47ADBA2E.9030303@psg.com>
	<86tzkga39e.fsf@seastrom.com>
Message-ID: <1202717693.2836.18.camel@localhost>


On Sun, 2008-02-10 at 16:51 -0500, Robert E. Seastrom wrote:
> Randy Bush <randy at psg.com> writes:
> 
> > so i am gonna sit here and sulk and whine loud and long until the iana 
> > and opensrs/tucows fix it. :)
> 
> Amen.  I want @!$^@%$ v6 glue for my nameservers to go with my v6
> hostnames.  This is not rocket science.
> 
> d75:~ rs$ dig +short seastrom.com. mx
> 10 valhalla.seastrom.com.
> d75:~ rs$ dig +short valhalla.seastrom.com. aaaa
> 2610:178:1:1:203:47ff:fe94:2c10
> d75:~ rs$ dig +short seastrom.com. ns
> asgard.seastrom.com.
> alfheim.seastrom.com.
> bifrost.seastrom.com.
> d75:~ rs$ dig +short asgard.seastrom.com. aaaa
> d75:~ rs$ dig +short bifrost.seastrom.com. aaaa
> d75:~ rs$ dig +short alfheim.seastrom.com. aaaa
> d75:~ rs$ 
> 
> This is holding up progress.  Elliott, Ross, are you guys with the
> program or do I need to find a new registrar and tell all my friends
> to do the same?

As CO.ZA (Commercial, South Africa) has added the facility for adding
IPv6 glue (without excluding IPv4 at the same time!), doing all the same
checks over IPv6 transport for IPv6 nameservers in the same way checks
are done to IPv4 nameservers, I see no reason that other registry
systems can not do the same.

I agree - like (dual-stack) access to content, registries need to be
both IPv6 accessible and able to deal with both IPv4 and IPv6 glue.

(One issue left is its 2001:43f8:30::/48 address is only 87% visible -
according to www.sixxs.net tools.. - but thats another problem)
-- 
  .  .     ___. .__      Posix Systems - Sth Africa
 /| /|       / /__       mje at posix.co.za  -  Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS  Tel: +27 12 807 0590  Cell: +27 82 601 0496



From info at arin.net  Mon Feb 11 10:58:40 2008
From: info at arin.net (Member Services)
Date: Mon, 11 Feb 2008 10:58:40 -0500
Subject: [ppml] Policy Proposal: Loophole Closure for 2007-21
Message-ID: <47B070B0.8090901@arin.net>

ARIN received the following policy proposal. In accordance with the ARIN
Internet Resource Policy Evaluation Process, the proposal is being
posted to the ARIN Public Policy Mailing List (PPML) and being placed on
ARIN's website.

The ARIN Advisory Council (AC) will review this proposal at their next
regularly scheduled meeting. The AC may decide to:

   1. Accept the proposal as written. If the AC accepts the proposal, it
will be posted as a formal policy proposal to PPML and it will be
presented at a Public Policy Meeting.

   2. Not accept the proposal. If the AC does not accept the proposal,
the AC will explain their decision via the PPML. If a proposal is not
accepted, then the author may elect to use the petition process to
advance their proposal. If the author elects not to petition or the
petition fails, then the proposal will be closed.

The AC shepherds for this proposal are Owen DeLong and Suzanne Woolf.

The AC invites everyone to comment on this 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.

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal Name: Loophole Closure for 2007-21

Author: Scott Leibrand, Owen DeLong

Proposal Version: 1.0

Submission Date: 2008-02-07

Proposal type: modify

Policy term: permanent

Policy statement:

Modify NRPM section 6.5.8.1 (Direct assignments from ARIN to end-user
organizations: Criteria), to read:

To qualify for a direct assignment, an organization must:

1. not be an IPv6 LIR; and

2. qualify for an IPv4 assignment or allocation from ARIN under the IPv4
policy currently in effect, or demonstrate efficient utilization of all
direct IPv4 assignments and allocations, each of which must be covered
by a current ARIN RSA.

Rationale:

The adopted wording of 2007-21 created a loophole allowing a resource
holder to qualify under the policy with only one resource subject to
RSA. This small change would close that loophole and bring policy in
line with the original intent of the author.

Timetable for implementation: immediate



From info at arin.net  Mon Feb 11 10:59:24 2008
From: info at arin.net (Member Services)
Date: Mon, 11 Feb 2008 10:59:24 -0500
Subject: [ppml] Policy Proposal: Community Networks IPv6 Allocation
Message-ID: <47B070DC.2020606@arin.net>

ARIN received the following policy proposal. In accordance with the ARIN
Internet Resource Policy Evaluation Process, the proposal is being
posted to the ARIN Public Policy Mailing List (PPML) and being placed on
ARIN's website.

The ARIN Advisory Council (AC) will review this proposal at their next
regularly scheduled meeting. The AC may decide to:

   1. Accept the proposal as written. If the AC accepts the proposal, it
will be posted as a formal policy proposal to PPML and it will be
presented at a Public Policy Meeting.

   2. Not accept the proposal. If the AC does not accept the proposal,
the AC will explain their decision via the PPML. If a proposal is not
accepted, then the author may elect to use the petition process to
advance their proposal. If the author elects not to petition or the
petition fails, then the proposal will be closed.

The AC shepherds for this proposal are Lea Roberts and Stacy Taylor.

The AC invites everyone to comment on this 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.

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal Name: Community Networks IPv6 Allocation

Author: Joshua King

Proposal Version:1.0

Submission Date:February 7th, 2008

Proposal type:new

Policy term:permanent

Policy statement:

Under this policy, ARIN would adopt a new IPv6 address allocation policy
that allows community networking projects to acquire space in a
straightforward and affordable manner. The policy will establish an
allocation template modeled on the experimental allocation template,
with all applicable ARIN fees aimed at affordability (for instance,
totaling not more than $500 USD). The aim is to prevent this policy from
becoming a less-expensive option for for-profit ISPs, and tailor it to
address the concerns of the kinds of organizations that run these
projects. Organizations would have the option of either acquiring blocks
for their own use, or distributing address space to other community
networks that are unable to deal with the administrative and technical
overhead of address management. A community network prefix would need to
be established, providing a subnet of sufficient size to serve such
projects for the foreseeable future. Block sizes of /48 and larger would
be available on the basis of a justification of project goals, with an
eye towards:
           1. Use by non-profit organizations.
           2. Projects aimed at low-income users.
           3. Open-source software development.

Rationale:

There are currently a number of projects globally that aim to develop
community network infrastructure and related technologies. These are
usually coordinated by volunteer-run, grassroots organizations which
lack many of the resources of traditional internet service providers and
other network operators. They have diverse goals, including public
policy, software development, and implementation of community services
and resources. Many of them provide services free of charge, and thus
lack any paying user base. However, in order to create and maintain
community networks that are often composed of hundreds if not thousands
of inexpensive, commodity hosts and devices, a significant amount of
address space will be required. Current-generation workarounds to this
problem, such as NAT, not only make it difficult to develop
next-generation decentralized network technology by segmenting the
community's architecture from the Internet as a whole, but will cease to
be as viable a stopgap as the Internet moves towards IPv6 integration.

Even now, common community networking software solutions such as
CUWiNware (http://www.cuwin.net) and Freifunk (http://www.freifunk.at)
have nascent IPv6 addressing support, but participating organizations
lack the address space for widespread testing or adoption. As such, it
is necessary to implement an procedure as soon as possible for these
segregated networks to acquire address space. These organizations do not
meet the criteria traditionally defined for LIR's, and thus cannot
acquire address allocations through existing templates. By establishing
a procedure by which these organizations can seek to acquire the
resources they require for further development, ARIN can reach out to
this active community and establish a small but definite space for them
in the future of Internet.

Timetable for implementation: Immediate.




From info at arin.net  Mon Feb 11 11:02:32 2008
From: info at arin.net (Member Services)
Date: Mon, 11 Feb 2008 11:02:32 -0500
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
Message-ID: <47B07198.2050106@arin.net>

ARIN received the following policy proposal. In accordance with the ARIN
Internet Resource Policy Evaluation Process, the proposal is being
posted to the ARIN Public Policy Mailing List (PPML) and being placed on
ARIN's website.

The ARIN Advisory Council (AC) will review this proposal at their next
regularly scheduled meeting. The AC may decide to:

   1. Accept the proposal as written. If the AC accepts the proposal, it
will be posted as a formal policy proposal to PPML and it will be
presented at a Public Policy Meeting.

   2. Not accept the proposal. If the AC does not accept the proposal,
the AC will explain their decision via the PPML. If a proposal is not
accepted, then the author may elect to use the petition process to
advance their proposal. If the author elects not to petition or the
petition fails, then the proposal will be closed.

The AC shepherds for this proposal are Scott Leibrand and Stacy Taylor.

The AC invites everyone to comment on this 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.

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal Name: IPv4 Transfer Policy Proposal

Author: ARIN Advisory Council

Proposal Version: 1.0

Submission Date: 02/07/2008

Proposal type: modify

Policy term: permanent

Policy statement:

Replace the current NRPM section 8 with the following --

8.         Transfers

[8.1.     Transfers ? retain as is:

Number resources are non-transferable and are not assignable to any
other organization unless ARIN has expressly and in writing approved a
request for transfer.  ARIN is tasked with making prudent decisions on
whether to approve the transfer of number resources.

It should be understood that number resources are not "sold" under ARIN
administration. Rather, number resources are assigned to an organization
for its exclusive use for the purpose stated in the request, provided
the terms of the Registration Services Agreement continue to be met and
the stated purpose for the number resources remains the same. Number
resources are administered and assigned according to ARIN's published
policies.

Number resources are issued, based on justified need, to organizations,
not to individuals representing those organizations. Thus, if a company
goes out of business, regardless of the reason, the point of contact
(POC) listed for the number resource does not have the authority to
sell, transfer, assign, or give the number resource to any other person
or organization. The POC must notify ARIN if a business fails so the
assigned number resources can be returned to the available pool of
number resources if a transfer is not requested and justified.]


[8.2 ? remove the word ?only?, and retitle to ?M&A Transfer Requirements?:

8.2.      M&A Transfer Requirements

ARIN will consider requests for the transfer of number resources upon
receipt of evidence that the new entity has acquired the assets which
had, as of the date of the acquisition or proposed reorganization,
justified the current entity's use of the number resource. Examples of
assets that justify use of the number resource include, but are not
limited to:

     * Existing customer base
     * Qualified hardware inventory
     * Specific software requirements.]


[8.3 ? retitle to ?M&A Transfer Documentation Requirements?:

8.3.      M&A Transfer Documentation Requirements

In evaluating a request for transfer, ARIN may require the requesting
organization to provide any of the following documents, as applicable,
plus any other documents deemed appropriate:

     * An authenticated copy of the instrument(s) effecting the transfer
       of assets, e.g., bill of sale, certificate of merger, contract,
       deed, or court decree
     * A detailed inventory of all assets utilized by the requesting
       party in maintaining and using the number resource
     * A list of the requesting party's customers using the number resource.

If further justification is required, the requesting party may be asked
to provide any of the following, or other supporting documentation, as
applicable:

     * A general listing of the assets or components acquired
     * A specific description of acquisitions, including:
           o Type and quantity of equipment
           o Customer base
     * A description of how number resources are being utilized
     * Network engineering plans, including:
           o Host counts
           o Subnet masking
           o Network diagrams
           o Reassignments to customers]

8.4.      Requirements for Simple Transfer of IPv4 Addresses

After the exhaustion of the IANA IPv4 free pool, ARIN will also process
IPv4 address transfer requests subject to the following conditions.

8.4.1    Conditions on the transferor:

     * The transferor resides in the ARIN service area.
     * The transferor has signed an RSA and/or a legacy RSA covering the
       IPv4 addresses transferred.
     * The transferor has no outstanding balances with ARIN.
     * The transferor has not received any IPv4 allocations or
       assignments from ARIN (through ordinary allocations or
       assignments, or through this Simple Transfer policy) within the
       preceding 24 months.
     * The transferor may not request any IPv4 allocations or assignments
       from ARIN (through ordinary allocations or assignments, or through
       this Simple Transfer policy) within the subsequent 24 months.

8.4.2    Conditions on the transferee:

     * The transferee resides in the ARIN service area and intends to use
       the transferred IPv4 addresses within the ARIN service area.
     * The transferee has no outstanding balances with ARIN.
     * The transferee?s need is confirmed by ARIN, according to current
       ARIN policies, including but not limited to confirmation of
       utilization rate of any prior IPv4 allocations, assignments, or
       previously transferred IPv4 addresses held by the transferee.
     * The transferee signs (or has previously signed) an RSA covering
       the IPv4 addresses transferred.
     * The transferee has not provided any IPv4 addresses for transfer
       through this Simple Transfer process within the preceding 2
       months.
     * The transferee may not provide any IPv4 addresses for transfer
       through this Simple Transfer process within the subsequent 24
       months, except in the case of business failure.
     * The transferee may only receive one IPv4 address transfer every 6
       months.



8.4.3    Conditions on the IPv4 address block to be transferred:

     * The IPv4 block must comply with applicable ARIN requirements,
       including minimum allocation size (i.e. NRPM 4.2.2., 4.2.4.,
       4.3.2., 4.3.6.).  However, an IPv4 allocation or assignment of /24
       or larger, but smaller than the current minimum allocation size,
       may be transferred as a whole resource, but may not be subdivided.
     * The IPv4 block must currently be registered for use within the
       ARIN service area, either as part of an address block assigned by
       IANA to ARIN, or as part of a legacy address block allocated
       within the ARIN service area.
     * There must exist no dispute as to the status of the IPv4 block or
       regarding the allocation or assignment of such block to the
       transferor.
     * The transferor may retain one contiguous address range out of
       their original allocation or assignment for their own use, and
       transfer the other contiguous address range.  If the address range
       to be transferred consists of multiple non-aggregatable CIDR
       blocks, each may be transferred to a different transferee.  The
       retained address range may not be further subdivided or
       transferred for a period of 12 months.

8.4.4    Fees

     * Completion of a transfer requires payment of a transfer fee
       according to ARIN?s schedule of fees.
     * The transferee will be subject to all future ARIN membership and
       service fees according to the transferee?s total address holdings.

8.4.5    Pre-qualification

     * An interested transferee must seek pre-qualification from ARIN to
       confirm its eligibility to receive a transfer (including
       satisfaction of need according to current ARIN policies) before
       making any solicitation for transfer.  Upon pre-qualification,
       ARIN will provide the transferee with documentation of the
       pre-qualification, including the size (CIDR prefix length) of the
       largest IPv4 address block the transferee is eligible to receive,
       and the expiration date of the pre-qualification.
     * An interested transferor must seek pre-qualification from ARIN to
       confirm its eligibility to offer a transfer (including lack of
       outstanding balances and having signed an RSA) before offering
       IPv4 address resources for transfer.  Upon pre-qualification, ARIN
       will provide the transferor with documentation of the
       pre-qualification, including the exact network address and size
       (CIDR prefix length) the transferor is eligible to provide, and
       the expiration date of the pre-qualification.

8.5.      Safe Harbor for IPv4 Transfers through this Simple Transfer
Process

IPv4 address resources being made available for transfer shall be exempt
from ARIN audit until expiration of the transfer pre-qualification or
completion of the transfer.  In the event that a transfer
pre-qualification expires, ARIN shall have up to 90 days to initiate an
audit prior to this exemption being reinstated through subsequent
transfer pre-qualification. This will not extend the end of the exemption.

8.6.      Simple IPv4 Transfers to or from Organizations Under Common
Ownership or Control

If an IPv4 transferor or transferee is under common ownership or control
with any other organization that holds one or more IPv4 blocks, the IPv4
transfer request must report all such organizations under common
ownership or control.

When evaluating compliance with IPv4 Simple Transfer conditions, ARIN
may consider a transferor?s transfer request in light of requests from
other organizations under common ownership or control with the
transferor.  Similarly, ARIN may consider a transferee?s request in
light of requests from other organizations under common ownership or
control with the transferee.  In evaluating requests from other
organizations under common ownership or control, ARIN staff will
consider the relationship between the organizations, the degree of
coordination between the organizations, and the bona fide use of the
addresses at issue to determine whether all appropriate conditions are met.

8.7.      Record-keeping and Publication of Simple Transfers of IPv4
Addresses

ARIN will develop and operate a listing service to assist interested
transferors and transferees by providing them a centralized location to
post information about IPv4 blocks available from prequalified
transferors and IPv4 blocks needed by prequalified transferees.

After completion of the transfer, ARIN will update the registration
records pertaining to the IPv4 block at issue.  ARIN will adjust its
records as to the holdings of the transferor and transferee.

After the transfer, ARIN will publish WHOIS data that reflects the
current allocation or assignment of the transferred block.  ARIN will
also make available information about any prior recipient(s) of such
block.  ARIN will also publish a log of all transfers, including block,
transferor, transferee, and date.


Rationale:

The ARIN Board of Trustees asked the Advisory Council to consider a set
of questions around the depletion of the free pool of IPv4 addresses,
the transition to IPv6 for Internet address needs in the future, and
ARIN's possible role in easing the transition.

Over the past few years the AC has spent a great deal of time reflecting
on these issues as a group, as individuals, and in consultation with
the community. One outcome of this process is this policy proposal,
which the AC is submitting for consideration at the next meeting. We are
proposing some changes to existing ARIN policy regarding the transfer of
IP address block registrations between subscribers, which will allow for
the emergence of trade in IPv4 address space, with ARIN to provide a
listing service for address blocks available for transfer under the
liberalized policy.  We are aware that this proposal, if adopted, will
mark a major change in ARIN's role in the community and the Internet.

This policy proposal would create a transfer mechanism for IPv4 number
resources between those who have excess resources and those who have a
need, thereby allowing ARIN to continue to serve its mission after IANA
free pool exhaustion.  This proposal would also set conditions on such
transfers intended to preserve as much as possible the existing policy
related to efficient, needs-based resource issuance, and would leverage
ARIN's extensive control systems, audit trails, and recognized position
as a trusted agent to avoid speculation and hoarding and diminish the
likelihood and extent of an uncontrolled 'black market' where the risk
and potential for fraud is immeasurably higher.

Many of the transfer conditions are self-explanatory, but some worth
highlighting are that:

     * To discourage speculation, a waiting period (proposed at 24
       months) is required before a transferee (or ordinary resource
       recipient) can become a transferor, or vice versa.
     * Transferees must qualify for IPv4 space (just as they do today
       when getting it from ARIN) before they can receive address space
       by transfer, or solicit space on a listing service.
     * To discourage unnecessarily rapid growth of routing tables, an
       allocation or assignment may not be arbitrarily deaggregated.  To
       allow a transferor to downsize within their existing space, they
       may split off a contiguous address range, once every 12 months,
       and transfer the resulting netblock(s), which are subject to
       ARIN?s minimum allocation size, to one or more transferee(s).
     * A transferee may receive one transfer every 6 months, so they?ll
       be incented to transfer a block appropriately sized for their
       needs, which will further discourage deaggregation and keep
       smaller blocks available for smaller organizations.

The proposal would also have ARIN develop and operate a listing service
to facilitate transfers and provide an authoritative central source of
information on space available and requested for transfer.  It would not
prohibit private party transactions, but would require that potential
transferors and transferees be pre-qualified first, so that neither
party will encounter any unexpected surprises when they ask ARIN to
process the transfer.

Timetable for implementation: Immediately, with most aspects of policy
taking effect upon IANA exhaustion, per the policy text.





From bicknell at ufp.org  Mon Feb 11 11:09:31 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 11 Feb 2008 11:09:31 -0500
Subject: [ppml] Policy Proposal 2007-22: Expand timeframe of Additional
	Requests - Second Last Call
In-Reply-To: <47AB4195.6050904@arin.net>
References: <47AB4195.6050904@arin.net>
Message-ID: <20080211160931.GB33688@ussenterprise.ufp.org>


Typically proposals in last call receive very few comments.  I would
like to think this is a result of our policy process being quite
successful and leaving very little to discuss during the last call
time.

In this particular case there was some confusion over language.
This was due to changes at the meeting and due to a mistake in
getting the text posted to PPML.  Because of this, the AC would
find it useful in this particular case for several people to chime
in with "yes, we believe that was the proposal we discussed, and
yes, we believe there was community support."  Of course, if you
believe that was not the case, feel free to post your opinion as
well.

We're working behind the scenes to try and make sure this never happens
again.  Our apologies for the mix up.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20080211/f4c4fba6/attachment.bin>

From info at arin.net  Mon Feb 11 11:35:27 2008
From: info at arin.net (Member Services)
Date: Mon, 11 Feb 2008 11:35:27 -0500
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
Message-ID: <47B0794F.40205@arin.net>

Resending with a typo that has been corrected in 8.4.2 below. The 
original text is supposed to have "24 months" twice in that section.

Member Services
American Registry for Internet Numbers (ARIN)




ARIN received the following policy proposal. In accordance with the ARIN
Internet Resource Policy Evaluation Process, the proposal is being
posted to the ARIN Public Policy Mailing List (PPML) and being placed on
ARIN's website.

The ARIN Advisory Council (AC) will review this proposal at their next
regularly scheduled meeting. The AC may decide to:

   1. Accept the proposal as written. If the AC accepts the proposal, it
will be posted as a formal policy proposal to PPML and it will be
presented at a Public Policy Meeting.

   2. Not accept the proposal. If the AC does not accept the proposal,
the AC will explain their decision via the PPML. If a proposal is not
accepted, then the author may elect to use the petition process to
advance their proposal. If the author elects not to petition or the
petition fails, then the proposal will be closed.

The AC shepherds for this proposal are Scott Leibrand and Stacy Taylor.

The AC invites everyone to comment on this 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.

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal Name: IPv4 Transfer Policy Proposal

Author: ARIN Advisory Council

Proposal Version: 1.0

Submission Date: 02/07/2008

Proposal type: modify

Policy term: permanent

Policy statement:

Replace the current NRPM section 8 with the following --

8.         Transfers

[8.1.     Transfers ? retain as is:

Number resources are non-transferable and are not assignable to any
other organization unless ARIN has expressly and in writing approved a
request for transfer.  ARIN is tasked with making prudent decisions on
whether to approve the transfer of number resources.

It should be understood that number resources are not "sold" under ARIN
administration. Rather, number resources are assigned to an organization
for its exclusive use for the purpose stated in the request, provided
the terms of the Registration Services Agreement continue to be met and
the stated purpose for the number resources remains the same. Number
resources are administered and assigned according to ARIN's published
policies.

Number resources are issued, based on justified need, to organizations,
not to individuals representing those organizations. Thus, if a company
goes out of business, regardless of the reason, the point of contact
(POC) listed for the number resource does not have the authority to
sell, transfer, assign, or give the number resource to any other person
or organization. The POC must notify ARIN if a business fails so the
assigned number resources can be returned to the available pool of
number resources if a transfer is not requested and justified.]


[8.2 ? remove the word ?only?, and retitle to ?M&A Transfer Requirements?:

8.2.      M&A Transfer Requirements

ARIN will consider requests for the transfer of number resources upon
receipt of evidence that the new entity has acquired the assets which
had, as of the date of the acquisition or proposed reorganization,
justified the current entity's use of the number resource. Examples of
assets that justify use of the number resource include, but are not
limited to:

     * Existing customer base
     * Qualified hardware inventory
     * Specific software requirements.]


[8.3 ? retitle to ?M&A Transfer Documentation Requirements?:

8.3.      M&A Transfer Documentation Requirements

In evaluating a request for transfer, ARIN may require the requesting
organization to provide any of the following documents, as applicable,
plus any other documents deemed appropriate:

     * An authenticated copy of the instrument(s) effecting the transfer
       of assets, e.g., bill of sale, certificate of merger, contract,
       deed, or court decree
     * A detailed inventory of all assets utilized by the requesting
       party in maintaining and using the number resource
     * A list of the requesting party's customers using the number resource.

If further justification is required, the requesting party may be asked
to provide any of the following, or other supporting documentation, as
applicable:

     * A general listing of the assets or components acquired
     * A specific description of acquisitions, including:
           o Type and quantity of equipment
           o Customer base
     * A description of how number resources are being utilized
     * Network engineering plans, including:
           o Host counts
           o Subnet masking
           o Network diagrams
           o Reassignments to customers]

8.4.      Requirements for Simple Transfer of IPv4 Addresses

After the exhaustion of the IANA IPv4 free pool, ARIN will also process
IPv4 address transfer requests subject to the following conditions.

8.4.1    Conditions on the transferor:

     * The transferor resides in the ARIN service area.
     * The transferor has signed an RSA and/or a legacy RSA covering the
       IPv4 addresses transferred.
     * The transferor has no outstanding balances with ARIN.
     * The transferor has not received any IPv4 allocations or
       assignments from ARIN (through ordinary allocations or
       assignments, or through this Simple Transfer policy) within the
       preceding 24 months.
     * The transferor may not request any IPv4 allocations or assignments
       from ARIN (through ordinary allocations or assignments, or through
       this Simple Transfer policy) within the subsequent 24 months.

8.4.2    Conditions on the transferee:

     * The transferee resides in the ARIN service area and intends to use
       the transferred IPv4 addresses within the ARIN service area.
     * The transferee has no outstanding balances with ARIN.
     * The transferee?s need is confirmed by ARIN, according to current
       ARIN policies, including but not limited to confirmation of
       utilization rate of any prior IPv4 allocations, assignments, or
       previously transferred IPv4 addresses held by the transferee.
     * The transferee signs (or has previously signed) an RSA covering
       the IPv4 addresses transferred.
     * The transferee has not provided any IPv4 addresses for transfer
       through this Simple Transfer process within the preceding 24
       months.
     * The transferee may not provide any IPv4 addresses for transfer
       through this Simple Transfer process within the subsequent 24
       months, except in the case of business failure.
     * The transferee may only receive one IPv4 address transfer every 6
       months.



8.4.3    Conditions on the IPv4 address block to be transferred:

     * The IPv4 block must comply with applicable ARIN requirements,
       including minimum allocation size (i.e. NRPM 4.2.2., 4.2.4.,
       4.3.2., 4.3.6.).  However, an IPv4 allocation or assignment of /24
       or larger, but smaller than the current minimum allocation size,
       may be transferred as a whole resource, but may not be subdivided.
     * The IPv4 block must currently be registered for use within the
       ARIN service area, either as part of an address block assigned by
       IANA to ARIN, or as part of a legacy address block allocated
       within the ARIN service area.
     * There must exist no dispute as to the status of the IPv4 block or
       regarding the allocation or assignment of such block to the
       transferor.
     * The transferor may retain one contiguous address range out of
       their original allocation or assignment for their own use, and
       transfer the other contiguous address range.  If the address range
       to be transferred consists of multiple non-aggregatable CIDR
       blocks, each may be transferred to a different transferee.  The
       retained address range may not be further subdivided or
       transferred for a period of 12 months.

8.4.4    Fees

     * Completion of a transfer requires payment of a transfer fee
       according to ARIN?s schedule of fees.
     * The transferee will be subject to all future ARIN membership and
       service fees according to the transferee?s total address holdings.

8.4.5    Pre-qualification

     * An interested transferee must seek pre-qualification from ARIN to
       confirm its eligibility to receive a transfer (including
       satisfaction of need according to current ARIN policies) before
       making any solicitation for transfer.  Upon pre-qualification,
       ARIN will provide the transferee with documentation of the
       pre-qualification, including the size (CIDR prefix length) of the
       largest IPv4 address block the transferee is eligible to receive,
       and the expiration date of the pre-qualification.
     * An interested transferor must seek pre-qualification from ARIN to
       confirm its eligibility to offer a transfer (including lack of
       outstanding balances and having signed an RSA) before offering
       IPv4 address resources for transfer.  Upon pre-qualification, ARIN
       will provide the transferor with documentation of the
       pre-qualification, including the exact network address and size
       (CIDR prefix length) the transferor is eligible to provide, and
       the expiration date of the pre-qualification.

8.5.      Safe Harbor for IPv4 Transfers through this Simple Transfer
Process

IPv4 address resources being made available for transfer shall be exempt
from ARIN audit until expiration of the transfer pre-qualification or
completion of the transfer.  In the event that a transfer
pre-qualification expires, ARIN shall have up to 90 days to initiate an
audit prior to this exemption being reinstated through subsequent
transfer pre-qualification. This will not extend the end of the exemption.

8.6.      Simple IPv4 Transfers to or from Organizations Under Common
Ownership or Control

If an IPv4 transferor or transferee is under common ownership or control
with any other organization that holds one or more IPv4 blocks, the IPv4
transfer request must report all such organizations under common
ownership or control.

When evaluating compliance with IPv4 Simple Transfer conditions, ARIN
may consider a transferor?s transfer request in light of requests from
other organizations under common ownership or control with the
transferor.  Similarly, ARIN may consider a transferee?s request in
light of requests from other organizations under common ownership or
control with the transferee.  In evaluating requests from other
organizations under common ownership or control, ARIN staff will
consider the relationship between the organizations, the degree of
coordination between the organizations, and the bona fide use of the
addresses at issue to determine whether all appropriate conditions are met.

8.7.      Record-keeping and Publication of Simple Transfers of IPv4
Addresses

ARIN will develop and operate a listing service to assist interested
transferors and transferees by providing them a centralized location to
post information about IPv4 blocks available from prequalified
transferors and IPv4 blocks needed by prequalified transferees.

After completion of the transfer, ARIN will update the registration
records pertaining to the IPv4 block at issue.  ARIN will adjust its
records as to the holdings of the transferor and transferee.

After the transfer, ARIN will publish WHOIS data that reflects the
current allocation or assignment of the transferred block.  ARIN will
also make available information about any prior recipient(s) of such
block.  ARIN will also publish a log of all transfers, including block,
transferor, transferee, and date.


Rationale:

The ARIN Board of Trustees asked the Advisory Council to consider a set
of questions around the depletion of the free pool of IPv4 addresses,
the transition to IPv6 for Internet address needs in the future, and
ARIN's possible role in easing the transition.

Over the past few years the AC has spent a great deal of time reflecting
on these issues as a group, as individuals, and in consultation with
the community. One outcome of this process is this policy proposal,
which the AC is submitting for consideration at the next meeting. We are
proposing some changes to existing ARIN policy regarding the transfer of
IP address block registrations between subscribers, which will allow for
the emergence of trade in IPv4 address space, with ARIN to provide a
listing service for address blocks available for transfer under the
liberalized policy.  We are aware that this proposal, if adopted, will
mark a major change in ARIN's role in the community and the Internet.

This policy proposal would create a transfer mechanism for IPv4 number
resources between those who have excess resources and those who have a
need, thereby allowing ARIN to continue to serve its mission after IANA
free pool exhaustion.  This proposal would also set conditions on such
transfers intended to preserve as much as possible the existing policy
related to efficient, needs-based resource issuance, and would leverage
ARIN's extensive control systems, audit trails, and recognized position
as a trusted agent to avoid speculation and hoarding and diminish the
likelihood and extent of an uncontrolled 'black market' where the risk
and potential for fraud is immeasurably higher.

Many of the transfer conditions are self-explanatory, but some worth
highlighting are that:

     * To discourage speculation, a waiting period (proposed at 24
       months) is required before a transferee (or ordinary resource
       recipient) can become a transferor, or vice versa.
     * Transferees must qualify for IPv4 space (just as they do today
       when getting it from ARIN) before they can receive address space
       by transfer, or solicit space on a listing service.
     * To discourage unnecessarily rapid growth of routing tables, an
       allocation or assignment may not be arbitrarily deaggregated.  To
       allow a transferor to downsize within their existing space, they
       may split off a contiguous address range, once every 12 months,
       and transfer the resulting netblock(s), which are subject to
       ARIN?s minimum allocation size, to one or more transferee(s).
     * A transferee may receive one transfer every 6 months, so they?ll
       be incented to transfer a block appropriately sized for their
       needs, which will further discourage deaggregation and keep
       smaller blocks available for smaller organizations.

The proposal would also have ARIN develop and operate a listing service
to facilitate transfers and provide an authoritative central source of
information on space available and requested for transfer.  It would not
prohibit private party transactions, but would require that potential
transferors and transferees be pre-qualified first, so that neither
party will encounter any unexpected surprises when they ask ARIN to
process the transfer.

Timetable for implementation: Immediately, with most aspects of policy
taking effect upon IANA exhaustion, per the policy text.






From Lee.Howard at stanleyassociates.com  Mon Feb 11 11:56:29 2008
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Mon, 11 Feb 2008 11:56:29 -0500
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <47B0794F.40205@arin.net>
Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB408841E6E@CL-S-EX-1.stanleyassociates.com>

I'm not commenting on the merit of the proposal, but on its
clarity.


> 8.4.3    Conditions on the IPv4 address block to be transferred:
> 
>      * The IPv4 block must comply with applicable ARIN requirements,
>        including minimum allocation size (i.e. NRPM 4.2.2., 4.2.4.,
>        4.3.2., 4.3.6.).  However, an IPv4 allocation or 
> assignment of /24
>        or larger, but smaller than the current minimum 
> allocation size,
>        may be transferred as a whole resource, but may not be 
> subdivided.

Is this intended to mean swamp space can remain swampy, but other
space can't be subdivided in /24?  It looks like it says the block
must meet minimum transfer size, unless it's a /24 or larger.

>      * The transferor may retain one contiguous address range out of
>        their original allocation or assignment for their own use, and
>        transfer the other contiguous address range.  If the 
> address range
>        to be transferred consists of multiple non-aggregatable CIDR
>        blocks, each may be transferred to a different transferee.  The
>        retained address range may not be further subdivided or
>        transferred for a period of 12 months.

I can transfer my hypothetical /16 as 254 /24s and keep one for myself?

Lee


From dlw+arin at tellme.com  Mon Feb 11 12:06:26 2008
From: dlw+arin at tellme.com (David Williamson)
Date: Mon, 11 Feb 2008 09:06:26 -0800
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB408841E6E@CL-S-EX-1.stanleyassociates.com>
References: <47B0794F.40205@arin.net>
	<369EB04A0951824ABE7D8BAC67AF9BB408841E6E@CL-S-EX-1.stanleyassociates.com>
Message-ID: <20080211170626.GN8368@shell01.cell.sv2.tellme.com>

On Mon, Feb 11, 2008 at 11:56:29AM -0500, Howard, W. Lee wrote:
> > 8.4.3    Conditions on the IPv4 address block to be transferred:
> > 
> >      * The IPv4 block must comply with applicable ARIN requirements,
> >        including minimum allocation size (i.e. NRPM 4.2.2., 4.2.4.,
> >        4.3.2., 4.3.6.).  However, an IPv4 allocation or 
> > assignment of /24
> >        or larger, but smaller than the current minimum 
> > allocation size,
> >        may be transferred as a whole resource, but may not be 
> > subdivided.
> 
> Is this intended to mean swamp space can remain swampy, but other
> space can't be subdivided in /24?  It looks like it says the block
> must meet minimum transfer size, unless it's a /24 or larger.

I'm also a bit confused by this.  It does seem to imply that I cannot
get a PI /24 from ARIN directly, but I could get one transferred to
me.  That seems unexpected.  If the intent is to permit resources
already allocated at some size that is presently below the minimum
requirements (i.e., the swamp), this should get some different
verbiage.  If the intent is really to permit transfers down to the /24
limit, we should go ahead and change the minimum allocation and
assignment sizes to match.

For the record, I still think that multi-homed PI users would really
like a smaller minimum size than /22.  It would certainly promote
greater efficiency, albeit at the expense of routing slots, which are
going to get consumed anyway for most multi-homed sites.

So, what is this supposed to be?

-David


From owen at delong.com  Mon Feb 11 12:09:47 2008
From: owen at delong.com (Owen DeLong)
Date: Mon, 11 Feb 2008 09:09:47 -0800
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB408841E6E@CL-S-EX-1.stanleyassociates.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB408841E6E@CL-S-EX-1.stanleyassociates.com>
Message-ID: <1AF7D7C2-4AF3-431E-9A58-34F81649C5C6@delong.com>


On Feb 11, 2008, at 8:56 AM, Howard, W. Lee wrote:

> I'm not commenting on the merit of the proposal, but on its
> clarity.
>
>
>> 8.4.3    Conditions on the IPv4 address block to be transferred:
>>
>>     * The IPv4 block must comply with applicable ARIN requirements,
>>       including minimum allocation size (i.e. NRPM 4.2.2., 4.2.4.,
>>       4.3.2., 4.3.6.).  However, an IPv4 allocation or
>> assignment of /24
>>       or larger, but smaller than the current minimum
>> allocation size,
>>       may be transferred as a whole resource, but may not be
>> subdivided.
>
> Is this intended to mean swamp space can remain swampy, but other
> space can't be subdivided in /24?  It looks like it says the block
> must meet minimum transfer size, unless it's a /24 or larger.
>
It is meant to prevent the subdivision of anything smaller than the
current minimum, but, allow transfers only of /24s or larger.

>>     * The transferor may retain one contiguous address range out of
>>       their original allocation or assignment for their own use, and
>>       transfer the other contiguous address range.  If the
>> address range
>>       to be transferred consists of multiple non-aggregatable CIDR
>>       blocks, each may be transferred to a different transferee.  The
>>       retained address range may not be further subdivided or
>>       transferred for a period of 12 months.
>
> I can transfer my hypothetical /16 as 254 /24s and keep one for  
> myself?
>
No.  You can transfer your hypothetical /16 as follows:
	Keep 1 /24
	Transfer the remaining
		/24
		/23
		/22
		/21
		/20
		/19
		/18
		/17
	as separate blocks.

That is why we specified "multiple non-aggregatable" blocks.

Owen

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



From bicknell at ufp.org  Mon Feb 11 12:15:23 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 11 Feb 2008 12:15:23 -0500
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB408841E6E@CL-S-EX-1.stanleyassociates.com>
References: <47B0794F.40205@arin.net>
	<369EB04A0951824ABE7D8BAC67AF9BB408841E6E@CL-S-EX-1.stanleyassociates.com>
Message-ID: <20080211171523.GA37775@ussenterprise.ufp.org>


I think you went right to the part of the proposal that's been one
of the hardest for the AC to craft.  Indeed, there are some discussions
going on inside the AC we might have liked to finish before the
proposal deadline, but it did not work that way.

There are several competing forces under the general umbrella of
prefix length size.  In no particular order:

- Preventing massive deaggregation.  We would like to prevent a /8 from
  showing up in the routing table as 65536 /24's.

- Allowing deaggregation.  A /8 is not a desireable element on its own,
  as few would pass the requirements to justify need, and we may have
  the problem of few being able to afford it.

- What role does existing ARIN criteria play?  Should we allow
  deaggregation simply to ARIN's current limits?

- What rules are applied to blocks that no longer meet current policy?
  There were /24's given out in the past, but you can't get one today.

- If we limit the amount of deaggregation does that limit the liquidity
  of the market?

Rather than nitpick the language of the current proposal I think
the AC would find it more useful if the community could articulate
how they want it to work.  We have just under 30 more days to adjust
the language before the Denver meeting.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20080211/501d8218/attachment.bin>

From tedm at ipinc.net  Mon Feb 11 13:05:29 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 11 Feb 2008 10:05:29 -0800
Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no
	one."
In-Reply-To: <p06240801c3d3e0df6e6b@[192.168.3.76]>
Message-ID: <NABBJOELMNGNJNGPKDDOCEHBHFAA.tedm@ipinc.net>



>-----Original Message-----
>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>John Curran
>Sent: Saturday, February 09, 2008 3:35 PM
>To: bmanning at vacation.karoshi.com
>Cc: Public Policy Mailing List
>Subject: Re: [ppml] "Who's afraid of IPv4 address depletion? Apparently
>no one."
>
>
>At 10:56 PM +0000 2/9/08, bmanning at vacation.karoshi.com wrote:
>>
>>	i think a safe presumption is that this may be a
>>	predominant structure as long as there are "arrogant
>>	twits" who maintain the fiction that only IPv4 transport
>>	is needed to get to their content/eyeballs.  e.g. if
>>	facebook never supports IPv6 transport, this will be common.
>>	Facebook will never see IPv6 demand and claim "all is well"
>>	with IPv4 and the IPv6 hype is just that.
>
>Facebook, Yahoo!, Google, MSN, Youtube, .... the list goes on and on.
>I wouldn't expect any of them to see measurable demand for IPv6
>until there's a sizable IPv6-only user community.
>

This is the classic chicken-and-egg program or catch-22 as you would
have it.  And it's an argument easily sidestepped.

Yahoo and Facebook don't configure the IPv4 and IPv6 stacks of our
customers, so what they have to say about IPv6 deployment is of
no consequence.

What -I- as the ISP say to my customers is the only thing of any real
consequence.

When we have a business customer connect to us, 9/10's of the time
we are doing the configuration on their routers, and 1/2 of the time
we are specing to them what -new- router to buy.  I've had customers
with perfectly good Cisco devices leftover from their prior ISP tell
me they still want to buy a new router, even though I tell them we
could reconfigure their old device.  That's beside the point, though.

If an end-user comes to me and says they want to connect to us via
DSL or Dialup or whatever, I'll direct them to the how-to's on our
website as to how to configure their system.  When the time is ready
for IPv6 those how-to's will be re-written to enable all the IPv6 stuff
on their system.  The end users will blindly follow whatever I or
my tech support group tells them to do, and if that means enable IPv6
they will do it.  As they don't really understand how IPv4 works, the
fact that they don't understand how IPv6 works is of no consequence -
none of them are in the position to question my instructions in the first
place.

For my corporate customers, if I start telling them they have to get
new routers to support IPv6, most of them will simply say no problem
and do it.  Maybe not immediately but eventually.  These are customers
that are paying me to tell them what they need to do to connect to the
Internet, so if I tell them they need to be IPv6 compliant to their
firewall (at least) they will do it.

I think people are really making this IPv4 <-> IPv6 transition sound
far more difficult than it really needs to be.  Customers come in 2
categories, informed or ignorant.  The vast number are ignorant and
they are happy to stay that way - they no more want to know how to
configure a router than they want to know how to change the sparkplugs
in their car engine.  The informed customer, on the other hand,
merely needs to be told the cons of remaining IPv4 and left alone to
their own devices.

The sum fact of it is that the vast majority of customers are just going
to do what their ISP tells them to do.  If all the ISP's start telling
customers to switch over to IPv6, the very small minority of informed
customers who want to fight against it based on whatever cost/benefit
they come up with, are going to find themselves outnumbered.

Much like the network admins who argued against 10BaseT claiming it was
no faster than 10Base2, they will be snowed over by the herd.

Ted


From dlw+arin at tellme.com  Mon Feb 11 13:47:36 2008
From: dlw+arin at tellme.com (David Williamson)
Date: Mon, 11 Feb 2008 10:47:36 -0800
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <20080211171523.GA37775@ussenterprise.ufp.org>
References: <47B0794F.40205@arin.net>
	<369EB04A0951824ABE7D8BAC67AF9BB408841E6E@CL-S-EX-1.stanleyassociates.com>
	<20080211171523.GA37775@ussenterprise.ufp.org>
Message-ID: <20080211184736.GO8368@shell01.cell.sv2.tellme.com>

On Mon, Feb 11, 2008 at 12:15:23PM -0500, Leo Bicknell wrote:
> Rather than nitpick the language of the current proposal I think
> the AC would find it more useful if the community could articulate
> how they want it to work.  We have just under 30 more days to adjust
> the language before the Denver meeting.

I'm still contemplating the overall impact of the entire proposal, so
this is, at best, a preliminary thought.  *If* ARIN is going to get
into the transfer process, I agree that the tension between
deaggregation and policy is going to be a key problem.

I think the intent of the proposal as Owen has outlined it is a
reasonable compromise, for now.  That is, blocks smaller than the
current minimum limits should not be transferred unless they already
exist as a unique resource record with ARIN at that sub-minimum size.
Additionally, in no case should a block smaller than /24 be
transferred.

At some point, I suspect the /24 limit will get fuzzy, and we'll need
to revisit that.  Then again, I think the existing limits are too
large. :)

I'm not sure that taking a hypothetical /16 and breaking it into
completely deaggregated /22s should be against the transfer rules,
though.  Much as a /16 isn't very useful for most entities, nor is a
/17.

I think I'm broadly in favor of this proposal at this time, but I need
to give it some more thought.

-David


From raul at lacnic.net  Mon Feb 11 15:52:23 2008
From: raul at lacnic.net (Raul Echeberria)
Date: Mon, 11 Feb 2008 17:52:23 -0300
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <47B0794F.40205@arin.net>
References: <47B0794F.40205@arin.net>
Message-ID: <7.0.1.0.1.20080211164859.05618d40@lacnic.net>


Could the author of the proposal explain what is 
the justification for requiring that the 
transferee should also belong to ARIN's region?
It is only a question and it doesn't imply any 
specific opinion about the topic.

Ra?l





At 01:35 p.m. 11/02/2008, Member Services wrote:
>Resending with a typo that has been corrected in 8.4.2 below. The
>original text is supposed to have "24 months" twice in that section.
>
>Member Services
>American Registry for Internet Numbers (ARIN)
>
>
>
>
>ARIN received the following policy proposal. In accordance with the ARIN
>Internet Resource Policy Evaluation Process, the proposal is being
>posted to the ARIN Public Policy Mailing List (PPML) and being placed on
>ARIN's website.
>
>The ARIN Advisory Council (AC) will review this proposal at their next
>regularly scheduled meeting. The AC may decide to:
>
>    1. Accept the proposal as written. If the AC accepts the proposal, it
>will be posted as a formal policy proposal to PPML and it will be
>presented at a Public Policy Meeting.
>
>    2. Not accept the proposal. If the AC does not accept the proposal,
>the AC will explain their decision via the PPML. If a proposal is not
>accepted, then the author may elect to use the petition process to
>advance their proposal. If the author elects not to petition or the
>petition fails, then the proposal will be closed.
>
>The AC shepherds for this proposal are Scott Leibrand and Stacy Taylor.
>
>The AC invites everyone to comment on this 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.
>
>The ARIN Internet Resource Policy Evaluation Process can be found at:
>http://www.arin.net/policy/irpep.html
>
>Mailing list subscription information can be found at:
>http://www.arin.net/mailing_lists/
>
>Regards,
>
>Member Services
>American Registry for Internet Numbers (ARIN)
>
>
>## * ##
>
>
>Policy Proposal Name: IPv4 Transfer Policy Proposal
>
>Author: ARIN Advisory Council
>
>Proposal Version: 1.0
>
>Submission Date: 02/07/2008
>
>Proposal type: modify
>
>Policy term: permanent
>
>Policy statement:
>
>Replace the current NRPM section 8 with the following --
>
>8.         Transfers
>
>[8.1.     Transfers ? retain as is:
>
>Number resources are non-transferable and are not assignable to any
>other organization unless ARIN has expressly and in writing approved a
>request for transfer.  ARIN is tasked with making prudent decisions on
>whether to approve the transfer of number resources.
>
>It should be understood that number resources are not "sold" under ARIN
>administration. Rather, number resources are assigned to an organization
>for its exclusive use for the purpose stated in the request, provided
>the terms of the Registration Services Agreement continue to be met and
>the stated purpose for the number resources remains the same. Number
>resources are administered and assigned according to ARIN's published
>policies.
>
>Number resources are issued, based on justified need, to organizations,
>not to individuals representing those organizations. Thus, if a company
>goes out of business, regardless of the reason, the point of contact
>(POC) listed for the number resource does not have the authority to
>sell, transfer, assign, or give the number resource to any other person
>or organization. The POC must notify ARIN if a business fails so the
>assigned number resources can be returned to the available pool of
>number resources if a transfer is not requested and justified.]
>
>
>[8.2 ? remove the word ?only?, and retitle to ?M&A Transfer Requirements?:
>
>8.2.      M&A Transfer Requirements
>
>ARIN will consider requests for the transfer of number resources upon
>receipt of evidence that the new entity has acquired the assets which
>had, as of the date of the acquisition or proposed reorganization,
>justified the current entity's use of the number resource. Examples of
>assets that justify use of the number resource include, but are not
>limited to:
>
>      * Existing customer base
>      * Qualified hardware inventory
>      * Specific software requirements.]
>
>
>[8.3 ? retitle to ?M&A Transfer Documentation Requirements?:
>
>8.3.      M&A Transfer Documentation Requirements
>
>In evaluating a request for transfer, ARIN may require the requesting
>organization to provide any of the following documents, as applicable,
>plus any other documents deemed appropriate:
>
>      * An authenticated copy of the instrument(s) effecting the transfer
>        of assets, e.g., bill of sale, certificate of merger, contract,
>        deed, or court decree
>      * A detailed inventory of all assets utilized by the requesting
>        party in maintaining and using the number resource
>      * A list of the requesting party's customers using the number resource.
>
>If further justification is required, the requesting party may be asked
>to provide any of the following, or other supporting documentation, as
>applicable:
>
>      * A general listing of the assets or components acquired
>      * A specific description of acquisitions, including:
>            o Type and quantity of equipment
>            o Customer base
>      * A description of how number resources are being utilized
>      * Network engineering plans, including:
>            o Host counts
>            o Subnet masking
>            o Network diagrams
>            o Reassignments to customers]
>
>8.4.      Requirements for Simple Transfer of IPv4 Addresses
>
>After the exhaustion of the IANA IPv4 free pool, ARIN will also process
>IPv4 address transfer requests subject to the following conditions.
>
>8.4.1    Conditions on the transferor:
>
>      * The transferor resides in the ARIN service area.
>      * The transferor has signed an RSA and/or a legacy RSA covering the
>        IPv4 addresses transferred.
>      * The transferor has no outstanding balances with ARIN.
>      * The transferor has not received any IPv4 allocations or
>        assignments from ARIN (through ordinary allocations or
>        assignments, or through this Simple Transfer policy) within the
>        preceding 24 months.
>      * The transferor may not request any IPv4 allocations or assignments
>        from ARIN (through ordinary allocations or assignments, or through
>        this Simple Transfer policy) within the subsequent 24 months.
>
>8.4.2    Conditions on the transferee:
>
>      * The transferee resides in the ARIN service area and intends to use
>        the transferred IPv4 addresses within the ARIN service area.
>      * The transferee has no outstanding balances with ARIN.
>      * The transferee?s need is confirmed by ARIN, according to current
>        ARIN policies, including but not limited to confirmation of
>        utilization rate of any prior IPv4 allocations, assignments, or
>        previously transferred IPv4 addresses held by the transferee.
>      * The transferee signs (or has previously signed) an RSA covering
>        the IPv4 addresses transferred.
>      * The transferee has not provided any IPv4 addresses for transfer
>        through this Simple Transfer process within the preceding 24
>        months.
>      * The transferee may not provide any IPv4 addresses for transfer
>        through this Simple Transfer process within the subsequent 24
>        months, except in the case of business failure.
>      * The transferee may only receive one IPv4 address transfer every 6
>        months.
>
>
>
>8.4.3    Conditions on the IPv4 address block to be transferred:
>
>      * The IPv4 block must comply with applicable ARIN requirements,
>        including minimum allocation size (i.e. NRPM 4.2.2., 4.2.4.,
>        4.3.2., 4.3.6.).  However, an IPv4 allocation or assignment of /24
>        or larger, but smaller than the current minimum allocation size,
>        may be transferred as a whole resource, but may not be subdivided.
>      * The IPv4 block must currently be registered for use within the
>        ARIN service area, either as part of an address block assigned by
>        IANA to ARIN, or as part of a legacy address block allocated
>        within the ARIN service area.
>      * There must exist no dispute as to the status of the IPv4 block or
>        regarding the allocation or assignment of such block to the
>        transferor.
>      * The transferor may retain one contiguous address range out of
>        their original allocation or assignment for their own use, and
>        transfer the other contiguous address range.  If the address range
>        to be transferred consists of multiple non-aggregatable CIDR
>        blocks, each may be transferred to a different transferee.  The
>        retained address range may not be further subdivided or
>        transferred for a period of 12 months.
>
>8.4.4    Fees
>
>      * Completion of a transfer requires payment of a transfer fee
>        according to ARIN?s schedule of fees.
>      * The transferee will be subject to all future ARIN membership and
>        service fees according to the transferee?s total address holdings.
>
>8.4.5    Pre-qualification
>
>      * An interested transferee must seek pre-qualification from ARIN to
>        confirm its eligibility to receive a transfer (including
>        satisfaction of need according to current ARIN policies) before
>        making any solicitation for transfer.  Upon pre-qualification,
>        ARIN will provide the transferee with documentation of the
>        pre-qualification, including the size (CIDR prefix length) of the
>        largest IPv4 address block the transferee is eligible to receive,
>        and the expiration date of the pre-qualification.
>      * An interested transferor must seek pre-qualification from ARIN to
>        confirm its eligibility to offer a transfer (including lack of
>        outstanding balances and having signed an RSA) before offering
>        IPv4 address resources for transfer.  Upon pre-qualification, ARIN
>        will provide the transferor with documentation of the
>        pre-qualification, including the exact network address and size
>        (CIDR prefix length) the transferor is eligible to provide, and
>        the expiration date of the pre-qualification.
>
>8.5.      Safe Harbor for IPv4 Transfers through this Simple Transfer
>Process
>
>IPv4 address resources being made available for transfer shall be exempt
>from ARIN audit until expiration of the transfer pre-qualification or
>completion of the transfer.  In the event that a transfer
>pre-qualification expires, ARIN shall have up to 90 days to initiate an
>audit prior to this exemption being reinstated through subsequent
>transfer pre-qualification. This will not extend the end of the exemption.
>
>8.6.      Simple IPv4 Transfers to or from Organizations Under Common
>Ownership or Control
>
>If an IPv4 transferor or transferee is under common ownership or control
>with any other organization that holds one or more IPv4 blocks, the IPv4
>transfer request must report all such organizations under common
>ownership or control.
>
>When evaluating compliance with IPv4 Simple Transfer conditions, ARIN
>may consider a transferor?s transfer request in light of requests from
>other organizations under common ownership or control with the
>transferor.  Similarly, ARIN may consider a transferee?s request in
>light of requests from other organizations under common ownership or
>control with the transferee.  In evaluating requests from other
>organizations under common ownership or control, ARIN staff will
>consider the relationship between the organizations, the degree of
>coordination between the organizations, and the bona fide use of the
>addresses at issue to determine whether all appropriate conditions are met.
>
>8.7.      Record-keeping and Publication of Simple Transfers of IPv4
>Addresses
>
>ARIN will develop and operate a listing service to assist interested
>transferors and transferees by providing them a centralized location to
>post information about IPv4 blocks available from prequalified
>transferors and IPv4 blocks needed by prequalified transferees.
>
>After completion of the transfer, ARIN will update the registration
>records pertaining to the IPv4 block at issue.  ARIN will adjust its
>records as to the holdings of the transferor and transferee.
>
>After the transfer, ARIN will publish WHOIS data that reflects the
>current allocation or assignment of the transferred block.  ARIN will
>also make available information about any prior recipient(s) of such
>block.  ARIN will also publish a log of all transfers, including block,
>transferor, transferee, and date.
>
>
>Rationale:
>
>The ARIN Board of Trustees asked the Advisory Council to consider a set
>of questions around the depletion of the free pool of IPv4 addresses,
>the transition to IPv6 for Internet address needs in the future, and
>ARIN's possible role in easing the transition.
>
>Over the past few years the AC has spent a great deal of time reflecting
>on these issues as a group, as individuals, and in consultation with
>the community. One outcome of this process is this policy proposal,
>which the AC is submitting for consideration at the next meeting. We are
>proposing some changes to existing ARIN policy regarding the transfer of
>IP address block registrations between subscribers, which will allow for
>the emergence of trade in IPv4 address space, with ARIN to provide a
>listing service for address blocks available for transfer under the
>liberalized policy.  We are aware that this proposal, if adopted, will
>mark a major change in ARIN's role in the community and the Internet.
>
>This policy proposal would create a transfer mechanism for IPv4 number
>resources between those who have excess resources and those who have a
>need, thereby allowing ARIN to continue to serve its mission after IANA
>free pool exhaustion.  This proposal would also set conditions on such
>transfers intended to preserve as much as possible the existing policy
>related to efficient, needs-based resource issuance, and would leverage
>ARIN's extensive control systems, audit trails, and recognized position
>as a trusted agent to avoid speculation and hoarding and diminish the
>likelihood and extent of an uncontrolled 'black market' where the risk
>and potential for fraud is immeasurably higher.
>
>Many of the transfer conditions are self-explanatory, but some worth
>highlighting are that:
>
>      * To discourage speculation, a waiting period (proposed at 24
>        months) is required before a transferee (or ordinary resource
>        recipient) can become a transferor, or vice versa.
>      * Transferees must qualify for IPv4 space (just as they do today
>        when getting it from ARIN) before they can receive address space
>        by transfer, or solicit space on a listing service.
>      * To discourage unnecessarily rapid growth of routing tables, an
>        allocation or assignment may not be arbitrarily deaggregated.  To
>        allow a transferor to downsize within their existing space, they
>        may split off a contiguous address range, once every 12 months,
>        and transfer the resulting netblock(s), which are subject to
>        ARIN?s minimum allocation size, to one or more transferee(s).
>      * A transferee may receive one transfer every 6 months, so they?ll
>        be incented to transfer a block appropriately sized for their
>        needs, which will further discourage deaggregation and keep
>        smaller blocks available for smaller organizations.
>
>The proposal would also have ARIN develop and operate a listing service
>to facilitate transfers and provide an authoritative central source of
>information on space available and requested for transfer.  It would not
>prohibit private party transactions, but would require that potential
>transferors and transferees be pre-qualified first, so that neither
>party will encounter any unexpected surprises when they ask ARIN to
>process the transfer.
>
>Timetable for implementation: Immediately, with most aspects of policy
>taking effect upon IANA exhaustion, per the policy text.
>
>
>
>
>_______________________________________________
>PPML
>You are receiving this message because you are 
>subscribed to the ARIN Public Policy
>Mailing List (PPML at arin.net).
>Unsubscribe or manage your mailing list subscription at:
>http://lists.arin.net/mailman/listinfo/ppml
>Please contact the ARIN Member Services Help 
>Desk at info at arin.net if you experience any issues.
>
>
>--
>No virus found in this incoming message.
>Checked by AVG Free Edition.
>Version: 7.5.516 / Virus Database: 269.20.2/1271 
>- Release Date: 11/02/2008 08:16 a.m.




From sleibrand at internap.com  Mon Feb 11 15:15:54 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Mon, 11 Feb 2008 14:15:54 -0600
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <7.0.1.0.1.20080211164859.05618d40@lacnic.net>
References: <47B0794F.40205@arin.net>
	<7.0.1.0.1.20080211164859.05618d40@lacnic.net>
Message-ID: <47B0ACFA.5070202@internap.com>

Raul,

I can speak as an author, but not for the entire AC (which, 
collectively, are the authors):

The global policy framework basically allows three types of policies: 
local to a single RIR, globally coordinated, or global. The latter 
require consensus among multiple RIRs as to a course of action, which 
tends to be an extended process that only moves forward if there is 
significant consensus around an issue, and even then fairly slowly. For 
that reason, we didn't want to make this a globally coordinated or 
global policy at this time.

If we were to allow transferees from outside ARIN's service region, and 
not make this a globally coordinated policy (to coordinate transfer of 
the registration to the local RIR), we would open up the possibility of 
"registry shopping", encouraging organizations to go to RIRs outside 
their region to get IPv4 space. This would defeat the purpose of having 
a local RIR in the first place.

My own personal crystal ball shows a possible future where several RIRs 
each adopt their own transfer policy, with somewhat different conditions 
and requirements, to meet their own membership's needs. We would then 
need to do some inter-RIR coordination to enable some sort of 
inter-region transfer, and work out all the details of how records would 
be kept current in such a scenario, and which RIR each organization 
would deal with.

So, in summary, this is a first attempt at getting something reasonable 
in place in the ARIN region, and I fully expect to work with other RIRs 
to make arrangements for transferring space between regions as well.

-Scott

Raul Echeberria wrote:
> Could the author of the proposal explain what is 
> the justification for requiring that the 
> transferee should also belong to ARIN's region?
> It is only a question and it doesn't imply any 
> specific opinion about the topic.
>
> Ra?l
>
>
>
>
>
> At 01:35 p.m. 11/02/2008, Member Services wrote:
>   
>> Resending with a typo that has been corrected in 8.4.2 below. The
>> original text is supposed to have "24 months" twice in that section.
>>
>> Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>>
>>
>> ARIN received the following policy proposal. In accordance with the ARIN
>> Internet Resource Policy Evaluation Process, the proposal is being
>> posted to the ARIN Public Policy Mailing List (PPML) and being placed on
>> ARIN's website.
>>
>> The ARIN Advisory Council (AC) will review this proposal at their next
>> regularly scheduled meeting. The AC may decide to:
>>
>>    1. Accept the proposal as written. If the AC accepts the proposal, it
>> will be posted as a formal policy proposal to PPML and it will be
>> presented at a Public Policy Meeting.
>>
>>    2. Not accept the proposal. If the AC does not accept the proposal,
>> the AC will explain their decision via the PPML. If a proposal is not
>> accepted, then the author may elect to use the petition process to
>> advance their proposal. If the author elects not to petition or the
>> petition fails, then the proposal will be closed.
>>
>> The AC shepherds for this proposal are Scott Leibrand and Stacy Taylor.
>>
>> The AC invites everyone to comment on this 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.
>>
>> The ARIN Internet Resource Policy Evaluation Process can be found at:
>> http://www.arin.net/policy/irpep.html
>>
>> Mailing list subscription information can be found at:
>> http://www.arin.net/mailing_lists/
>>
>> Regards,
>>
>> Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> ## * ##
>>
>>
>> Policy Proposal Name: IPv4 Transfer Policy Proposal
>>
>> Author: ARIN Advisory Council
>>
>> Proposal Version: 1.0
>>
>> Submission Date: 02/07/2008
>>
>> Proposal type: modify
>>
>> Policy term: permanent
>>
>> Policy statement:
>>
>> Replace the current NRPM section 8 with the following --
>>
>> 8.         Transfers
>>
>> [8.1.     Transfers ? retain as is:
>>
>> Number resources are non-transferable and are not assignable to any
>> other organization unless ARIN has expressly and in writing approved a
>> request for transfer.  ARIN is tasked with making prudent decisions on
>> whether to approve the transfer of number resources.
>>
>> It should be understood that number resources are not "sold" under ARIN
>> administration. Rather, number resources are assigned to an organization
>> for its exclusive use for the purpose stated in the request, provided
>> the terms of the Registration Services Agreement continue to be met and
>> the stated purpose for the number resources remains the same. Number
>> resources are administered and assigned according to ARIN's published
>> policies.
>>
>> Number resources are issued, based on justified need, to organizations,
>> not to individuals representing those organizations. Thus, if a company
>> goes out of business, regardless of the reason, the point of contact
>> (POC) listed for the number resource does not have the authority to
>> sell, transfer, assign, or give the number resource to any other person
>> or organization. The POC must notify ARIN if a business fails so the
>> assigned number resources can be returned to the available pool of
>> number resources if a transfer is not requested and justified.]
>>
>>
>> [8.2 ? remove the word ?only?, and retitle to ?M&A Transfer Requirements?:
>>
>> 8.2.      M&A Transfer Requirements
>>
>> ARIN will consider requests for the transfer of number resources upon
>> receipt of evidence that the new entity has acquired the assets which
>> had, as of the date of the acquisition or proposed reorganization,
>> justified the current entity's use of the number resource. Examples of
>> assets that justify use of the number resource include, but are not
>> limited to:
>>
>>      * Existing customer base
>>      * Qualified hardware inventory
>>      * Specific software requirements.]
>>
>>
>> [8.3 ? retitle to ?M&A Transfer Documentation Requirements?:
>>
>> 8.3.      M&A Transfer Documentation Requirements
>>
>> In evaluating a request for transfer, ARIN may require the requesting
>> organization to provide any of the following documents, as applicable,
>> plus any other documents deemed appropriate:
>>
>>      * An authenticated copy of the instrument(s) effecting the transfer
>>        of assets, e.g., bill of sale, certificate of merger, contract,
>>        deed, or court decree
>>      * A detailed inventory of all assets utilized by the requesting
>>        party in maintaining and using the number resource
>>      * A list of the requesting party's customers using the number resource.
>>
>> If further justification is required, the requesting party may be asked
>> to provide any of the following, or other supporting documentation, as
>> applicable:
>>
>>      * A general listing of the assets or components acquired
>>      * A specific description of acquisitions, including:
>>            o Type and quantity of equipment
>>            o Customer base
>>      * A description of how number resources are being utilized
>>      * Network engineering plans, including:
>>            o Host counts
>>            o Subnet masking
>>            o Network diagrams
>>            o Reassignments to customers]
>>
>> 8.4.      Requirements for Simple Transfer of IPv4 Addresses
>>
>> After the exhaustion of the IANA IPv4 free pool, ARIN will also process
>> IPv4 address transfer requests subject to the following conditions.
>>
>> 8.4.1    Conditions on the transferor:
>>
>>      * The transferor resides in the ARIN service area.
>>      * The transferor has signed an RSA and/or a legacy RSA covering the
>>        IPv4 addresses transferred.
>>      * The transferor has no outstanding balances with ARIN.
>>      * The transferor has not received any IPv4 allocations or
>>        assignments from ARIN (through ordinary allocations or
>>        assignments, or through this Simple Transfer policy) within the
>>        preceding 24 months.
>>      * The transferor may not request any IPv4 allocations or assignments
>>        from ARIN (through ordinary allocations or assignments, or through
>>        this Simple Transfer policy) within the subsequent 24 months.
>>
>> 8.4.2    Conditions on the transferee:
>>
>>      * The transferee resides in the ARIN service area and intends to use
>>        the transferred IPv4 addresses within the ARIN service area.
>>      * The transferee has no outstanding balances with ARIN.
>>      * The transferee?s need is confirmed by ARIN, according to current
>>        ARIN policies, including but not limited to confirmation of
>>        utilization rate of any prior IPv4 allocations, assignments, or
>>        previously transferred IPv4 addresses held by the transferee.
>>      * The transferee signs (or has previously signed) an RSA covering
>>        the IPv4 addresses transferred.
>>      * The transferee has not provided any IPv4 addresses for transfer
>>        through this Simple Transfer process within the preceding 24
>>        months.
>>      * The transferee may not provide any IPv4 addresses for transfer
>>        through this Simple Transfer process within the subsequent 24
>>        months, except in the case of business failure.
>>      * The transferee may only receive one IPv4 address transfer every 6
>>        months.
>>
>>
>>
>> 8.4.3    Conditions on the IPv4 address block to be transferred:
>>
>>      * The IPv4 block must comply with applicable ARIN requirements,
>>        including minimum allocation size (i.e. NRPM 4.2.2., 4.2.4.,
>>        4.3.2., 4.3.6.).  However, an IPv4 allocation or assignment of /24
>>        or larger, but smaller than the current minimum allocation size,
>>        may be transferred as a whole resource, but may not be subdivided.
>>      * The IPv4 block must currently be registered for use within the
>>        ARIN service area, either as part of an address block assigned by
>>        IANA to ARIN, or as part of a legacy address block allocated
>>        within the ARIN service area.
>>      * There must exist no dispute as to the status of the IPv4 block or
>>        regarding the allocation or assignment of such block to the
>>        transferor.
>>      * The transferor may retain one contiguous address range out of
>>        their original allocation or assignment for their own use, and
>>        transfer the other contiguous address range.  If the address range
>>        to be transferred consists of multiple non-aggregatable CIDR
>>        blocks, each may be transferred to a different transferee.  The
>>        retained address range may not be further subdivided or
>>        transferred for a period of 12 months.
>>
>> 8.4.4    Fees
>>
>>      * Completion of a transfer requires payment of a transfer fee
>>        according to ARIN?s schedule of fees.
>>      * The transferee will be subject to all future ARIN membership and
>>        service fees according to the transferee?s total address holdings.
>>
>> 8.4.5    Pre-qualification
>>
>>      * An interested transferee must seek pre-qualification from ARIN to
>>        confirm its eligibility to receive a transfer (including
>>        satisfaction of need according to current ARIN policies) before
>>        making any solicitation for transfer.  Upon pre-qualification,
>>        ARIN will provide the transferee with documentation of the
>>        pre-qualification, including the size (CIDR prefix length) of the
>>        largest IPv4 address block the transferee is eligible to receive,
>>        and the expiration date of the pre-qualification.
>>      * An interested transferor must seek pre-qualification from ARIN to
>>        confirm its eligibility to offer a transfer (including lack of
>>        outstanding balances and having signed an RSA) before offering
>>        IPv4 address resources for transfer.  Upon pre-qualification, ARIN
>>        will provide the transferor with documentation of the
>>        pre-qualification, including the exact network address and size
>>        (CIDR prefix length) the transferor is eligible to provide, and
>>        the expiration date of the pre-qualification.
>>
>> 8.5.      Safe Harbor for IPv4 Transfers through this Simple Transfer
>> Process
>>
>> IPv4 address resources being made available for transfer shall be exempt
>>     
> >from ARIN audit until expiration of the transfer pre-qualification or
>   
>> completion of the transfer.  In the event that a transfer
>> pre-qualification expires, ARIN shall have up to 90 days to initiate an
>> audit prior to this exemption being reinstated through subsequent
>> transfer pre-qualification. This will not extend the end of the exemption.
>>
>> 8.6.      Simple IPv4 Transfers to or from Organizations Under Common
>> Ownership or Control
>>
>> If an IPv4 transferor or transferee is under common ownership or control
>> with any other organization that holds one or more IPv4 blocks, the IPv4
>> transfer request must report all such organizations under common
>> ownership or control.
>>
>> When evaluating compliance with IPv4 Simple Transfer conditions, ARIN
>> may consider a transferor?s transfer request in light of requests from
>> other organizations under common ownership or control with the
>> transferor.  Similarly, ARIN may consider a transferee?s request in
>> light of requests from other organizations under common ownership or
>> control with the transferee.  In evaluating requests from other
>> organizations under common ownership or control, ARIN staff will
>> consider the relationship between the organizations, the degree of
>> coordination between the organizations, and the bona fide use of the
>> addresses at issue to determine whether all appropriate conditions are met.
>>
>> 8.7.      Record-keeping and Publication of Simple Transfers of IPv4
>> Addresses
>>
>> ARIN will develop and operate a listing service to assist interested
>> transferors and transferees by providing them a centralized location to
>> post information about IPv4 blocks available from prequalified
>> transferors and IPv4 blocks needed by prequalified transferees.
>>
>> After completion of the transfer, ARIN will update the registration
>> records pertaining to the IPv4 block at issue.  ARIN will adjust its
>> records as to the holdings of the transferor and transferee.
>>
>> After the transfer, ARIN will publish WHOIS data that reflects the
>> current allocation or assignment of the transferred block.  ARIN will
>> also make available information about any prior recipient(s) of such
>> block.  ARIN will also publish a log of all transfers, including block,
>> transferor, transferee, and date.
>>
>>
>> Rationale:
>>
>> The ARIN Board of Trustees asked the Advisory Council to consider a set
>> of questions around the depletion of the free pool of IPv4 addresses,
>> the transition to IPv6 for Internet address needs in the future, and
>> ARIN's possible role in easing the transition.
>>
>> Over the past few years the AC has spent a great deal of time reflecting
>> on these issues as a group, as individuals, and in consultation with
>> the community. One outcome of this process is this policy proposal,
>> which the AC is submitting for consideration at the next meeting. We are
>> proposing some changes to existing ARIN policy regarding the transfer of
>> IP address block registrations between subscribers, which will allow for
>> the emergence of trade in IPv4 address space, with ARIN to provide a
>> listing service for address blocks available for transfer under the
>> liberalized policy.  We are aware that this proposal, if adopted, will
>> mark a major change in ARIN's role in the community and the Internet.
>>
>> This policy proposal would create a transfer mechanism for IPv4 number
>> resources between those who have excess resources and those who have a
>> need, thereby allowing ARIN to continue to serve its mission after IANA
>> free pool exhaustion.  This proposal would also set conditions on such
>> transfers intended to preserve as much as possible the existing policy
>> related to efficient, needs-based resource issuance, and would leverage
>> ARIN's extensive control systems, audit trails, and recognized position
>> as a trusted agent to avoid speculation and hoarding and diminish the
>> likelihood and extent of an uncontrolled 'black market' where the risk
>> and potential for fraud is immeasurably higher.
>>
>> Many of the transfer conditions are self-explanatory, but some worth
>> highlighting are that:
>>
>>      * To discourage speculation, a waiting period (proposed at 24
>>        months) is required before a transferee (or ordinary resource
>>        recipient) can become a transferor, or vice versa.
>>      * Transferees must qualify for IPv4 space (just as they do today
>>        when getting it from ARIN) before they can receive address space
>>        by transfer, or solicit space on a listing service.
>>      * To discourage unnecessarily rapid growth of routing tables, an
>>        allocation or assignment may not be arbitrarily deaggregated.  To
>>        allow a transferor to downsize within their existing space, they
>>        may split off a contiguous address range, once every 12 months,
>>        and transfer the resulting netblock(s), which are subject to
>>        ARIN?s minimum allocation size, to one or more transferee(s).
>>      * A transferee may receive one transfer every 6 months, so they?ll
>>        be incented to transfer a block appropriately sized for their
>>        needs, which will further discourage deaggregation and keep
>>        smaller blocks available for smaller organizations.
>>
>> The proposal would also have ARIN develop and operate a listing service
>> to facilitate transfers and provide an authoritative central source of
>> information on space available and requested for transfer.  It would not
>> prohibit private party transactions, but would require that potential
>> transferors and transferees be pre-qualified first, so that neither
>> party will encounter any unexpected surprises when they ask ARIN to
>> process the transfer.
>>
>> Timetable for implementation: Immediately, with most aspects of policy
>> taking effect upon IANA exhaustion, per the policy text.
>>
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are 
>> subscribed to the ARIN Public Policy
>> Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml
>> Please contact the ARIN Member Services Help 
>> Desk at info at arin.net if you experience any issues.
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Free Edition.
>> Version: 7.5.516 / Virus Database: 269.20.2/1271 
>> - Release Date: 11/02/2008 08:16 a.m.
>>     
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues.
>   


From gih at apnic.net  Mon Feb 11 16:51:52 2008
From: gih at apnic.net (Geoff Huston)
Date: Tue, 12 Feb 2008 08:51:52 +1100
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <7.0.1.0.1.20080211164859.05618d40@lacnic.net>
References: <47B0794F.40205@arin.net>
	<7.0.1.0.1.20080211164859.05618d40@lacnic.net>
Message-ID: <47B0C378.8090401@apnic.net>

Raul Echeberria wrote:
 > Could the author of the proposal explain what is
 > the justification for requiring that the
 > transferee should also belong to ARIN's region?
 > It is only a question and it doesn't imply any
 > specific opinion about the topic.
 >
 > Ra?l
 >

Raul has not asked this more generally, but as the proposer of a similar 
address transfer policy in APNIC that also has a similar restriction 
(APNIC members only) I should add a note about why this restriction is 
present in the APNIC transfer policy proposal.

In the APNIC case its about the regional address policy group being able 
to define policy for themselves. In this case the policy proposal has 
not been submitted as a coordinated policy across the RIRs nor as a 
proposed global polic. It was submitted to the APNIC policy development 
process as a proposed APNIC policy that would apply to APNIC members.

That said, I now notice that there are similar proposals in both the 
ARIN and RIPE regions, so it may be possible during the course of the 
consideration of these proposals to assess to what extent such transfer 
mechanisms could be extended to encompass transfers across RIRs, as 
Scott Leibrand has already indicated in his response to Raul.

Geoff





From sleibrand at internap.com  Mon Feb 11 16:57:33 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Mon, 11 Feb 2008 15:57:33 -0600
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <47B0C378.8090401@apnic.net>
References: <47B0794F.40205@arin.net>	<7.0.1.0.1.20080211164859.05618d40@lacnic.net>
	<47B0C378.8090401@apnic.net>
Message-ID: <47B0C4CD.1010005@internap.com>

Geoff Huston wrote:
> That said, I now notice that there are similar proposals in both the 
> ARIN and RIPE regions, so it may be possible during the course of the 
> consideration of these proposals to assess to what extent such transfer 
> mechanisms could be extended to encompass transfers across RIRs, as 
> Scott Leibrand has already indicated in his response to Raul.
>   

Do you think that the consideration of transfer mechanisms should occur 
now, during the initial consideration of the separate proposals, or 
after the adoption of two or more transfer policy proposals (but 
hopefully before IANA exhaustion)?  Given how complex the issue is just 
within each RIR, I can definitely see arguments for the latter, but am 
wondering if others see compelling reasons to consider those issues now...

Thanks,
Scott


From raul at lacnic.net  Mon Feb 11 18:31:34 2008
From: raul at lacnic.net (Raul Echeberria)
Date: Mon, 11 Feb 2008 20:31:34 -0300
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <47B0C378.8090401@apnic.net>
References: <47B0794F.40205@arin.net>
	<7.0.1.0.1.20080211164859.05618d40@lacnic.net>
	<47B0C378.8090401@apnic.net>
Message-ID: <7.0.1.0.1.20080211202317.04fe9300@lacnic.net>


Geoff.

One observation.

Accepting transfers only within the region is a 
way to keep the IP addresses within the regions 
in which they were originally allocated.
I don't know if it is good or not, but a fact.

If the transfer of legacy space is also admited, 
it has a great impact in other regions, since 
most of the unused space belonging to the legacy 
blocks, will feed regional markets in the 
developed countries. This is the promotion of 
regional markets instead of global markets.

My opinion is that the regional approach to a 
global poblem that is the IPv4 deployment is not the right approach.


Ra?l



At 06:51 p.m. 11/02/2008, Geoff Huston wrote:
>Raul Echeberria wrote:
> > Could the author of the proposal explain what is
> > the justification for requiring that the
> > transferee should also belong to ARIN's region?
> > It is only a question and it doesn't imply any
> > specific opinion about the topic.
> >
> > Ra?l
> >
>
>Raul has not asked this more generally, but as 
>the proposer of a similar address transfer 
>policy in APNIC that also has a similar 
>restriction (APNIC members only) I should add a 
>note about why this restriction is present in 
>the APNIC transfer policy proposal.
>
>In the APNIC case its about the regional address 
>policy group being able to define policy for 
>themselves. In this case the policy proposal has 
>not been submitted as a coordinated policy 
>across the RIRs nor as a proposed global polic. 
>It was submitted to the APNIC policy development 
>process as a proposed APNIC policy that would apply to APNIC members.
>
>That said, I now notice that there are similar 
>proposals in both the ARIN and RIPE regions, so 
>it may be possible during the course of the 
>consideration of these proposals to assess to 
>what extent such transfer mechanisms could be 
>extended to encompass transfers across RIRs, as 
>Scott Leibrand has already indicated in his response to Raul.
>
>Geoff
>
>
>
>
>--
>No virus found in this incoming message.
>Checked by AVG Free Edition. Version: 7.5.516 / 
>Virus Database: 269.20.2/1271 - Release Date: 11/02/2008 08:16 a.m.




From tedm at ipinc.net  Mon Feb 11 17:39:25 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 11 Feb 2008 14:39:25 -0800
Subject: [ppml] "Who's afraid of IPv4 address depletion?
	Apparentlynoone."
In-Reply-To: <0ECB41A1-17E9-49E7-8011-85925869ABE8@adhost.com>
Message-ID: <NABBJOELMNGNJNGPKDDOKEHBHFAA.tedm@ipinc.net>



>-----Original Message-----
>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>Michael Smith
>Sent: Sunday, February 10, 2008 2:12 PM
>To: Paul Vixie
>Cc: ppml at arin.net
>Subject: Re: [ppml] "Who's afraid of IPv4 address depletion?
>Apparentlynoone."
>

> Since
>most of our sites are SSL-enabled, we really can't use shared-IP
>resources for these hosts, so this is a very real problem.

This isn't true.  You can use a single SSL certificate for multiple
domains on a virtual host using mod_rewrite.  The technique is here:

http://sweon.net/2008/01/hosting-multiple-ssl-vhosts-on-a-single-ipportcerti
ficate-with-apache2

You can simply buy your own SSL cert and charge the customers each a
bit for the use of it.

Of course, if your business model includes you making a profit by
buying SSL certificates in bulk for pennies then selling them to
your customers for tons of money, then I can see how you might be
a little annoyed.  I might also point out that historically, retailers
that merely buy and resell add extremely little value and as a result
customers tend to find ways around them - you might look at a different
business model that has more value add?

Ted



From bicknell at ufp.org  Mon Feb 11 17:42:31 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 11 Feb 2008 17:42:31 -0500
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <7.0.1.0.1.20080211202317.04fe9300@lacnic.net>
References: <47B0794F.40205@arin.net>
	<7.0.1.0.1.20080211164859.05618d40@lacnic.net>
	<47B0C378.8090401@apnic.net>
	<7.0.1.0.1.20080211202317.04fe9300@lacnic.net>
Message-ID: <20080211224231.GA60722@ussenterprise.ufp.org>

In a message written on Mon, Feb 11, 2008 at 08:31:34PM -0300, Raul Echeberria wrote:
> If the transfer of legacy space is also admited, 
> it has a great impact in other regions, since 
> most of the unused space belonging to the legacy 
> blocks, will feed regional markets in the 
> developed countries. This is the promotion of 
> regional markets instead of global markets.

Here are a few of the talking points the AC has considered.

- Since most of the legacy space is inside the ARIN region if
  it is kept inside the ARIN region then the ARIN region will
  have a much longer lifetime for IPv4 than other regions.

- Since legacy space is believed to be one of the larger sources
  of IPv4 resources allowing it to be transferred around the world
  would do the most good.

- If transfers between regions were allowed those in first world
  countries would likely buy all of the space from second and
  third world countries, as they have the money to do so.  This
  would shift the cost of transition to IPv6 onto those least 
  likely to have the money to make the transition.  It also has
  a great potential to get world governments involved in the
  transfer process.

The last point is particularly interesting when you look at the
various RIR's.  Some have a mix of economies in them, others do
not.

Personally I am quite troubled by the results either way.  If someone
in a third world country can't get IP's because we don't allow them
to be transferred out of our region, that's bad.  If some large,
rich US corporation comes along and buys up all the IP's from a
third world country because it can, I think that's bad too.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20080211/af1e28cd/attachment.bin>

From mksmith at adhost.com  Mon Feb 11 17:53:11 2008
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Mon, 11 Feb 2008 14:53:11 -0800
Subject: [ppml] "Who's afraid of IPv4 address depletion?
	Apparentlynoone."
In-Reply-To: <NABBJOELMNGNJNGPKDDOKEHBHFAA.tedm@ipinc.net>
References: <0ECB41A1-17E9-49E7-8011-85925869ABE8@adhost.com>
	<NABBJOELMNGNJNGPKDDOKEHBHFAA.tedm@ipinc.net>
Message-ID: <17838240D9A5544AAA5FF95F8D52031603554FC9@ad-exh01.adhost.lan>

Hello:

> -----Original Message-----
> From: Ted Mittelstaedt [mailto:tedm at ipinc.net]
> Sent: Monday, February 11, 2008 2:39 PM
> To: Michael K. Smith - Adhost; Paul Vixie
> Cc: ppml at arin.net
> Subject: RE: [ppml] "Who's afraid of IPv4 address depletion?
> Apparentlynoone."
> 
> 
> 
> >-----Original Message-----
> >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
> >Michael Smith
> >Sent: Sunday, February 10, 2008 2:12 PM
> >To: Paul Vixie
> >Cc: ppml at arin.net
> >Subject: Re: [ppml] "Who's afraid of IPv4 address depletion?
> >Apparentlynoone."
> >
> 
> > Since
> >most of our sites are SSL-enabled, we really can't use shared-IP
> >resources for these hosts, so this is a very real problem.
> 
> This isn't true.  You can use a single SSL certificate for multiple
> domains on a virtual host using mod_rewrite.  The technique is here:
> 
> http://sweon.net/2008/01/hosting-multiple-ssl-vhosts-on-a-single-
> ipportcerti
> ficate-with-apache2
> 
> You can simply buy your own SSL cert and charge the customers each a
> bit for the use of it.
> 
> Of course, if your business model includes you making a profit by
> buying SSL certificates in bulk for pennies then selling them to
> your customers for tons of money, then I can see how you might be
> a little annoyed.  I might also point out that historically, retailers
> that merely buy and resell add extremely little value and as a result
> customers tend to find ways around them - you might look at a different
> business model that has more value add?
> 
> Ted

I punted to Ted off list about the finer technical points of the above hack.  But, I think it does point out an excellent, urm, point.  We have more IPv6 addresses than we know what to do with and I'm already well down the path of being able to provide them to my customers.  I would gladly do so.  And yet, we have to come up with all of these various ways to hack our way into extending the life of IPv4.  

Why?

Regards,

Mike
Adhost Internet, LLC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 475 bytes
Desc: not available
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20080211/a3db3c7e/attachment.bin>

From gih at apnic.net  Mon Feb 11 18:04:54 2008
From: gih at apnic.net (Geoff Huston)
Date: Tue, 12 Feb 2008 10:04:54 +1100
Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer
	Policy	Proposal
In-Reply-To: <7.0.1.0.1.20080211202317.04fe9300@lacnic.net>
References: <47B0794F.40205@arin.net>	<7.0.1.0.1.20080211164859.05618d40@lacnic.net>	<47B0C378.8090401@apnic.net>
	<7.0.1.0.1.20080211202317.04fe9300@lacnic.net>
Message-ID: <47B0D496.2030800@apnic.net>



Raul Echeberria wrote:
> Geoff.
> 
> One observation.
> 
> Accepting transfers only within the region is a 
> way to keep the IP addresses within the regions 
> in which they were originally allocated.
> I don't know if it is good or not, but a fact.
> 
> If the transfer of legacy space is also admited, 
> it has a great impact in other regions, since 
> most of the unused space belonging to the legacy 
> blocks, will feed regional markets in the 
> developed countries. This is the promotion of 
> regional markets instead of global markets.
> 
> My opinion is that the regional approach to a 
> global poblem that is the IPv4 deployment is not the right approach.
> 

There are two issues that I can readily see here - the first is the 
issue of defining the mechanics of a cross-rir transfer. and the second 
is the assessment of the value of the intended outcomes and the risk of 
other unintended outcomes.

Concerning mechanics, in looking at the APNIC and ARIN proposals they 
both take the approach of "qualification" of the two parties to a 
transfer. One approach would be to 'recognise' the qualification from 
another region - i.e. taking an ARIN perspective a "transferor" (is that 
really an english word? ;-)) meets the criteria listed in section 8.4.1. 
  To extend this to allow cross-RIR transfers it would be a case of 
adding "or meets the criteria as listed (insert reference to the 
transfer policy of another RIR) for members of (RIR). Similarly the 
conditions of the transferee could be augmented by reference to the 
relevant qualifications in the policies of other RIRs. So in terms of 
extending the mechanics of the policy proposals to encompass cross-RIR 
transfers then I'd suggest that there are ways to achieve this though 
the use of mutual recognition of each RIR's qualification processes.

(I should note a slight inaccuracy here from my previous posting - I 
thought that the presentation at the October 2007 RIPE meeting :
http://www.ripe.net/ripe/meetings/ripe-55/presentations/vanmook-v4policy-change.pdf
had been submitted into the RIPE policy process as a proposal, but it 
looks like this has not happened as yet as there is no proposal listed 
at http://www.ripe.net/ripe/policies/proposals/index.html)


The second issue is perhaps the one that deserves further consideration. 
There is a strong argument in favour of looking at this issues of 
transfers from a global rather than regional perspective. The regional 
distribution of IPv4 addresses today, the regional levels of demand for 
IPv4 addresses, and the projections of demand within each region do not 
appear to be well-aligned, and an imposition of a regional 'containment' 
of transfers may well lead to less than desireable outcomes.

One question I have is whether a global transfer model would run the 
risk of unintended outcomes. Would a global transfer domain create 
inequities and imbalances in the residual IPv4 internet that may require 
some other form of intervention or mediation to redress? What are the 
risks of such outcomes, and it is possible to propose some policy 
mechanisms that may mitigate such risks?

regards,

    Geoff



From randy at psg.com  Mon Feb 11 18:51:37 2008
From: randy at psg.com (Randy Bush)
Date: Tue, 12 Feb 2008 08:51:37 +0900
Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer
	Policy	Proposal
In-Reply-To: <7.0.1.0.1.20080211202317.04fe9300@lacnic.net>
References: <47B0794F.40205@arin.net>	<7.0.1.0.1.20080211164859.05618d40@lacnic.net>	<47B0C378.8090401@apnic.net>
	<7.0.1.0.1.20080211202317.04fe9300@lacnic.net>
Message-ID: <47B0DF89.9020506@psg.com>

> My opinion is that the regional approach to a global problem that is
> the IPv4 deployment is not the right approach.

bingo!

as we joked in the verio days of acquiring many small isps, many seemed 
to think locally and act globally.

randy


From stephen at sprunk.org  Mon Feb 11 18:34:12 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Mon, 11 Feb 2008 17:34:12 -0600
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
References: <47B0794F.40205@arin.net>	<7.0.1.0.1.20080211164859.05618d40@lacnic.net><47B0C378.8090401@apnic.net>
	<47B0C4CD.1010005@internap.com>
Message-ID: <01b301c86d0a$7c5f73b0$493816ac@atlanta.polycom.com>

Thus spake "Scott Leibrand" <sleibrand at internap.com>
> Geoff Huston wrote:
>> That said, I now notice that there are similar proposals in both the
>> ARIN and RIPE regions, so it may be possible during the course of the
>> consideration of these proposals to assess to what extent such transfer
>> mechanisms could be extended to encompass transfers across RIRs, as
>> Scott Leibrand has already indicated in his response to Raul.
>
> Do you think that the consideration of transfer mechanisms should occur
> now, during the initial consideration of the separate proposals, or
> after the adoption of two or more transfer policy proposals (but
> hopefully before IANA exhaustion)?  Given how complex the issue is just
> within each RIR, I can definitely see arguments for the latter, but am
> wondering if others see compelling reasons to consider those issues now...

The global policy process is difficult at best when everyone agrees on what 
needs to be done -- and probably with good reason.  IMHO, there is little 
hope of us getting through that by the time IANA exhaustion hits if it were 
to be the primary route because this issue is so contentious.

We don't know if we want to do this.  If we decide to do it, we don't know 
the right method or rules to go about it.  Every region is going to come up 
with different answers to the salient questions, and that's their right. 
Personally, I think we're all going to get it wrong on the first try, but in 
interestingly different ways.  We'll learn from each others' mistakes and 
perhaps, one day, come to some sort of global policy that everyone can live 
with.  Or perhaps we'll decide that even if every region allows internal 
transfers, we don't want to allow them between regions for some reason. 
Trying to answer that question today is premature, as we're all blind men 
groping at different parts of the elephant at this point.  More importantly, 
a global coordination is not a pressing matter; we can solve that after IANA 
exhaustion -- but the regional debate definitely needs to be settled before 
then one way or the other.

At this time I have no comments on this particular proposal other than to 
say I am against it being adopted _at the upcoming meeting_.  I hope that it 
sparks thoughtful debate on the topic and that it spurs alternative 
proposals in the following policy cycle(s).  This is too big an issue to be 
resolved in a couple months with only one option in front of us.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking 



From tedm at ipinc.net  Mon Feb 11 19:20:27 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 11 Feb 2008 16:20:27 -0800
Subject: [ppml] "Who's afraid of IPv4 address depletion?
	Apparentlynoone."
In-Reply-To: <17838240D9A5544AAA5FF95F8D52031603554FC9@ad-exh01.adhost.lan>
Message-ID: <NABBJOELMNGNJNGPKDDOOEHCHFAA.tedm@ipinc.net>



>-----Original Message-----
>From: Michael K. Smith - Adhost [mailto:mksmith at adhost.com]
>Sent: Monday, February 11, 2008 2:53 PM
>To: Ted Mittelstaedt; Paul Vixie
>Cc: ppml at arin.net
>Subject: RE: [ppml] "Who's afraid of IPv4 address depletion?
>Apparentlynoone."
>
>
>I punted to Ted off list about the finer technical points of the 
>above hack.  But, I think it does point out an excellent, urm, 
>point.  We have more IPv6 addresses than we know what to do with 
>and I'm already well down the path of being able to provide them 
>to my customers.  I would gladly do so.  And yet, we have to come 
>up with all of these various ways to hack our way into extending 
>the life of IPv4.  

> Why?

Sigh.

There are still too many "2nd tier" ie: transit AS ISPs/networks out
there who can't route IPv6 yet (you can look at my AS-path list for an
example) although I'm told it's "real soon now"

Maybe in a few years someone could setup an "IPv6 hall O shame"
kind of like the pizza place near here that posts all the bounced
checks they get on a bulletin board, which might spur the last ones
to start routing it?

Ted



From tedm at ipinc.net  Mon Feb 11 19:36:31 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 11 Feb 2008 16:36:31 -0800
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <47B0794F.40205@arin.net>
Message-ID: <NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net>


I have some concerns with this proposal.

This policy seems to undermine the idea that IP addressing is assigned on
the
basis of proving need.  It lends credibility to the idea that IP addressing
is property, and could open the door to any number of lawsuits based
on this.  For example if an organization "purchases" IPv4 they could
then file a lawsuit against a large provider which decided to block
access from that purchased block, claiming discriminatory behavior.

Is there any reason that extending the lifetime of IPv4 will be of any
benefit to the Internet community?  It seems that the projected runout date
is now well after all network operating systems, both router and host-based,
will be IPv6 compliant.

By contrast, it has been said repeatedly that the uptake of new addressing
is so fast that any schemes to "mine" IPv4 from legacy holders who
aren't using it, or any other sources, would be nothing more than a
drop in the bucket, and thus, not worth pursuing.  Furthermore, every
day that passes increases the number of hosts on the Internet, thus
the sooner that IPv4 is abandonded the fewer hosts will need to be
renumbered and the less work will be required to switch to it.

This is also at odds with the ARIN board's statement that organizations
need to switch to IPv6 at http://www.arin.net/v6/v6-resolution.html
rather than try extending IPv4.  Specifically:

"...Board of Trustees hereby requests the ARIN Advisory Council to consider
Internet Numbering Resource Policy changes advisable to encourage migration
to IPv6 numbering resources where possible...."

is in direct contrast to:

"...We (the AC) are proposing some changes to existing ARIN policy regarding
the
transfer of IP address block registrations between subscribers, which will
allow for
the emergence of trade in IPv4 address space, with ARIN to provide a
listing service for address blocks available for transfer under the
liberalized policy...."

I will grant the AC's contention that the emergence of a trade in IPv4 is
inevitable.  I think though that ARIN needs to take the high road and stay
out of the grimy, gross, and messy mechanisms that such a trade may
entail.  If an organization comes to ARIN demanding as a result of a "buy"
that they "deserve" such and such a block of IP numbers is "theirs" then
I see no benefit to the Internet community for deviating from the standard
mechanism of requiring the "buyer" to submit the SAME justification for
new IP addressing that any other submitter would have to provide, and
issuing IPv4 using the same criteria.  If that results in a denial or some
or
all of the IP allocation the "buyer" is requesting, then that is the gamble
that the "buyer" has to take.  As for a mechanism to get the same numbers
as the "buyer" claims they "bought", that sort of thing is what we pay ARIN
to
do for us - there is no reason that the details of any internal resevation
system ARIN might have for this needs to be brought out into policy.  I
would
prefer to give the ARIN staff free-hand as to how to solve these on a
case-by-case
basis - as they have now, as they used when Cable & Wireless abandonded
their
North American IP holdings, etc. etc. etc.


Ted

>-----Original Message-----
>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>Member Services
>Sent: Monday, February 11, 2008 8:35 AM
>To: ppml at arin.net
>Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
>
>
>Resending with a typo that has been corrected in 8.4.2 below. The
>original text is supposed to have "24 months" twice in that section.
>
>Member Services
>American Registry for Internet Numbers (ARIN)
>
>
>
>
>ARIN received the following policy proposal. In accordance with the ARIN
>Internet Resource Policy Evaluation Process, the proposal is being
>posted to the ARIN Public Policy Mailing List (PPML) and being placed on
>ARIN's website.
>
>The ARIN Advisory Council (AC) will review this proposal at their next
>regularly scheduled meeting. The AC may decide to:
>
>   1. Accept the proposal as written. If the AC accepts the proposal, it
>will be posted as a formal policy proposal to PPML and it will be
>presented at a Public Policy Meeting.
>
>   2. Not accept the proposal. If the AC does not accept the proposal,
>the AC will explain their decision via the PPML. If a proposal is not
>accepted, then the author may elect to use the petition process to
>advance their proposal. If the author elects not to petition or the
>petition fails, then the proposal will be closed.
>
>The AC shepherds for this proposal are Scott Leibrand and Stacy Taylor.
>
>The AC invites everyone to comment on this 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.
>
>The ARIN Internet Resource Policy Evaluation Process can be found at:
>http://www.arin.net/policy/irpep.html
>
>Mailing list subscription information can be found at:
>http://www.arin.net/mailing_lists/
>
>Regards,
>
>Member Services
>American Registry for Internet Numbers (ARIN)
>
>
>## * ##
>
>
>Policy Proposal Name: IPv4 Transfer Policy Proposal
>
>Author: ARIN Advisory Council
>
>Proposal Version: 1.0
>
>Submission Date: 02/07/2008
>
>Proposal type: modify
>
>Policy term: permanent
>
>Policy statement:
>
>Replace the current NRPM section 8 with the following --
>
>8.         Transfers
>
>[8.1.     Transfers ? retain as is:
>
>Number resources are non-transferable and are not assignable to any
>other organization unless ARIN has expressly and in writing approved a
>request for transfer.  ARIN is tasked with making prudent decisions on
>whether to approve the transfer of number resources.
>
>It should be understood that number resources are not "sold" under ARIN
>administration. Rather, number resources are assigned to an organization
>for its exclusive use for the purpose stated in the request, provided
>the terms of the Registration Services Agreement continue to be met and
>the stated purpose for the number resources remains the same. Number
>resources are administered and assigned according to ARIN's published
>policies.
>
>Number resources are issued, based on justified need, to organizations,
>not to individuals representing those organizations. Thus, if a company
>goes out of business, regardless of the reason, the point of contact
>(POC) listed for the number resource does not have the authority to
>sell, transfer, assign, or give the number resource to any other person
>or organization. The POC must notify ARIN if a business fails so the
>assigned number resources can be returned to the available pool of
>number resources if a transfer is not requested and justified.]
>
>
>[8.2 ? remove the word ?only?, and retitle to ?M&A Transfer Requirements?:
>
>8.2.      M&A Transfer Requirements
>
>ARIN will consider requests for the transfer of number resources upon
>receipt of evidence that the new entity has acquired the assets which
>had, as of the date of the acquisition or proposed reorganization,
>justified the current entity's use of the number resource. Examples of
>assets that justify use of the number resource include, but are not
>limited to:
>
>     * Existing customer base
>     * Qualified hardware inventory
>     * Specific software requirements.]
>
>
>[8.3 ? retitle to ?M&A Transfer Documentation Requirements?:
>
>8.3.      M&A Transfer Documentation Requirements
>
>In evaluating a request for transfer, ARIN may require the requesting
>organization to provide any of the following documents, as applicable,
>plus any other documents deemed appropriate:
>
>     * An authenticated copy of the instrument(s) effecting the transfer
>       of assets, e.g., bill of sale, certificate of merger, contract,
>       deed, or court decree
>     * A detailed inventory of all assets utilized by the requesting
>       party in maintaining and using the number resource
>     * A list of the requesting party's customers using the number
>resource.
>
>If further justification is required, the requesting party may be asked
>to provide any of the following, or other supporting documentation, as
>applicable:
>
>     * A general listing of the assets or components acquired
>     * A specific description of acquisitions, including:
>           o Type and quantity of equipment
>           o Customer base
>     * A description of how number resources are being utilized
>     * Network engineering plans, including:
>           o Host counts
>           o Subnet masking
>           o Network diagrams
>           o Reassignments to customers]
>
>8.4.      Requirements for Simple Transfer of IPv4 Addresses
>
>After the exhaustion of the IANA IPv4 free pool, ARIN will also process
>IPv4 address transfer requests subject to the following conditions.
>
>8.4.1    Conditions on the transferor:
>
>     * The transferor resides in the ARIN service area.
>     * The transferor has signed an RSA and/or a legacy RSA covering the
>       IPv4 addresses transferred.
>     * The transferor has no outstanding balances with ARIN.
>     * The transferor has not received any IPv4 allocations or
>       assignments from ARIN (through ordinary allocations or
>       assignments, or through this Simple Transfer policy) within the
>       preceding 24 months.
>     * The transferor may not request any IPv4 allocations or assignments
>       from ARIN (through ordinary allocations or assignments, or through
>       this Simple Transfer policy) within the subsequent 24 months.
>
>8.4.2    Conditions on the transferee:
>
>     * The transferee resides in the ARIN service area and intends to use
>       the transferred IPv4 addresses within the ARIN service area.
>     * The transferee has no outstanding balances with ARIN.
>     * The transferee?s need is confirmed by ARIN, according to current
>       ARIN policies, including but not limited to confirmation of
>       utilization rate of any prior IPv4 allocations, assignments, or
>       previously transferred IPv4 addresses held by the transferee.
>     * The transferee signs (or has previously signed) an RSA covering
>       the IPv4 addresses transferred.
>     * The transferee has not provided any IPv4 addresses for transfer
>       through this Simple Transfer process within the preceding 24
>       months.
>     * The transferee may not provide any IPv4 addresses for transfer
>       through this Simple Transfer process within the subsequent 24
>       months, except in the case of business failure.
>     * The transferee may only receive one IPv4 address transfer every 6
>       months.
>
>
>
>8.4.3    Conditions on the IPv4 address block to be transferred:
>
>     * The IPv4 block must comply with applicable ARIN requirements,
>       including minimum allocation size (i.e. NRPM 4.2.2., 4.2.4.,
>       4.3.2., 4.3.6.).  However, an IPv4 allocation or assignment of /24
>       or larger, but smaller than the current minimum allocation size,
>       may be transferred as a whole resource, but may not be subdivided.
>     * The IPv4 block must currently be registered for use within the
>       ARIN service area, either as part of an address block assigned by
>       IANA to ARIN, or as part of a legacy address block allocated
>       within the ARIN service area.
>     * There must exist no dispute as to the status of the IPv4 block or
>       regarding the allocation or assignment of such block to the
>       transferor.
>     * The transferor may retain one contiguous address range out of
>       their original allocation or assignment for their own use, and
>       transfer the other contiguous address range.  If the address range
>       to be transferred consists of multiple non-aggregatable CIDR
>       blocks, each may be transferred to a different transferee.  The
>       retained address range may not be further subdivided or
>       transferred for a period of 12 months.
>
>8.4.4    Fees
>
>     * Completion of a transfer requires payment of a transfer fee
>       according to ARIN?s schedule of fees.
>     * The transferee will be subject to all future ARIN membership and
>       service fees according to the transferee?s total address holdings.
>
>8.4.5    Pre-qualification
>
>     * An interested transferee must seek pre-qualification from ARIN to
>       confirm its eligibility to receive a transfer (including
>       satisfaction of need according to current ARIN policies) before
>       making any solicitation for transfer.  Upon pre-qualification,
>       ARIN will provide the transferee with documentation of the
>       pre-qualification, including the size (CIDR prefix length) of the
>       largest IPv4 address block the transferee is eligible to receive,
>       and the expiration date of the pre-qualification.
>     * An interested transferor must seek pre-qualification from ARIN to
>       confirm its eligibility to offer a transfer (including lack of
>       outstanding balances and having signed an RSA) before offering
>       IPv4 address resources for transfer.  Upon pre-qualification, ARIN
>       will provide the transferor with documentation of the
>       pre-qualification, including the exact network address and size
>       (CIDR prefix length) the transferor is eligible to provide, and
>       the expiration date of the pre-qualification.
>
>8.5.      Safe Harbor for IPv4 Transfers through this Simple Transfer
>Process
>
>IPv4 address resources being made available for transfer shall be exempt
>from ARIN audit until expiration of the transfer pre-qualification or
>completion of the transfer.  In the event that a transfer
>pre-qualification expires, ARIN shall have up to 90 days to initiate an
>audit prior to this exemption being reinstated through subsequent
>transfer pre-qualification. This will not extend the end of the exemption.
>
>8.6.      Simple IPv4 Transfers to or from Organizations Under Common
>Ownership or Control
>
>If an IPv4 transferor or transferee is under common ownership or control
>with any other organization that holds one or more IPv4 blocks, the IPv4
>transfer request must report all such organizations under common
>ownership or control.
>
>When evaluating compliance with IPv4 Simple Transfer conditions, ARIN
>may consider a transferor?s transfer request in light of requests from
>other organizations under common ownership or control with the
>transferor.  Similarly, ARIN may consider a transferee?s request in
>light of requests from other organizations under common ownership or
>control with the transferee.  In evaluating requests from other
>organizations under common ownership or control, ARIN staff will
>consider the relationship between the organizations, the degree of
>coordination between the organizations, and the bona fide use of the
>addresses at issue to determine whether all appropriate conditions are met.
>
>8.7.      Record-keeping and Publication of Simple Transfers of IPv4
>Addresses
>
>ARIN will develop and operate a listing service to assist interested
>transferors and transferees by providing them a centralized location to
>post information about IPv4 blocks available from prequalified
>transferors and IPv4 blocks needed by prequalified transferees.
>
>After completion of the transfer, ARIN will update the registration
>records pertaining to the IPv4 block at issue.  ARIN will adjust its
>records as to the holdings of the transferor and transferee.
>
>After the transfer, ARIN will publish WHOIS data that reflects the
>current allocation or assignment of the transferred block.  ARIN will
>also make available information about any prior recipient(s) of such
>block.  ARIN will also publish a log of all transfers, including block,
>transferor, transferee, and date.
>
>
>Rationale:
>
>The ARIN Board of Trustees asked the Advisory Council to consider a set
>of questions around the depletion of the free pool of IPv4 addresses,
>the transition to IPv6 for Internet address needs in the future, and
>ARIN's possible role in easing the transition.
>
>Over the past few years the AC has spent a great deal of time reflecting
>on these issues as a group, as individuals, and in consultation with
>the community. One outcome of this process is this policy proposal,
>which the AC is submitting for consideration at the next meeting. We are
>proposing some changes to existing ARIN policy regarding the transfer of
>IP address block registrations between subscribers, which will allow for
>the emergence of trade in IPv4 address space, with ARIN to provide a
>listing service for address blocks available for transfer under the
>liberalized policy.  We are aware that this proposal, if adopted, will
>mark a major change in ARIN's role in the community and the Internet.
>
>This policy proposal would create a transfer mechanism for IPv4 number
>resources between those who have excess resources and those who have a
>need, thereby allowing ARIN to continue to serve its mission after IANA
>free pool exhaustion.  This proposal would also set conditions on such
>transfers intended to preserve as much as possible the existing policy
>related to efficient, needs-based resource issuance, and would leverage
>ARIN's extensive control systems, audit trails, and recognized position
>as a trusted agent to avoid speculation and hoarding and diminish the
>likelihood and extent of an uncontrolled 'black market' where the risk
>and potential for fraud is immeasurably higher.
>
>Many of the transfer conditions are self-explanatory, but some worth
>highlighting are that:
>
>     * To discourage speculation, a waiting period (proposed at 24
>       months) is required before a transferee (or ordinary resource
>       recipient) can become a transferor, or vice versa.
>     * Transferees must qualify for IPv4 space (just as they do today
>       when getting it from ARIN) before they can receive address space
>       by transfer, or solicit space on a listing service.
>     * To discourage unnecessarily rapid growth of routing tables, an
>       allocation or assignment may not be arbitrarily deaggregated.  To
>       allow a transferor to downsize within their existing space, they
>       may split off a contiguous address range, once every 12 months,
>       and transfer the resulting netblock(s), which are subject to
>       ARIN?s minimum allocation size, to one or more transferee(s).
>     * A transferee may receive one transfer every 6 months, so they?ll
>       be incented to transfer a block appropriately sized for their
>       needs, which will further discourage deaggregation and keep
>       smaller blocks available for smaller organizations.
>
>The proposal would also have ARIN develop and operate a listing service
>to facilitate transfers and provide an authoritative central source of
>information on space available and requested for transfer.  It would not
>prohibit private party transactions, but would require that potential
>transferors and transferees be pre-qualified first, so that neither
>party will encounter any unexpected surprises when they ask ARIN to
>process the transfer.
>
>Timetable for implementation: Immediately, with most aspects of policy
>taking effect upon IANA exhaustion, per the policy text.
>
>
>
>
>_______________________________________________
>PPML
>You are receiving this message because you are subscribed to the
>ARIN Public Policy
>Mailing List (PPML at arin.net).
>Unsubscribe or manage your mailing list subscription at:
>http://lists.arin.net/mailman/listinfo/ppml
>Please contact the ARIN Member Services Help Desk at info at arin.net
>if you experience any issues.
>
>



From plzak at arin.net  Mon Feb 11 19:57:06 2008
From: plzak at arin.net (Ray Plzak)
Date: Mon, 11 Feb 2008 19:57:06 -0500
Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer Policy
 Proposal
In-Reply-To: <7.0.1.0.1.20080211202317.04fe9300@lacnic.net>
References: <47B0794F.40205@arin.net>
	<7.0.1.0.1.20080211164859.05618d40@lacnic.net>	<47B0C378.8090401@apnic.net>
	<7.0.1.0.1.20080211202317.04fe9300@lacnic.net>
Message-ID: <FEA070315E40A3489D38398C35FE7BB20298B1E4CD@EDAMAME.arin.net>

Any discussion of a globally coordinated policy must include an agreement between the RIRs that all will adhere to the policy as globally coordinated and that regional changes cannot and will not be accepted or this policy will unravel like the globally coordinated IPv6 policy of 2002. The ink was not dry on that policy before the first RIR modified it thus negating the efforts of a great number of individuals over a great many months.

Ray

> -----Original Message-----
> From: sig-policy-bounces at lists.apnic.net [mailto:sig-policy-
> bounces at lists.apnic.net] On Behalf Of Raul Echeberria
> Sent: Monday, February 11, 2008 6:32 PM
> To: ppml at arin.net; sig-policy at apnic.net
> Subject: Re: [sig-policy] [ppml] Policy Proposal: IPv4 Transfer Policy
> Proposal
>
>
> Geoff.
>
> One observation.
>
> Accepting transfers only within the region is a
> way to keep the IP addresses within the regions
> in which they were originally allocated.
> I don't know if it is good or not, but a fact.
>
> If the transfer of legacy space is also admited,
> it has a great impact in other regions, since
> most of the unused space belonging to the legacy
> blocks, will feed regional markets in the
> developed countries. This is the promotion of
> regional markets instead of global markets.
>
> My opinion is that the regional approach to a
> global poblem that is the IPv4 deployment is not the right approach.
>
>
> Ra?l
>
>
>
> At 06:51 p.m. 11/02/2008, Geoff Huston wrote:
> >Raul Echeberria wrote:
> > > Could the author of the proposal explain what is
> > > the justification for requiring that the
> > > transferee should also belong to ARIN's region?
> > > It is only a question and it doesn't imply any
> > > specific opinion about the topic.
> > >
> > > Ra?l
> > >
> >
> >Raul has not asked this more generally, but as
> >the proposer of a similar address transfer
> >policy in APNIC that also has a similar
> >restriction (APNIC members only) I should add a
> >note about why this restriction is present in
> >the APNIC transfer policy proposal.
> >
> >In the APNIC case its about the regional address
> >policy group being able to define policy for
> >themselves. In this case the policy proposal has
> >not been submitted as a coordinated policy
> >across the RIRs nor as a proposed global polic.
> >It was submitted to the APNIC policy development
> >process as a proposed APNIC policy that would apply to APNIC members.
> >
> >That said, I now notice that there are similar
> >proposals in both the ARIN and RIPE regions, so
> >it may be possible during the course of the
> >consideration of these proposals to assess to
> >what extent such transfer mechanisms could be
> >extended to encompass transfers across RIRs, as
> >Scott Leibrand has already indicated in his response to Raul.
> >
> >Geoff
> >
> >
> >
> >
> >--
> >No virus found in this incoming message.
> >Checked by AVG Free Edition. Version: 7.5.516 /
> >Virus Database: 269.20.2/1271 - Release Date: 11/02/2008 08:16 a.m.
>
>
> *              sig-policy:  APNIC SIG on resource management policy
> *
> _______________________________________________
> sig-policy mailing list
> sig-policy at lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/sig-policy



From jcurran at istaff.org  Mon Feb 11 20:02:42 2008
From: jcurran at istaff.org (John Curran)
Date: Mon, 11 Feb 2008 20:02:42 -0500
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net>
References: <NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net>
Message-ID: <p06240802c3d69d28b4f5@[192.168.3.76]>

At 4:36 PM -0800 2/11/08, Ted Mittelstaedt wrote:
>...
>This is also at odds with the ARIN board's statement that organizations
>need to switch to IPv6 at http://www.arin.net/v6/v6-resolution.html
>rather than try extending IPv4.  Specifically:
>
>"...Board of Trustees hereby requests the ARIN Advisory Council to consider
>Internet Numbering Resource Policy changes advisable to encourage migration
>to IPv6 numbering resources where possible...."

"Changes to encourage migration to IPv6 *where possible*" does
not preclude changes that make IPv4 available for those for whom
it may not be possible to migrate in a timely manner.  The resolution
states that availability IPv4 space "cannot be assured indefinitely",
which is not the same as saying "shall not be efficiently managed
now that IPv6 is here"...

Each entity using address space faces its own set of business and
technical issues with migration, and to not consider the possibility
of transfer policies which would improve the overall utilization of
IPv4 address space would presume we know what's best on behalf
of every ISP, hosting company, content provider, enterprise, etc.

/John


From tedm at ipinc.net  Mon Feb 11 20:34:29 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 11 Feb 2008 17:34:29 -0800
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <p06240802c3d69d28b4f5@[192.168.3.76]>
Message-ID: <NABBJOELMNGNJNGPKDDOGEHEHFAA.tedm@ipinc.net>



>-----Original Message-----
>From: John Curran [mailto:jcurran at istaff.org]
>Sent: Monday, February 11, 2008 5:03 PM
>To: Ted Mittelstaedt
>Cc: ppml at arin.net
>Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
>
>
>At 4:36 PM -0800 2/11/08, Ted Mittelstaedt wrote:
>>...
>>This is also at odds with the ARIN board's statement that organizations
>>need to switch to IPv6 at http://www.arin.net/v6/v6-resolution.html
>>rather than try extending IPv4.  Specifically:
>>
>>"...Board of Trustees hereby requests the ARIN Advisory Council 
>to consider
>>Internet Numbering Resource Policy changes advisable to encourage 
>migration
>>to IPv6 numbering resources where possible...."
>
>"Changes to encourage migration to IPv6 *where possible*" does
>not preclude changes that make IPv4 available for those for whom
>it may not be possible to migrate in a timely manner.
>The resolution
>states that availability IPv4 space "cannot be assured indefinitely",
>which is not the same as saying "shall not be efficiently managed
>now that IPv6 is here"...
>

Your relying on semantic games.  The intent and thrust of the
Board statement is pretty clear.  The intent and thrust of this policy
change is also pretty clear.  The two are at odds.

>Each entity using address space faces its own set of business and
>technical issues with migration, and to not consider the possibility
>of transfer policies which would improve the overall utilization of
>IPv4 address space

Nothing in the CURRENT method of return-issue blocks improvements
of the overall utilization of IPv4.

Transfers can also make it easier for problems with badly-utilized
space to be perpetuated, rather than addressed.

>would presume we know what's best on behalf
>of every ISP, hosting company, content provider, enterprise, etc.
>

That is irrelevant.

The highest incidents of color blindness in the general
population is red-green color blindness.  However, traffic control devices
use the colors red and green.  This makes your ordinary stop light
definitely not "the best" color choice for these individuals.  However,
red and green have the highest recognition among the general population
as "danger" and "safe" and as a result, we have "presumed that we
know the best" traffic control device color for every ISP, hosting
company, content provider, enterprise, etc.

It is unavoidable that any rule will affect some groups negatively.
That is not a reason for either implementing, or not implementing it.
We need to be looking at what is best for the Internet, not for
a subgroup of ISPs.

Your welcome to argue that migrating to IPv6 is not in the best interest
of the Internet.  Maybe it isn't, and we should forget it and be
concentrating on schemes to extend IPv4 indefinitely.

Ted


From bicknell at ufp.org  Mon Feb 11 20:41:20 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 11 Feb 2008 20:41:20 -0500
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net>
References: <47B0794F.40205@arin.net>
	<NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net>
Message-ID: <20080212014120.GB70018@ussenterprise.ufp.org>

In a message written on Mon, Feb 11, 2008 at 04:36:31PM -0800, Ted Mittelstaedt wrote:
> This policy seems to undermine the idea that IP addressing is assigned on
> the
> basis of proving need.  It lends credibility to the idea that IP addressing
> is property, and could open the door to any number of lawsuits based
> on this.  For example if an organization "purchases" IPv4 they could
> then file a lawsuit against a large provider which decided to block
> access from that purchased block, claiming discriminatory behavior.

Two things to consider:

- The AC felt that need should still be a factor, hence the desire to
  pre-qualify based on existing policies.  I believe in general we wanted
  to retain as much need based addressing as seemed practical to do.

- The AC worked closely with legal council to try and find the right
  words and phrasing.  The transfer is not on IPv4 numbers; it is on a
  bundle of services that ARIN provides.  I don't want to dismiss your
  worry completely, as even with input from council many AC members
  still have a concern in this area.

> "...We (the AC) are proposing some changes to existing ARIN policy regarding
> the
> transfer of IP address block registrations between subscribers, which will
> allow for
> the emergence of trade in IPv4 address space, with ARIN to provide a
> listing service for address blocks available for transfer under the
> liberalized policy...."

In the same statement you will also find...

]                                                      "While the
] AC as a whole believes the policy proposal to be well written and
] carefully considered, we are not unanimous in all aspects of the
] policy proposal, nor even are we united in the view that the proposed
] policy should be adopted."

The AC has not endorsed this policy as something that should be
done.  Indeed, there are members of the AC who share your concern
and that no transfer policy should pass.

Our primary goal was to spark discussion on that very point.  Until
now it's been "there's a proposal in APNIC" or "transfers may work
like this..."  We wanted to put forth a straw man of what we
considered to be a well thought out transfer policy to spark real
community discussion, and we very much welcome your comments.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20080211/d4bbcd9f/attachment.bin>

From jcurran at istaff.org  Mon Feb 11 20:57:13 2008
From: jcurran at istaff.org (John Curran)
Date: Mon, 11 Feb 2008 20:57:13 -0500
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <NABBJOELMNGNJNGPKDDOGEHEHFAA.tedm@ipinc.net>
References: <NABBJOELMNGNJNGPKDDOGEHEHFAA.tedm@ipinc.net>
Message-ID: <p06240804c3d6a89261f2@[192.168.3.76]>

At 5:34 PM -0800 2/11/08, Ted Mittelstaedt wrote:
> >The resolution
> >states that availability IPv4 space "cannot be assured indefinitely",
>>which is not the same as saying "shall not be efficiently managed
> >now that IPv6 is here"...
>
>Your relying on semantic games.  The intent and thrust of the
>Board statement is pretty clear.

No games - The intent of the Board statement is exactly what
it states: IPv4 space "cannot be assured indefinitely".

>The intent and thrust of this policy change is also pretty clear. 
>The two are at odds.

Interesting...  It didn't appear that way to the ARIN Board,
which specifically asked the ARIN AC to look into the IPv4
IPv6 transition issues and whether any changes to policy
needed to be considered.

In that spirit, it would be good to get your feedback on whether
the proposal is in the best interest of the Internet or not.

>It is unavoidable that any rule will affect some groups negatively.
>That is not a reason for either implementing, or not implementing it.
>We need to be looking at what is best for the Internet, not for
>a subgroup of ISPs.

100% agreement.  The policy proposal is exactly that, a proposal.
It's possible that there is no safe transfer policy that doesn't have
side effects worse than any benefit...   The point is that now there
is a cohesive proposal on the table, and the community can discuss
the benefits and risks in concrete terms rather than the abstract.

>Your welcome to argue that migrating to IPv6 is not in the best interest
>of the Internet.  Maybe it isn't, and we should forget it and be
>concentrating on schemes to extend IPv4 indefinitely.

I'm here to help make sure that open discussion occurs, and
not much else.  My particular opinion on this proposal is moot
(unless it reaches the ARIN Board and needs to be considered
at that time based on the community's support, openness of
discussion, and ARIN's overall mission).

/John


From drc at virtualized.org  Mon Feb 11 21:33:27 2008
From: drc at virtualized.org (David Conrad)
Date: Mon, 11 Feb 2008 18:33:27 -0800
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <NABBJOELMNGNJNGPKDDOGEHEHFAA.tedm@ipinc.net>
References: <NABBJOELMNGNJNGPKDDOGEHEHFAA.tedm@ipinc.net>
Message-ID: <E1792E04-25DD-4CAD-AF83-E86253A661E4@virtualized.org>

> Nothing in the CURRENT method of return-issue blocks improvements
> of the overall utilization of IPv4.

Except there is currently no incentive to return blocks and there will  
be less over time.

> Transfers can also make it easier for problems with badly-utilized
> space to be perpetuated, rather than addressed.

How is that worse than the situation as it exists now?

Regards,
-drc



From sleibrand at internap.com  Mon Feb 11 23:33:49 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Mon, 11 Feb 2008 22:33:49 -0600
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <20080211170626.GN8368@shell01.cell.sv2.tellme.com>
References: <47B0794F.40205@arin.net>	<369EB04A0951824ABE7D8BAC67AF9BB408841E6E@CL-S-EX-1.stanleyassociates.com>
	<20080211170626.GN8368@shell01.cell.sv2.tellme.com>
Message-ID: <47B121AD.9040807@internap.com>

David Williamson wrote:
> On Mon, Feb 11, 2008 at 11:56:29AM -0500, Howard, W. Lee wrote:
>   
>>> 8.4.3    Conditions on the IPv4 address block to be transferred:
>>>
>>>      * The IPv4 block must comply with applicable ARIN requirements,
>>>        including minimum allocation size (i.e. NRPM 4.2.2., 4.2.4.,
>>>        4.3.2., 4.3.6.).  However, an IPv4 allocation or 
>>> assignment of /24
>>>        or larger, but smaller than the current minimum 
>>> allocation size,
>>>        may be transferred as a whole resource, but may not be 
>>> subdivided.
>>>       
>> Is this intended to mean swamp space can remain swampy, but other
>> space can't be subdivided in /24?  It looks like it says the block
>> must meet minimum transfer size, unless it's a /24 or larger.
>>     
>
> I'm also a bit confused by this.  It does seem to imply that I cannot
> get a PI /24 from ARIN directly, but I could get one transferred to
> me.  That seems unexpected.  If the intent is to permit resources
> already allocated at some size that is presently below the minimum
> requirements (i.e., the swamp), this should get some different
> verbiage.  If the intent is really to permit transfers down to the /24
> limit, we should go ahead and change the minimum allocation and
> assignment sizes to match.
>   

Yes, that is the intent: to encourage efficient use of unused swamp 
space by allowing it to be transferred after IANA exhaustion.  This 
policy does not do anything to change the minimum allocation size: that 
may be a good idea, but should be a separate policy proposal IMO.

-Scott



From sleibrand at internap.com  Mon Feb 11 23:53:36 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Mon, 11 Feb 2008 22:53:36 -0600
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net>
References: <NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net>
Message-ID: <47B12650.2060107@internap.com>

Ted Mittelstaedt wrote:
> I have some concerns with this proposal.
>
> This policy seems to undermine the idea that IP addressing is assigned on the
> basis of proving need.

As Leo mentioned, the intent here is to continue requiring applicants to 
prove they need IPv4 addresses, and simply provide them with another way 
to get those addresses they've qualified for once ARIN runs out.

>   It lends credibility to the idea that IP addressing
> is property, and could open the door to any number of lawsuits based
> on this.  For example if an organization "purchases" IPv4 they could
> then file a lawsuit against a large provider which decided to block
> access from that purchased block, claiming discriminatory behavior.
>   

That is a valid concern.  ARIN counsel has been consulting with the AC 
on this policy proposal.  In addition to the legal risks to ARIN itself 
that he's been considering thus far, it may be a good idea to ask 
whether he feels this policy proposal would create any substantial legal 
risk for ARIN members individually.

> Is there any reason that extending the lifetime of IPv4 will be of any
> benefit to the Internet community?

Yes.  There is a large installed base for whom migrating to IPv6 may be 
painful (expensive).  Reducing the community's total expense for 
operating their IP networks is a benefit to the Internet community.

>   It seems that the projected runout date
> is now well after all network operating systems, both router and host-based,
> will be IPv6 compliant.
>
> By contrast, it has been said repeatedly that the uptake of new addressing
> is so fast that any schemes to "mine" IPv4 from legacy holders who
> aren't using it, or any other sources, would be nothing more than a
> drop in the bucket, and thus, not worth pursuing.

That assumes that we are only trying to reclaim existing unused IPv4 
space, without providing any incentive for people to renumber out of 
IPv4 space that, while not strictly unused, is easy to move out of.  For 
example, if I run a consumer ISP, I might decide that I could migrate my 
DHCP customers to IPv6 + NAT'd IPv4, thereby freeing up IPv4 addresses 
that I can then transfer to a slower adopter, and use the proceeds to 
fund my entire IPv6 migration.

> Furthermore, every
> day that passes increases the number of hosts on the Internet, thus
> the sooner that IPv4 is abandonded the fewer hosts will need to be
> renumbered and the less work will be required to switch to it.
>   

Money is a powerful motivator.  If an organization can choose to save 
money by putting new hosts on IPv6 with NAT'd IPv4 or a proxy for 
reaching the remaining IPv4 Internet, they'll likely do so.  If a 
different organization with different issues can save more money by 
paying someone else to migrate and use their space to delay migrating 
until all their systems are ready, they'll likely do that.  This policy 
proposal allows organizations to choose what's best for them, rather 
than forcing a one-size-fits-all solution.

> I will grant the AC's contention that the emergence of a trade in IPv4 is
> inevitable.  I think though that ARIN needs to take the high road and stay
> out of the grimy, gross, and messy mechanisms that such a trade may
> entail.

ARIN is in the stewardship business, no matter how grimy, gross, or 
messy that business becomes.  I believe it is our responsibility to the 
community to minimize the grime and messiness, and I believe that a 
transfer policy along the lines proposed is one of the best ways 
available to do so.

> If an organization comes to ARIN demanding as a result of a "buy"
> that they "deserve" such and such a block of IP numbers is "theirs" then
> I see no benefit to the Internet community for deviating from the standard
> mechanism of requiring the "buyer" to submit the SAME justification for
> new IP addressing that any other submitter would have to provide, and
> issuing IPv4 using the same criteria.  If that results in a denial or some or
> all of the IP allocation the "buyer" is requesting, then that is the gamble
> that the "buyer" has to take.

That is exactly what this policy proposal attempts to accomplish: it 
requires that any potential transferee justify their need for IP space, 
exactly as they have to do today.  They can then get IPv4 space from 
ARIN, if ARIN has any to give, or they can go out and find a transferor 
willing to part with some space.

> As for a mechanism to get the same numbers
> as the "buyer" claims they "bought", that sort of thing is what we pay ARIN
> to do for us - there is no reason that the details of any internal resevation
> system ARIN might have for this needs to be brought out into policy.  I
> would prefer to give the ARIN staff free-hand as to how to solve these on a
> case-by-case basis - as they have now, as they used when Cable & Wireless abandonded
> their North American IP holdings, etc. etc. etc.
>   

One important point I'll reiterate: we're not talking about just 
"abandoned" or "unused" IP space here.  We're talking about providing 
organizations a financial incentive to reduce their usage of IPv4 space 
(such as by adopting IPv6), thereby freeing up space for other 
organizations who still need it.  To enable that, we need a new policy, 
such as the one we've proposed.

-Scott


>   
>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>> Member Services
>> Sent: Monday, February 11, 2008 8:35 AM
>> To: ppml at arin.net
>> Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
>>
>>
>> Resending with a typo that has been corrected in 8.4.2 below. The
>> original text is supposed to have "24 months" twice in that section.
>>
>> Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>>
>>
>> ARIN received the following policy proposal. In accordance with the ARIN
>> Internet Resource Policy Evaluation Process, the proposal is being
>> posted to the ARIN Public Policy Mailing List (PPML) and being placed on
>> ARIN's website.
>>
>> The ARIN Advisory Council (AC) will review this proposal at their next
>> regularly scheduled meeting. The AC may decide to:
>>
>>   1. Accept the proposal as written. If the AC accepts the proposal, it
>> will be posted as a formal policy proposal to PPML and it will be
>> presented at a Public Policy Meeting.
>>
>>   2. Not accept the proposal. If the AC does not accept the proposal,
>> the AC will explain their decision via the PPML. If a proposal is not
>> accepted, then the author may elect to use the petition process to
>> advance their proposal. If the author elects not to petition or the
>> petition fails, then the proposal will be closed.
>>
>> The AC shepherds for this proposal are Scott Leibrand and Stacy Taylor.
>>
>> The AC invites everyone to comment on this 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.
>>
>> The ARIN Internet Resource Policy Evaluation Process can be found at:
>> http://www.arin.net/policy/irpep.html
>>
>> Mailing list subscription information can be found at:
>> http://www.arin.net/mailing_lists/
>>
>> Regards,
>>
>> Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> ## * ##
>>
>>
>> Policy Proposal Name: IPv4 Transfer Policy Proposal
>>
>> Author: ARIN Advisory Council
>>
>> Proposal Version: 1.0
>>
>> Submission Date: 02/07/2008
>>
>> Proposal type: modify
>>
>> Policy term: permanent
>>
>> Policy statement:
>>
>> Replace the current NRPM section 8 with the following --
>>
>> 8.         Transfers
>>
>> [8.1.     Transfers ? retain as is:
>>
>> Number resources are non-transferable and are not assignable to any
>> other organization unless ARIN has expressly and in writing approved a
>> request for transfer.  ARIN is tasked with making prudent decisions on
>> whether to approve the transfer of number resources.
>>
>> It should be understood that number resources are not "sold" under ARIN
>> administration. Rather, number resources are assigned to an organization
>> for its exclusive use for the purpose stated in the request, provided
>> the terms of the Registration Services Agreement continue to be met and
>> the stated purpose for the number resources remains the same. Number
>> resources are administered and assigned according to ARIN's published
>> policies.
>>
>> Number resources are issued, based on justified need, to organizations,
>> not to individuals representing those organizations. Thus, if a company
>> goes out of business, regardless of the reason, the point of contact
>> (POC) listed for the number resource does not have the authority to
>> sell, transfer, assign, or give the number resource to any other person
>> or organization. The POC must notify ARIN if a business fails so the
>> assigned number resources can be returned to the available pool of
>> number resources if a transfer is not requested and justified.]
>>
>>
>> [8.2 ? remove the word ?only?, and retitle to ?M&A Transfer Requirements?:
>>
>> 8.2.      M&A Transfer Requirements
>>
>> ARIN will consider requests for the transfer of number resources upon
>> receipt of evidence that the new entity has acquired the assets which
>> had, as of the date of the acquisition or proposed reorganization,
>> justified the current entity's use of the number resource. Examples of
>> assets that justify use of the number resource include, but are not
>> limited to:
>>
>>     * Existing customer base
>>     * Qualified hardware inventory
>>     * Specific software requirements.]
>>
>>
>> [8.3 ? retitle to ?M&A Transfer Documentation Requirements?:
>>
>> 8.3.      M&A Transfer Documentation Requirements
>>
>> In evaluating a request for transfer, ARIN may require the requesting
>> organization to provide any of the following documents, as applicable,
>> plus any other documents deemed appropriate:
>>
>>     * An authenticated copy of the instrument(s) effecting the transfer
>>       of assets, e.g., bill of sale, certificate of merger, contract,
>>       deed, or court decree
>>     * A detailed inventory of all assets utilized by the requesting
>>       party in maintaining and using the number resource
>>     * A list of the requesting party's customers using the number
>> resource.
>>
>> If further justification is required, the requesting party may be asked
>> to provide any of the following, or other supporting documentation, as
>> applicable:
>>
>>     * A general listing of the assets or components acquired
>>     * A specific description of acquisitions, including:
>>           o Type and quantity of equipment
>>           o Customer base
>>     * A description of how number resources are being utilized
>>     * Network engineering plans, including:
>>           o Host counts
>>           o Subnet masking
>>           o Network diagrams
>>           o Reassignments to customers]
>>
>> 8.4.      Requirements for Simple Transfer of IPv4 Addresses
>>
>> After the exhaustion of the IANA IPv4 free pool, ARIN will also process
>> IPv4 address transfer requests subject to the following conditions.
>>
>> 8.4.1    Conditions on the transferor:
>>
>>     * The transferor resides in the ARIN service area.
>>     * The transferor has signed an RSA and/or a legacy RSA covering the
>>       IPv4 addresses transferred.
>>     * The transferor has no outstanding balances with ARIN.
>>     * The transferor has not received any IPv4 allocations or
>>       assignments from ARIN (through ordinary allocations or
>>       assignments, or through this Simple Transfer policy) within the
>>       preceding 24 months.
>>     * The transferor may not request any IPv4 allocations or assignments
>>       from ARIN (through ordinary allocations or assignments, or through
>>       this Simple Transfer policy) within the subsequent 24 months.
>>
>> 8.4.2    Conditions on the transferee:
>>
>>     * The transferee resides in the ARIN service area and intends to use
>>       the transferred IPv4 addresses within the ARIN service area.
>>     * The transferee has no outstanding balances with ARIN.
>>     * The transferee?s need is confirmed by ARIN, according to current
>>       ARIN policies, including but not limited to confirmation of
>>       utilization rate of any prior IPv4 allocations, assignments, or
>>       previously transferred IPv4 addresses held by the transferee.
>>     * The transferee signs (or has previously signed) an RSA covering
>>       the IPv4 addresses transferred.
>>     * The transferee has not provided any IPv4 addresses for transfer
>>       through this Simple Transfer process within the preceding 24
>>       months.
>>     * The transferee may not provide any IPv4 addresses for transfer
>>       through this Simple Transfer process within the subsequent 24
>>       months, except in the case of business failure.
>>     * The transferee may only receive one IPv4 address transfer every 6
>>       months.
>>
>>
>>
>> 8.4.3    Conditions on the IPv4 address block to be transferred:
>>
>>     * The IPv4 block must comply with applicable ARIN requirements,
>>       including minimum allocation size (i.e. NRPM 4.2.2., 4.2.4.,
>>       4.3.2., 4.3.6.).  However, an IPv4 allocation or assignment of /24
>>       or larger, but smaller than the current minimum allocation size,
>>       may be transferred as a whole resource, but may not be subdivided.
>>     * The IPv4 block must currently be registered for use within the
>>       ARIN service area, either as part of an address block assigned by
>>       IANA to ARIN, or as part of a legacy address block allocated
>>       within the ARIN service area.
>>     * There must exist no dispute as to the status of the IPv4 block or
>>       regarding the allocation or assignment of such block to the
>>       transferor.
>>     * The transferor may retain one contiguous address range out of
>>       their original allocation or assignment for their own use, and
>>       transfer the other contiguous address range.  If the address range
>>       to be transferred consists of multiple non-aggregatable CIDR
>>       blocks, each may be transferred to a different transferee.  The
>>       retained address range may not be further subdivided or
>>       transferred for a period of 12 months.
>>
>> 8.4.4    Fees
>>
>>     * Completion of a transfer requires payment of a transfer fee
>>       according to ARIN?s schedule of fees.
>>     * The transferee will be subject to all future ARIN membership and
>>       service fees according to the transferee?s total address holdings.
>>
>> 8.4.5    Pre-qualification
>>
>>     * An interested transferee must seek pre-qualification from ARIN to
>>       confirm its eligibility to receive a transfer (including
>>       satisfaction of need according to current ARIN policies) before
>>       making any solicitation for transfer.  Upon pre-qualification,
>>       ARIN will provide the transferee with documentation of the
>>       pre-qualification, including the size (CIDR prefix length) of the
>>       largest IPv4 address block the transferee is eligible to receive,
>>       and the expiration date of the pre-qualification.
>>     * An interested transferor must seek pre-qualification from ARIN to
>>       confirm its eligibility to offer a transfer (including lack of
>>       outstanding balances and having signed an RSA) before offering
>>       IPv4 address resources for transfer.  Upon pre-qualification, ARIN
>>       will provide the transferor with documentation of the
>>       pre-qualification, including the exact network address and size
>>       (CIDR prefix length) the transferor is eligible to provide, and
>>       the expiration date of the pre-qualification.
>>
>> 8.5.      Safe Harbor for IPv4 Transfers through this Simple Transfer
>> Process
>>
>> IPv4 address resources being made available for transfer shall be exempt
>>     
> >from ARIN audit until expiration of the transfer pre-qualification or
>   
>> completion of the transfer.  In the event that a transfer
>> pre-qualification expires, ARIN shall have up to 90 days to initiate an
>> audit prior to this exemption being reinstated through subsequent
>> transfer pre-qualification. This will not extend the end of the exemption.
>>
>> 8.6.      Simple IPv4 Transfers to or from Organizations Under Common
>> Ownership or Control
>>
>> If an IPv4 transferor or transferee is under common ownership or control
>> with any other organization that holds one or more IPv4 blocks, the IPv4
>> transfer request must report all such organizations under common
>> ownership or control.
>>
>> When evaluating compliance with IPv4 Simple Transfer conditions, ARIN
>> may consider a transferor?s transfer request in light of requests from
>> other organizations under common ownership or control with the
>> transferor.  Similarly, ARIN may consider a transferee?s request in
>> light of requests from other organizations under common ownership or
>> control with the transferee.  In evaluating requests from other
>> organizations under common ownership or control, ARIN staff will
>> consider the relationship between the organizations, the degree of
>> coordination between the organizations, and the bona fide use of the
>> addresses at issue to determine whether all appropriate conditions are met.
>>
>> 8.7.      Record-keeping and Publication of Simple Transfers of IPv4
>> Addresses
>>
>> ARIN will develop and operate a listing service to assist interested
>> transferors and transferees by providing them a centralized location to
>> post information about IPv4 blocks available from prequalified
>> transferors and IPv4 blocks needed by prequalified transferees.
>>
>> After completion of the transfer, ARIN will update the registration
>> records pertaining to the IPv4 block at issue.  ARIN will adjust its
>> records as to the holdings of the transferor and transferee.
>>
>> After the transfer, ARIN will publish WHOIS data that reflects the
>> current allocation or assignment of the transferred block.  ARIN will
>> also make available information about any prior recipient(s) of such
>> block.  ARIN will also publish a log of all transfers, including block,
>> transferor, transferee, and date.
>>
>>
>> Rationale:
>>
>> The ARIN Board of Trustees asked the Advisory Council to consider a set
>> of questions around the depletion of the free pool of IPv4 addresses,
>> the transition to IPv6 for Internet address needs in the future, and
>> ARIN's possible role in easing the transition.
>>
>> Over the past few years the AC has spent a great deal of time reflecting
>> on these issues as a group, as individuals, and in consultation with
>> the community. One outcome of this process is this policy proposal,
>> which the AC is submitting for consideration at the next meeting. We are
>> proposing some changes to existing ARIN policy regarding the transfer of
>> IP address block registrations between subscribers, which will allow for
>> the emergence of trade in IPv4 address space, with ARIN to provide a
>> listing service for address blocks available for transfer under the
>> liberalized policy.  We are aware that this proposal, if adopted, will
>> mark a major change in ARIN's role in the community and the Internet.
>>
>> This policy proposal would create a transfer mechanism for IPv4 number
>> resources between those who have excess resources and those who have a
>> need, thereby allowing ARIN to continue to serve its mission after IANA
>> free pool exhaustion.  This proposal would also set conditions on such
>> transfers intended to preserve as much as possible the existing policy
>> related to efficient, needs-based resource issuance, and would leverage
>> ARIN's extensive control systems, audit trails, and recognized position
>> as a trusted agent to avoid speculation and hoarding and diminish the
>> likelihood and extent of an uncontrolled 'black market' where the risk
>> and potential for fraud is immeasurably higher.
>>
>> Many of the transfer conditions are self-explanatory, but some worth
>> highlighting are that:
>>
>>     * To discourage speculation, a waiting period (proposed at 24
>>       months) is required before a transferee (or ordinary resource
>>       recipient) can become a transferor, or vice versa.
>>     * Transferees must qualify for IPv4 space (just as they do today
>>       when getting it from ARIN) before they can receive address space
>>       by transfer, or solicit space on a listing service.
>>     * To discourage unnecessarily rapid growth of routing tables, an
>>       allocation or assignment may not be arbitrarily deaggregated.  To
>>       allow a transferor to downsize within their existing space, they
>>       may split off a contiguous address range, once every 12 months,
>>       and transfer the resulting netblock(s), which are subject to
>>       ARIN?s minimum allocation size, to one or more transferee(s).
>>     * A transferee may receive one transfer every 6 months, so they?ll
>>       be incented to transfer a block appropriately sized for their
>>       needs, which will further discourage deaggregation and keep
>>       smaller blocks available for smaller organizations.
>>
>> The proposal would also have ARIN develop and operate a listing service
>> to facilitate transfers and provide an authoritative central source of
>> information on space available and requested for transfer.  It would not
>> prohibit private party transactions, but would require that potential
>> transferors and transferees be pre-qualified first, so that neither
>> party will encounter any unexpected surprises when they ask ARIN to
>> process the transfer.
>>
>> Timetable for implementation: Immediately, with most aspects of policy
>> taking effect upon IANA exhaustion, per the policy text.
>>
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the
>> ARIN Public Policy
>> Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml
>> Please contact the ARIN Member Services Help Desk at 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 (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues.
>   


From heldal at eml.cc  Tue Feb 12 04:04:18 2008
From: heldal at eml.cc (Per Heldal)
Date: Tue, 12 Feb 2008 10:04:18 +0100
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net>
References: <NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net>
Message-ID: <1202807058.11775.13.camel@obelix.sandbu>


On Mon, 2008-02-11 at 16:36 -0800, Ted Mittelstaedt wrote:
> I have some concerns with this proposal.
> 
> This policy seems to undermine the idea that IP addressing is assigned on
> the
> basis of proving need.  It lends credibility to the idea that IP addressing
> is property, and could open the door to any number of lawsuits based
> on this.  For example if an organization "purchases" IPv4 they could
> then file a lawsuit against a large provider which decided to block
> access from that purchased block, claiming discriminatory behavior.

The suggested policy also seems to be in conflict with the RIR principle
of not being involved in routing. Wherever there's money to be made
there's greed and that can't be contained by simply telling people to
"be nice". The value of this kind of policy is questionable if it cannot
be enforced. To regulate other people's use of resources is
fundamentally different from the task of coordinating handouts from a
resource-pool.

//per





From michael.dillon at bt.com  Tue Feb 12 05:02:59 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 12 Feb 2008 10:02:59 -0000
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <20080211224231.GA60722@ussenterprise.ufp.org>
References: <47B0794F.40205@arin.net><7.0.1.0.1.20080211164859.05618d40@lacnic.net><47B0C378.8090401@apnic.net><7.0.1.0.1.20080211202317.04fe9300@lacnic.net>
	<20080211224231.GA60722@ussenterprise.ufp.org>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B001F2B4C2@E03MVC4-UKBR.domain1.systemhost.net>

> Personally I am quite troubled by the results either way.  If 
> someone in a third world country can't get IP's because we 
> don't allow them to be transferred out of our region, that's 
> bad.  If some large, rich US corporation comes along and buys 
> up all the IP's from a third world country because it can, I 
> think that's bad too.

Please get your head out of the clouds. IPv6 addresses are available
from all RIRs. The need for Transparent Internet Acess
<http://www.getipv6.info/index.php/Transparent_Internet_Access>
will mean that once the IPv6 transition has begun in some countries,
there will no longer be any value in maintaining growth of IPv4
networks because whether you use IPv4 or IPV6, you will still have
to operate transition mechanisms.

Considering that you can't escape spending money to live with IPv6,
it is smarter to begin your IPv6 transition earlier, rather than
hanging on to IPv4 until the bitter end. If you hang on until the
end, then you will have to spend money again, at a time when your
comptetitors have already broken free of IPv4.

There will never be a time when 3rd world countries can't get IPs.
And no rich companies will ever corner the market on IPs because
there are simply too many addresses in the IPv6 address space.

--Michael Dillon


From michael.dillon at bt.com  Tue Feb 12 05:22:23 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 12 Feb 2008 10:22:23 -0000
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <47B12650.2060107@internap.com>
References: <NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net>
	<47B12650.2060107@internap.com>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B001F2B4F7@E03MVC4-UKBR.domain1.systemhost.net>

> Yes.  There is a large installed base for whom migrating to 
> IPv6 may be painful (expensive).  Reducing the community's 
> total expense for operating their IP networks is a benefit to 
> the Internet community.

RED HERRING!

Given the fact that ISPs who implement IPv6 transit service
will also have to implement transition mechanisms such as
Teredo, 6to4, etc., there is no imperative for any part of
the installed base to migrate to IPv6 before they are ready.

The imperative today is for those organizations with steadily
growing networks at the heart of their business model (ISPs) 
to begin transitioning. Whether it is painful or not, they must
do it or die because network growth is fundamental to their
being.

If an ISP decided to try and avoid implementing IPv6 by getting
IPv4 addresses from other sources, they are simply backing
themselves into a corner and relying on their competitors to
operate transition mechanisms for them. This is a risky strategy
since the market segment who are willing to buy IPv4 network
access will be steadily shrinking. In addition, their existing
customers will begin to move away because the ISP is perceived
as being incompetent and at risk of hitting a brick wall.

>  This policy 
> proposal allows organizations to choose what's best for them, 
> rather than forcing a one-size-fits-all solution.

I disagree that this policy does what you say. In fact this policy
is trying to set up a market for buying and selling IP addresses.

Under current policy, an ISP who migrates infrastructure to IPv6
can return their IPv4 addresses to ARIN. And an ISP who is not
migrating can continue to apply to ARIN for more IPv4 addresses 
and receive the returned ones.

This is clear and simple and easy to understand. It is the way
that IPv4 allocation has always been done and is fully understood
by everybody who deals with IP networking. Any new policy like
the one proposed, simply muddies the waters and creates confusion.

--Michael Dillon


From raul at lacnic.net  Tue Feb 12 08:37:47 2008
From: raul at lacnic.net (Raul Echeberria)
Date: Tue, 12 Feb 2008 10:37:47 -0300
Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer Policy
 Proposal
In-Reply-To: <FEA070315E40A3489D38398C35FE7BB20298B1E4CD@EDAMAME.arin.ne
 t>
References: <47B0794F.40205@arin.net>
	<7.0.1.0.1.20080211164859.05618d40@lacnic.net>
	<47B0C378.8090401@apnic.net>
	<7.0.1.0.1.20080211202317.04fe9300@lacnic.net>
	<FEA070315E40A3489D38398C35FE7BB20298B1E4CD@EDAMAME.arin.net>
Message-ID: <7.0.1.0.1.20080212102939.04fec760@lacnic.net>


Ray:

Certainly it is a good point, but I am not 
necessarily claiming for a global or a 
coordinated policy (maybe yes), but for a global 
"and" coordinated strategy for dealing with a global problem.


Ra?l


At 09:57 p.m. 11/02/2008, Ray Plzak wrote:
>Any discussion of a globally coordinated policy 
>must include an agreement between the RIRs that 
>all will adhere to the policy as globally 
>coordinated and that regional changes cannot and 
>will not be accepted or this policy will unravel 
>like the globally coordinated IPv6 policy of 
>2002. The ink was not dry on that policy before 
>the first RIR modified it thus negating the 
>efforts of a great number of individuals over a great many months.
>
>Ray
>
> > -----Original Message-----
> > From: sig-policy-bounces at lists.apnic.net [mailto:sig-policy-
> > bounces at lists.apnic.net] On Behalf Of Raul Echeberria
> > Sent: Monday, February 11, 2008 6:32 PM
> > To: ppml at arin.net; sig-policy at apnic.net
> > Subject: Re: [sig-policy] [ppml] Policy Proposal: IPv4 Transfer Policy
> > Proposal
> >
> >
> > Geoff.
> >
> > One observation.
> >
> > Accepting transfers only within the region is a
> > way to keep the IP addresses within the regions
> > in which they were originally allocated.
> > I don't know if it is good or not, but a fact.
> >
> > If the transfer of legacy space is also admited,
> > it has a great impact in other regions, since
> > most of the unused space belonging to the legacy
> > blocks, will feed regional markets in the
> > developed countries. This is the promotion of
> > regional markets instead of global markets.
> >
> > My opinion is that the regional approach to a
> > global poblem that is the IPv4 deployment is not the right approach.
> >
> >
> > Ra?l
> >
> >
> >
> > At 06:51 p.m. 11/02/2008, Geoff Huston wrote:
> > >Raul Echeberria wrote:
> > > > Could the author of the proposal explain what is
> > > > the justification for requiring that the
> > > > transferee should also belong to ARIN's region?
> > > > It is only a question and it doesn't imply any
> > > > specific opinion about the topic.
> > > >
> > > > Ra?l
> > > >
> > >
> > >Raul has not asked this more generally, but as
> > >the proposer of a similar address transfer
> > >policy in APNIC that also has a similar
> > >restriction (APNIC members only) I should add a
> > >note about why this restriction is present in
> > >the APNIC transfer policy proposal.
> > >
> > >In the APNIC case its about the regional address
> > >policy group being able to define policy for
> > >themselves. In this case the policy proposal has
> > >not been submitted as a coordinated policy
> > >across the RIRs nor as a proposed global polic.
> > >It was submitted to the APNIC policy development
> > >process as a proposed APNIC policy that would apply to APNIC members.
> > >
> > >That said, I now notice that there are similar
> > >proposals in both the ARIN and RIPE regions, so
> > >it may be possible during the course of the
> > >consideration of these proposals to assess to
> > >what extent such transfer mechanisms could be
> > >extended to encompass transfers across RIRs, as
> > >Scott Leibrand has already indicated in his response to Raul.
> > >
> > >Geoff
> > >
> > >
> > >
> > >
> > >--
> > >No virus found in this incoming message.
> > >Checked by AVG Free Edition. Version: 7.5.516 /
> > >Virus Database: 269.20.2/1271 - Release Date: 11/02/2008 08:16 a.m.
> >
> >
> > *              sig-policy:  APNIC SIG on resource management policy
> > *
> > _______________________________________________
> > sig-policy mailing list
> > sig-policy at lists.apnic.net
> > http://mailman.apnic.net/mailman/listinfo/sig-policy
>
>*              sig-policy:  APNIC SIG on 
>resource management policy           *
>_______________________________________________
>sig-policy mailing list
>sig-policy at lists.apnic.net
>http://mailman.apnic.net/mailman/listinfo/sig-policy
>
>
>--
>No virus found in this incoming message.
>Checked by AVG Free Edition.
>Version: 7.5.516 / Virus Database: 269.20.2/1273 
>- Release Date: 12/02/2008 09:31 a.m.




From randy at psg.com  Tue Feb 12 07:38:28 2008
From: randy at psg.com (Randy Bush)
Date: Tue, 12 Feb 2008 21:38:28 +0900
Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer Policy
	Proposal
In-Reply-To: <7.0.1.0.1.20080212102939.04fec760@lacnic.net>
References: <47B0794F.40205@arin.net>	<7.0.1.0.1.20080211164859.05618d40@lacnic.net>	<47B0C378.8090401@apnic.net>	<7.0.1.0.1.20080211202317.04fe9300@lacnic.net>	<FEA070315E40A3489D38398C35FE7BB20298B1E4CD@EDAMAME.arin.net>
	<7.0.1.0.1.20080212102939.04fec760@lacnic.net>
Message-ID: <47B19344.7040707@psg.com>

> I am not necessarily claiming for a global or a coordinated policy
> (maybe yes), but for a global "and" coordinated strategy for dealing
> with a global problem.

too radical.  it is our right to think locally while acting globally. 
that's why there are five rirs, right?

randy


From randy at psg.com  Tue Feb 12 07:40:53 2008
From: randy at psg.com (Randy Bush)
Date: Tue, 12 Feb 2008 21:40:53 +0900
Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer
	Policy	Proposal
In-Reply-To: <47B19344.7040707@psg.com>
References: <47B0794F.40205@arin.net>	<7.0.1.0.1.20080211164859.05618d40@lacnic.net>	<47B0C378.8090401@apnic.net>	<7.0.1.0.1.20080211202317.04fe9300@lacnic.net>	<FEA070315E40A3489D38398C35FE7BB20298B1E4CD@EDAMAME.arin.net>	<7.0.1.0.1.20080212102939.04fec760@lacnic.net>
	<47B19344.7040707@psg.com>
Message-ID: <47B193D5.2060708@psg.com>

>> I am not necessarily claiming for a global or a coordinated policy
>> (maybe yes), but for a global "and" coordinated strategy for dealing
>> with a global problem.
> too radical.  it is our right to think locally while acting globally. 
> that's why there are five rirs, right?

apologies.  sarcasm does not translate well.  i am in strong agreement 
with raul.

randy


From plzak at arin.net  Tue Feb 12 07:45:43 2008
From: plzak at arin.net (Ray Plzak)
Date: Tue, 12 Feb 2008 07:45:43 -0500
Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer Policy
 Proposal
In-Reply-To: <47B19344.7040707@psg.com>
References: <47B0794F.40205@arin.net>
	<7.0.1.0.1.20080211164859.05618d40@lacnic.net>	<47B0C378.8090401@apnic.net>
	<7.0.1.0.1.20080211202317.04fe9300@lacnic.net>
	<FEA070315E40A3489D38398C35FE7BB20298B1E4CD@EDAMAME.arin.net>
	<7.0.1.0.1.20080212102939.04fec760@lacnic.net>
	<47B19344.7040707@psg.com>
Message-ID: <FEA070315E40A3489D38398C35FE7BB20298B1E506@EDAMAME.arin.net>

Merely pointing out that there are implications to the use of the term globally coordinated policy, a term that has been used many times over the past several months, perhaps a little to glibly.

Even a global and coordinated strategy will require commitments, once made, must not be subject to disassembly by the subsequent actions of a single RIR. Once that happens the global and coordinated strategy is neither global or coordinated. Think locally while acting globally is more than just a catchy phrase.

Ray

> -----Original Message-----
> From: Randy Bush [mailto:randy at psg.com]
> Sent: Tuesday, February 12, 2008 7:38 AM
> To: Raul Echeberria
> Cc: Ray Plzak; ppml at arin.net; sig-policy at apnic.net
> Subject: Re: [sig-policy] [ppml] Policy Proposal: IPv4 Transfer Policy
> Proposal
>
> > I am not necessarily claiming for a global or a coordinated policy
> > (maybe yes), but for a global "and" coordinated strategy for dealing
> > with a global problem.
>
> too radical.  it is our right to think locally while acting globally.
> that's why there are five rirs, right?
>
> randy



From raul at lacnic.net  Tue Feb 12 09:10:41 2008
From: raul at lacnic.net (Raul Echeberria)
Date: Tue, 12 Feb 2008 11:10:41 -0300
Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer Policy
 Proposal
In-Reply-To: <FEA070315E40A3489D38398C35FE7BB20298B1E506@EDAMAME.arin.ne
 t>
References: <47B0794F.40205@arin.net>
	<7.0.1.0.1.20080211164859.05618d40@lacnic.net>
	<47B0C378.8090401@apnic.net>
	<7.0.1.0.1.20080211202317.04fe9300@lacnic.net>
	<FEA070315E40A3489D38398C35FE7BB20298B1E4CD@EDAMAME.arin.net>
	<7.0.1.0.1.20080212102939.04fec760@lacnic.net>
	<47B19344.7040707@psg.com>
	<FEA070315E40A3489D38398C35FE7BB20298B1E506@EDAMAME.arin.net>
Message-ID: <7.0.1.0.1.20080212110845.05a8bb50@lacnic.net>


Ray

My point is that we first need a global strategy and later probably 
global and/or coordinated policies for implementing that strategy.
And of course, I agree with you regarding commitments, and rest that you said.

Raul


At 09:45 a.m. 12/02/2008, Ray Plzak wrote:
>Merely pointing out that there are implications to the use of the 
>term globally coordinated policy, a term that has been used many 
>times over the past several months, perhaps a little to glibly.
>
>Even a global and coordinated strategy will require commitments, 
>once made, must not be subject to disassembly by the subsequent 
>actions of a single RIR. Once that happens the global and 
>coordinated strategy is neither global or coordinated. Think locally 
>while acting globally is more than just a catchy phrase.
>
>Ray
>
> > -----Original Message-----
> > From: Randy Bush [mailto:randy at psg.com]
> > Sent: Tuesday, February 12, 2008 7:38 AM
> > To: Raul Echeberria
> > Cc: Ray Plzak; ppml at arin.net; sig-policy at apnic.net
> > Subject: Re: [sig-policy] [ppml] Policy Proposal: IPv4 Transfer Policy
> > Proposal
> >
> > > I am not necessarily claiming for a global or a coordinated policy
> > > (maybe yes), but for a global "and" coordinated strategy for dealing
> > > with a global problem.
> >
> > too radical.  it is our right to think locally while acting globally.
> > that's why there are five rirs, right?
> >
> > randy
>
>*              sig-policy:  APNIC SIG on resource management 
>policy           *
>_______________________________________________
>sig-policy mailing list
>sig-policy at lists.apnic.net
>http://mailman.apnic.net/mailman/listinfo/sig-policy
>
>
>--
>No virus found in this incoming message.
>Checked by AVG Free Edition.
>Version: 7.5.516 / Virus Database: 269.20.2/1273 - Release Date: 
>12/02/2008 09:31 a.m.




From BillD at cait.wustl.edu  Tue Feb 12 08:23:35 2008
From: BillD at cait.wustl.edu (Bill Darte)
Date: Tue, 12 Feb 2008 07:23:35 -0600
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net>
References: <47B0794F.40205@arin.net>
	<NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D0308754B41D@ex1.cait.wustl.edu>



The intent of the modified transfer policy is to provide order in the
interim between now, through IPv4 exhaustion and toward a pervasive IPv6
adoption.

As has been stated before, the AC was not in favor of this policy as a
singular effort.  It was in context of a number of suggestions that
would provide stability and promote migration and the acceptance that
transfers will take place in the future to meet needs.  The AC chose to
make this proposal to begin a concrete dialog about this issue in the
ARIN region and to prescribe a means to mitigate an uncoordinated and
unjustified transfer system...one that is likely to exhibit most of the
bad characteristics of unregulated exchanges of limited resources.

It is easy to misuse the term 'buying' of resources when discussing this
policy.  It is not a policy that accepts that IP addresses will become
property, nor that acquisition of number resources will take place
outside of justification by whichever source (free pool or transfer).

Bill Darte
ARIN AC
 

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Ted Mittelstaedt
> Sent: Monday, February 11, 2008 6:37 PM
> To: Member Services; ppml at arin.net
> Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
> 
> 
> I have some concerns with this proposal.
> 
> This policy seems to undermine the idea that IP addressing is 
> assigned on the basis of proving need.  It lends credibility 
> to the idea that IP addressing is property, and could open 
> the door to any number of lawsuits based on this.  For 
> example if an organization "purchases" IPv4 they could then 
> file a lawsuit against a large provider which decided to 
> block access from that purchased block, claiming 
> discriminatory behavior.
> 
> Is there any reason that extending the lifetime of IPv4 will 
> be of any benefit to the Internet community?  It seems that 
> the projected runout date is now well after all network 
> operating systems, both router and host-based, will be IPv6 compliant.
> 
> By contrast, it has been said repeatedly that the uptake of 
> new addressing is so fast that any schemes to "mine" IPv4 
> from legacy holders who aren't using it, or any other 
> sources, would be nothing more than a drop in the bucket, and 
> thus, not worth pursuing.  Furthermore, every day that passes 
> increases the number of hosts on the Internet, thus the 
> sooner that IPv4 is abandonded the fewer hosts will need to 
> be renumbered and the less work will be required to switch to it.
> 
> This is also at odds with the ARIN board's statement that 
> organizations need to switch to IPv6 at 
> http://www.arin.net/v6/v6-resolution.html
> rather than try extending IPv4.  Specifically:
> 
> "...Board of Trustees hereby requests the ARIN Advisory 
> Council to consider Internet Numbering Resource Policy 
> changes advisable to encourage migration to IPv6 numbering 
> resources where possible...."
> 
> is in direct contrast to:
> 
> "...We (the AC) are proposing some changes to existing ARIN 
> policy regarding the transfer of IP address block 
> registrations between subscribers, which will allow for the 
> emergence of trade in IPv4 address space, with ARIN to 
> provide a listing service for address blocks available for 
> transfer under the liberalized policy...."
> 
> I will grant the AC's contention that the emergence of a 
> trade in IPv4 is inevitable.  I think though that ARIN needs 
> to take the high road and stay out of the grimy, gross, and 
> messy mechanisms that such a trade may entail.  If an 
> organization comes to ARIN demanding as a result of a "buy"
> that they "deserve" such and such a block of IP numbers is 
> "theirs" then I see no benefit to the Internet community for 
> deviating from the standard mechanism of requiring the 
> "buyer" to submit the SAME justification for new IP 
> addressing that any other submitter would have to provide, 
> and issuing IPv4 using the same criteria.  If that results in 
> a denial or some or all of the IP allocation the "buyer" is 
> requesting, then that is the gamble that the "buyer" has to 
> take.  As for a mechanism to get the same numbers as the 
> "buyer" claims they "bought", that sort of thing is what we 
> pay ARIN to do for us - there is no reason that the details 
> of any internal resevation system ARIN might have for this 
> needs to be brought out into policy.  I would prefer to give 
> the ARIN staff free-hand as to how to solve these on a 
> case-by-case basis - as they have now, as they used when 
> Cable & Wireless abandonded their North American IP holdings, 
> etc. etc. etc.
> 
> 
> Ted
> 
> >-----Original Message-----
> >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On 
> Behalf Of 
> >Member Services
> >Sent: Monday, February 11, 2008 8:35 AM
> >To: ppml at arin.net
> >Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
> >
> >
> >Resending with a typo that has been corrected in 8.4.2 below. The 
> >original text is supposed to have "24 months" twice in that section.
> >
> >Member Services
> >American Registry for Internet Numbers (ARIN)
> >
> >
> >
> >
> >ARIN received the following policy proposal. In accordance with the 
> >ARIN Internet Resource Policy Evaluation Process, the 
> proposal is being 
> >posted to the ARIN Public Policy Mailing List (PPML) and 
> being placed 
> >on ARIN's website.
> >
> >The ARIN Advisory Council (AC) will review this proposal at 
> their next 
> >regularly scheduled meeting. The AC may decide to:
> >
> >   1. Accept the proposal as written. If the AC accepts the 
> proposal, 
> >it will be posted as a formal policy proposal to PPML and it will be 
> >presented at a Public Policy Meeting.
> >
> >   2. Not accept the proposal. If the AC does not accept the 
> proposal, 
> >the AC will explain their decision via the PPML. If a 
> proposal is not 
> >accepted, then the author may elect to use the petition process to 
> >advance their proposal. If the author elects not to petition or the 
> >petition fails, then the proposal will be closed.
> >
> >The AC shepherds for this proposal are Scott Leibrand and 
> Stacy Taylor.
> >
> >The AC invites everyone to comment on this 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.
> >
> >The ARIN Internet Resource Policy Evaluation Process can be found at:
> >http://www.arin.net/policy/irpep.html
> >
> >Mailing list subscription information can be found at:
> >http://www.arin.net/mailing_lists/
> >
> >Regards,
> >
> >Member Services
> >American Registry for Internet Numbers (ARIN)
> >
> >
> >## * ##
> >
> >
> >Policy Proposal Name: IPv4 Transfer Policy Proposal
> >
> >Author: ARIN Advisory Council
> >
> >Proposal Version: 1.0
> >
> >Submission Date: 02/07/2008
> >
> >Proposal type: modify
> >
> >Policy term: permanent
> >
> >Policy statement:
> >
> >Replace the current NRPM section 8 with the following --
> >
> >8.         Transfers
> >
> >[8.1.     Transfers - retain as is:
> >
> >Number resources are non-transferable and are not assignable to any 
> >other organization unless ARIN has expressly and in writing 
> approved a 
> >request for transfer.  ARIN is tasked with making prudent 
> decisions on 
> >whether to approve the transfer of number resources.
> >
> >It should be understood that number resources are not "sold" 
> under ARIN 
> >administration. Rather, number resources are assigned to an 
> >organization for its exclusive use for the purpose stated in the 
> >request, provided the terms of the Registration Services Agreement 
> >continue to be met and the stated purpose for the number resources 
> >remains the same. Number resources are administered and assigned 
> >according to ARIN's published policies.
> >
> >Number resources are issued, based on justified need, to 
> organizations, 
> >not to individuals representing those organizations. Thus, 
> if a company 
> >goes out of business, regardless of the reason, the point of contact
> >(POC) listed for the number resource does not have the authority to 
> >sell, transfer, assign, or give the number resource to any 
> other person 
> >or organization. The POC must notify ARIN if a business fails so the 
> >assigned number resources can be returned to the available pool of 
> >number resources if a transfer is not requested and justified.]
> >
> >
> >[8.2 - remove the word "only", and retitle to "M&A Transfer 
> Requirements":
> >
> >8.2.      M&A Transfer Requirements
> >
> >ARIN will consider requests for the transfer of number 
> resources upon 
> >receipt of evidence that the new entity has acquired the 
> assets which 
> >had, as of the date of the acquisition or proposed reorganization, 
> >justified the current entity's use of the number resource. 
> Examples of 
> >assets that justify use of the number resource include, but are not 
> >limited to:
> >
> >     * Existing customer base
> >     * Qualified hardware inventory
> >     * Specific software requirements.]
> >
> >
> >[8.3 - retitle to "M&A Transfer Documentation Requirements":
> >
> >8.3.      M&A Transfer Documentation Requirements
> >
> >In evaluating a request for transfer, ARIN may require the 
> requesting 
> >organization to provide any of the following documents, as 
> applicable, 
> >plus any other documents deemed appropriate:
> >
> >     * An authenticated copy of the instrument(s) effecting 
> the transfer
> >       of assets, e.g., bill of sale, certificate of merger, 
> contract,
> >       deed, or court decree
> >     * A detailed inventory of all assets utilized by the requesting
> >       party in maintaining and using the number resource
> >     * A list of the requesting party's customers using the number 
> >resource.
> >
> >If further justification is required, the requesting party 
> may be asked 
> >to provide any of the following, or other supporting 
> documentation, as
> >applicable:
> >
> >     * A general listing of the assets or components acquired
> >     * A specific description of acquisitions, including:
> >           o Type and quantity of equipment
> >           o Customer base
> >     * A description of how number resources are being utilized
> >     * Network engineering plans, including:
> >           o Host counts
> >           o Subnet masking
> >           o Network diagrams
> >           o Reassignments to customers]
> >
> >8.4.      Requirements for Simple Transfer of IPv4 Addresses
> >
> >After the exhaustion of the IANA IPv4 free pool, ARIN will 
> also process
> >IPv4 address transfer requests subject to the following conditions.
> >
> >8.4.1    Conditions on the transferor:
> >
> >     * The transferor resides in the ARIN service area.
> >     * The transferor has signed an RSA and/or a legacy RSA 
> covering the
> >       IPv4 addresses transferred.
> >     * The transferor has no outstanding balances with ARIN.
> >     * The transferor has not received any IPv4 allocations or
> >       assignments from ARIN (through ordinary allocations or
> >       assignments, or through this Simple Transfer policy) 
> within the
> >       preceding 24 months.
> >     * The transferor may not request any IPv4 allocations 
> or assignments
> >       from ARIN (through ordinary allocations or 
> assignments, or through
> >       this Simple Transfer policy) within the subsequent 24 months.
> >
> >8.4.2    Conditions on the transferee:
> >
> >     * The transferee resides in the ARIN service area and 
> intends to use
> >       the transferred IPv4 addresses within the ARIN service area.
> >     * The transferee has no outstanding balances with ARIN.
> >     * The transferee's need is confirmed by ARIN, according 
> to current
> >       ARIN policies, including but not limited to confirmation of
> >       utilization rate of any prior IPv4 allocations, 
> assignments, or
> >       previously transferred IPv4 addresses held by the transferee.
> >     * The transferee signs (or has previously signed) an 
> RSA covering
> >       the IPv4 addresses transferred.
> >     * The transferee has not provided any IPv4 addresses 
> for transfer
> >       through this Simple Transfer process within the preceding 24
> >       months.
> >     * The transferee may not provide any IPv4 addresses for transfer
> >       through this Simple Transfer process within the subsequent 24
> >       months, except in the case of business failure.
> >     * The transferee may only receive one IPv4 address 
> transfer every 6
> >       months.
> >
> >
> >
> >8.4.3    Conditions on the IPv4 address block to be transferred:
> >
> >     * The IPv4 block must comply with applicable ARIN requirements,
> >       including minimum allocation size (i.e. NRPM 4.2.2., 4.2.4.,
> >       4.3.2., 4.3.6.).  However, an IPv4 allocation or 
> assignment of /24
> >       or larger, but smaller than the current minimum 
> allocation size,
> >       may be transferred as a whole resource, but may not 
> be subdivided.
> >     * The IPv4 block must currently be registered for use within the
> >       ARIN service area, either as part of an address block 
> assigned by
> >       IANA to ARIN, or as part of a legacy address block allocated
> >       within the ARIN service area.
> >     * There must exist no dispute as to the status of the 
> IPv4 block or
> >       regarding the allocation or assignment of such block to the
> >       transferor.
> >     * The transferor may retain one contiguous address range out of
> >       their original allocation or assignment for their own use, and
> >       transfer the other contiguous address range.  If the 
> address range
> >       to be transferred consists of multiple non-aggregatable CIDR
> >       blocks, each may be transferred to a different 
> transferee.  The
> >       retained address range may not be further subdivided or
> >       transferred for a period of 12 months.
> >
> >8.4.4    Fees
> >
> >     * Completion of a transfer requires payment of a transfer fee
> >       according to ARIN's schedule of fees.
> >     * The transferee will be subject to all future ARIN 
> membership and
> >       service fees according to the transferee's total 
> address holdings.
> >
> >8.4.5    Pre-qualification
> >
> >     * An interested transferee must seek pre-qualification 
> from ARIN to
> >       confirm its eligibility to receive a transfer (including
> >       satisfaction of need according to current ARIN 
> policies) before
> >       making any solicitation for transfer.  Upon pre-qualification,
> >       ARIN will provide the transferee with documentation of the
> >       pre-qualification, including the size (CIDR prefix 
> length) of the
> >       largest IPv4 address block the transferee is eligible 
> to receive,
> >       and the expiration date of the pre-qualification.
> >     * An interested transferor must seek pre-qualification 
> from ARIN to
> >       confirm its eligibility to offer a transfer (including lack of
> >       outstanding balances and having signed an RSA) before offering
> >       IPv4 address resources for transfer.  Upon 
> pre-qualification, ARIN
> >       will provide the transferor with documentation of the
> >       pre-qualification, including the exact network 
> address and size
> >       (CIDR prefix length) the transferor is eligible to 
> provide, and
> >       the expiration date of the pre-qualification.
> >
> >8.5.      Safe Harbor for IPv4 Transfers through this Simple Transfer
> >Process
> >
> >IPv4 address resources being made available for transfer shall be 
> >exempt from ARIN audit until expiration of the transfer 
> >pre-qualification or completion of the transfer.  In the 
> event that a 
> >transfer pre-qualification expires, ARIN shall have up to 90 days to 
> >initiate an audit prior to this exemption being reinstated through 
> >subsequent transfer pre-qualification. This will not extend 
> the end of the exemption.
> >
> >8.6.      Simple IPv4 Transfers to or from Organizations Under Common
> >Ownership or Control
> >
> >If an IPv4 transferor or transferee is under common ownership or 
> >control with any other organization that holds one or more 
> IPv4 blocks, 
> >the IPv4 transfer request must report all such organizations under 
> >common ownership or control.
> >
> >When evaluating compliance with IPv4 Simple Transfer 
> conditions, ARIN 
> >may consider a transferor's transfer request in light of 
> requests from 
> >other organizations under common ownership or control with the 
> >transferor.  Similarly, ARIN may consider a transferee's request in 
> >light of requests from other organizations under common ownership or 
> >control with the transferee.  In evaluating requests from other 
> >organizations under common ownership or control, ARIN staff will 
> >consider the relationship between the organizations, the degree of 
> >coordination between the organizations, and the bona fide use of the 
> >addresses at issue to determine whether all appropriate 
> conditions are met.
> >
> >8.7.      Record-keeping and Publication of Simple Transfers of IPv4
> >Addresses
> >
> >ARIN will develop and operate a listing service to assist interested 
> >transferors and transferees by providing them a centralized 
> location to 
> >post information about IPv4 blocks available from prequalified 
> >transferors and IPv4 blocks needed by prequalified transferees.
> >
> >After completion of the transfer, ARIN will update the registration 
> >records pertaining to the IPv4 block at issue.  ARIN will adjust its 
> >records as to the holdings of the transferor and transferee.
> >
> >After the transfer, ARIN will publish WHOIS data that reflects the 
> >current allocation or assignment of the transferred block.  
> ARIN will 
> >also make available information about any prior recipient(s) of such 
> >block.  ARIN will also publish a log of all transfers, 
> including block, 
> >transferor, transferee, and date.
> >
> >
> >Rationale:
> >
> >The ARIN Board of Trustees asked the Advisory Council to 
> consider a set 
> >of questions around the depletion of the free pool of IPv4 
> addresses, 
> >the transition to IPv6 for Internet address needs in the future, and 
> >ARIN's possible role in easing the transition.
> >
> >Over the past few years the AC has spent a great deal of time 
> >reflecting on these issues as a group, as individuals, and in 
> >consultation with the community. One outcome of this process is this 
> >policy proposal, which the AC is submitting for consideration at the 
> >next meeting. We are proposing some changes to existing ARIN policy 
> >regarding the transfer of IP address block registrations between 
> >subscribers, which will allow for the emergence of trade in IPv4 
> >address space, with ARIN to provide a listing service for address 
> >blocks available for transfer under the liberalized policy.  We are 
> >aware that this proposal, if adopted, will mark a major 
> change in ARIN's role in the community and the Internet.
> >
> >This policy proposal would create a transfer mechanism for 
> IPv4 number 
> >resources between those who have excess resources and those 
> who have a 
> >need, thereby allowing ARIN to continue to serve its mission 
> after IANA 
> >free pool exhaustion.  This proposal would also set 
> conditions on such 
> >transfers intended to preserve as much as possible the 
> existing policy 
> >related to efficient, needs-based resource issuance, and 
> would leverage 
> >ARIN's extensive control systems, audit trails, and 
> recognized position 
> >as a trusted agent to avoid speculation and hoarding and 
> diminish the 
> >likelihood and extent of an uncontrolled 'black market' 
> where the risk 
> >and potential for fraud is immeasurably higher.
> >
> >Many of the transfer conditions are self-explanatory, but some worth 
> >highlighting are that:
> >
> >     * To discourage speculation, a waiting period (proposed at 24
> >       months) is required before a transferee (or ordinary resource
> >       recipient) can become a transferor, or vice versa.
> >     * Transferees must qualify for IPv4 space (just as they do today
> >       when getting it from ARIN) before they can receive 
> address space
> >       by transfer, or solicit space on a listing service.
> >     * To discourage unnecessarily rapid growth of routing tables, an
> >       allocation or assignment may not be arbitrarily 
> deaggregated.  To
> >       allow a transferor to downsize within their existing 
> space, they
> >       may split off a contiguous address range, once every 
> 12 months,
> >       and transfer the resulting netblock(s), which are subject to
> >       ARIN's minimum allocation size, to one or more transferee(s).
> >     * A transferee may receive one transfer every 6 months, 
> so they'll
> >       be incented to transfer a block appropriately sized for their
> >       needs, which will further discourage deaggregation and keep
> >       smaller blocks available for smaller organizations.
> >
> >The proposal would also have ARIN develop and operate a 
> listing service 
> >to facilitate transfers and provide an authoritative central 
> source of 
> >information on space available and requested for transfer.  It would 
> >not prohibit private party transactions, but would require that 
> >potential transferors and transferees be pre-qualified 
> first, so that 
> >neither party will encounter any unexpected surprises when they ask 
> >ARIN to process the transfer.
> >
> >Timetable for implementation: Immediately, with most aspects 
> of policy 
> >taking effect upon IANA exhaustion, per the policy text.
> >
> >
> >
> >
> >_______________________________________________
> >PPML
> >You are receiving this message because you are subscribed to 
> the ARIN 
> >Public Policy Mailing List (PPML at arin.net).
> >Unsubscribe or manage your mailing list subscription at:
> >http://lists.arin.net/mailman/listinfo/ppml
> >Please contact the ARIN Member Services Help Desk at 
> 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 (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at 
> info at arin.net if you experience any issues.
> 


From plzak at arin.net  Tue Feb 12 08:41:28 2008
From: plzak at arin.net (Ray Plzak)
Date: Tue, 12 Feb 2008 08:41:28 -0500
Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer Policy
 Proposal
In-Reply-To: <7.0.1.0.1.20080212110845.05a8bb50@lacnic.net>
References: <47B0794F.40205@arin.net>
	<7.0.1.0.1.20080211164859.05618d40@lacnic.net>
	<47B0C378.8090401@apnic.net>
	<7.0.1.0.1.20080211202317.04fe9300@lacnic.net>
	<FEA070315E40A3489D38398C35FE7BB20298B1E4CD@EDAMAME.arin.net>
	<7.0.1.0.1.20080212102939.04fec760@lacnic.net>
	<47B19344.7040707@psg.com>
	<FEA070315E40A3489D38398C35FE7BB20298B1E506@EDAMAME.arin.net>
	<7.0.1.0.1.20080212110845.05a8bb50@lacnic.net>
Message-ID: <FEA070315E40A3489D38398C35FE7BB20298B1E539@EDAMAME.arin.net>

Raul,

The policies that have been proposed in the various regions thus far are all regional only. None attempt to bring in the global community. I see  nothing that precludes these policies from moving forward in their respective regions. Certainly in the discussions that take place in the individual regions, global implications have been and will be continued to be discussed. The communities should not have to wait for a global strategy in order to discuss the merits of various aspects of these proposals as they will have to be discussed in any event.


Ray

> -----Original Message-----
> From: Raul Echeberria [mailto:raul at lacnic.net]
> Sent: Tuesday, February 12, 2008 9:11 AM
> To: Ray Plzak; Randy Bush
> Cc: ppml at arin.net; sig-policy at apnic.net
> Subject: Re: [sig-policy] [ppml] Policy Proposal: IPv4 Transfer Policy
> Proposal
>
>
> Ray
>
> My point is that we first need a global strategy and later probably
> global and/or coordinated policies for implementing that strategy.
> And of course, I agree with you regarding commitments, and rest that
> you said.
>
> Raul
>
>
> At 09:45 a.m. 12/02/2008, Ray Plzak wrote:
> >Merely pointing out that there are implications to the use of the
> >term globally coordinated policy, a term that has been used many
> >times over the past several months, perhaps a little to glibly.
> >
> >Even a global and coordinated strategy will require commitments,
> >once made, must not be subject to disassembly by the subsequent
> >actions of a single RIR. Once that happens the global and
> >coordinated strategy is neither global or coordinated. Think locally
> >while acting globally is more than just a catchy phrase.
> >
> >Ray
> >
> > > -----Original Message-----
> > > From: Randy Bush [mailto:randy at psg.com]
> > > Sent: Tuesday, February 12, 2008 7:38 AM
> > > To: Raul Echeberria
> > > Cc: Ray Plzak; ppml at arin.net; sig-policy at apnic.net
> > > Subject: Re: [sig-policy] [ppml] Policy Proposal: IPv4 Transfer
> Policy
> > > Proposal
> > >
> > > > I am not necessarily claiming for a global or a coordinated
> policy
> > > > (maybe yes), but for a global "and" coordinated strategy for
> dealing
> > > > with a global problem.
> > >
> > > too radical.  it is our right to think locally while acting
> globally.
> > > that's why there are five rirs, right?
> > >
> > > randy
> >
> >*              sig-policy:  APNIC SIG on resource management
> >policy           *
> >_______________________________________________
> >sig-policy mailing list
> >sig-policy at lists.apnic.net
> >http://mailman.apnic.net/mailman/listinfo/sig-policy
> >
> >
> >--
> >No virus found in this incoming message.
> >Checked by AVG Free Edition.
> >Version: 7.5.516 / Virus Database: 269.20.2/1273 - Release Date:
> >12/02/2008 09:31 a.m.
>
>



From raul at lacnic.net  Tue Feb 12 10:56:49 2008
From: raul at lacnic.net (Raul Echeberria)
Date: Tue, 12 Feb 2008 12:56:49 -0300
Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer Policy
 Proposal
In-Reply-To: <FEA070315E40A3489D38398C35FE7BB20298B1E539@EDAMAME.arin.ne
 t>
References: <47B0794F.40205@arin.net>
	<7.0.1.0.1.20080211164859.05618d40@lacnic.net>
	<47B0C378.8090401@apnic.net>
	<7.0.1.0.1.20080211202317.04fe9300@lacnic.net>
	<FEA070315E40A3489D38398C35FE7BB20298B1E4CD@EDAMAME.arin.net>
	<7.0.1.0.1.20080212102939.04fec760@lacnic.net>
	<47B19344.7040707@psg.com>
	<FEA070315E40A3489D38398C35FE7BB20298B1E506@EDAMAME.arin.net>
	<7.0.1.0.1.20080212110845.05a8bb50@lacnic.net>
	<FEA070315E40A3489D38398C35FE7BB20298B1E539@EDAMAME.arin.net>
Message-ID: <7.0.1.0.1.20080212125257.04dba050@lacnic.net>

At 10:41 a.m. 12/02/2008, Ray Plzak wrote:
>Raul,
>
>The policies that have been proposed in the 
>various regions thus far are all regional only.

That's clear.

>  None attempt to bring in the global community.

That's clear.

>I see  nothing that precludes these policies 
>from moving forward in their respective regions.
>  Certainly in the discussions that take place 
> in the individual regions, global implications 
> have been and will be continued to be 
> discussed. The communities should not have to 
> wait for a global strategy in order to discuss 
> the merits of various aspects of these 
> proposals as they will have to be discussed in any event.

I don't see your point.
Who proposed to stop?de discussion?
I only gave my opinion and that is that global 
problems need of global aproaches.


Ra?l




From sleibrand at internap.com  Tue Feb 12 10:07:34 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Tue, 12 Feb 2008 09:07:34 -0600
Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer Policy
	Proposal
In-Reply-To: <7.0.1.0.1.20080212125257.04dba050@lacnic.net>
References: <47B0794F.40205@arin.net>	<7.0.1.0.1.20080211164859.05618d40@lacnic.net>	<47B0C378.8090401@apnic.net>	<7.0.1.0.1.20080211202317.04fe9300@lacnic.net>	<FEA070315E40A3489D38398C35FE7BB20298B1E4CD@EDAMAME.arin.net>	<7.0.1.0.1.20080212102939.04fec760@lacnic.net>	<47B19344.7040707@psg.com>	<FEA070315E40A3489D38398C35FE7BB20298B1E506@EDAMAME.arin.net>	<7.0.1.0.1.20080212110845.05a8bb50@lacnic.net>	<FEA070315E40A3489D38398C35FE7BB20298B1E539@EDAMAME.arin.net>
	<7.0.1.0.1.20080212125257.04dba050@lacnic.net>
Message-ID: <47B1B636.1060407@internap.com>

In the short term, I think Ray is correct that we need to move forward 
with considering these policy proposals independently at each RIR.  In 
the long term, I think Raul is correct that we need to consider more 
global approaches, either in terms of a globally coordinated policy on 
inter-RIR transfers, or on a bilateral adjustment of policies between 
two RIRs to allow transfers between them.

IOW, I think we're in violent agreement.  :-)

-Scott

Raul Echeberria wrote:
> At 10:41 a.m. 12/02/2008, Ray Plzak wrote:
>   
>> Raul,
>>
>> The policies that have been proposed in the 
>> various regions thus far are all regional only.
>>     
>
> That's clear.
>
>   
>>  None attempt to bring in the global community.
>>     
>
> That's clear.
>
>   
>> I see  nothing that precludes these policies 
>>     
> >from moving forward in their respective regions.
>   
>>  Certainly in the discussions that take place 
>> in the individual regions, global implications 
>> have been and will be continued to be 
>> discussed. The communities should not have to 
>> wait for a global strategy in order to discuss 
>> the merits of various aspects of these 
>> proposals as they will have to be discussed in any event.
>>     
>
> I don't see your point.
> Who proposed to stop?de discussion?
> I only gave my opinion and that is that global 
> problems need of global aproaches.
>
>
> Ra?l
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues.
>   


From bicknell at ufp.org  Tue Feb 12 10:26:13 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 12 Feb 2008 10:26:13 -0500
Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer
	Policy	Proposal
In-Reply-To: <47B0D496.2030800@apnic.net>
References: <47B0794F.40205@arin.net>
	<7.0.1.0.1.20080211164859.05618d40@lacnic.net>
	<47B0C378.8090401@apnic.net>
	<7.0.1.0.1.20080211202317.04fe9300@lacnic.net>
	<47B0D496.2030800@apnic.net>
Message-ID: <20080212152613.GB14759@ussenterprise.ufp.org>

In a message written on Tue, Feb 12, 2008 at 10:04:54AM +1100, Geoff Huston wrote:
> Concerning mechanics, in looking at the APNIC and ARIN proposals they 
> both take the approach of "qualification" of the two parties to a 
> transfer. One approach would be to 'recognise' the qualification from 
> another region - i.e. taking an ARIN perspective a "transferor" (is that 
> really an english word? ;-)) meets the criteria listed in section 8.4.1. 
>   To extend this to allow cross-RIR transfers it would be a case of 
> adding "or meets the criteria as listed (insert reference to the 
> transfer policy of another RIR) for members of (RIR). Similarly the 
> conditions of the transferee could be augmented by reference to the 
> relevant qualifications in the policies of other RIRs. So in terms of 
> extending the mechanics of the policy proposals to encompass cross-RIR 
> transfers then I'd suggest that there are ways to achieve this though 
> the use of mutual recognition of each RIR's qualification processes.

I'd like to agree with Geoff's analysis.  I think the mechanics of
doing this across RIR are relatively simple as he explains.  We
also have experience from the ERX effort in actually getting the
database entries to the right place.

Rather than trying to pass a global policy having each region pass
a reciprocity policy of sorts.  This has two advantages.  First,
it should be faster than a true global policy.  Second, it can
create a stalemate that prevents change.  The problem of a "globally
coordinated policy" has been discussed.  Rather than have everyone
agree not to make changes it's easier to enforce if ARIN's policy
says "we'll grant reciprocity to any RIR's policy that contains a
requirement to do x, y, and z."  A change away from x, y, or z would
automatically stop the reciprocity, which is a far greater consequence
than having the global policy no longer be coordinated.

However, I also agree with Geoff that the larger issue is the
potential for unintended consequences.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20080212/e6093b92/attachment.bin>

From michael.dillon at bt.com  Tue Feb 12 10:55:07 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 12 Feb 2008 15:55:07 -0000
Subject: [ppml] [sig-policy] Policy Proposal: IPv4
	TransferPolicy	Proposal
In-Reply-To: <20080212152613.GB14759@ussenterprise.ufp.org>
References: <47B0794F.40205@arin.net><7.0.1.0.1.20080211164859.05618d40@lacnic.net><47B0C378.8090401@apnic.net><7.0.1.0.1.20080211202317.04fe9300@lacnic.net><47B0D496.2030800@apnic.net>
	<20080212152613.GB14759@ussenterprise.ufp.org>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B001F2B7D7@E03MVC4-UKBR.domain1.systemhost.net>

> Rather than trying to pass a global policy having each region 
> pass a reciprocity policy of sorts. 

What's the point?

Most of the time, when IP addresses are transferred, it is
coupled to the sale of network assets. Two and a half years 
ago, I worked for an American company that was acquired by
a British company. The addresses transferred to the new
owner but we do not want to shift them to RIPE. They are
still used by the same network assests. It means that we have
to pay a bit more money, e.g. $12,000 annual fees to ARIN,
but this is peanuts compared to the cost of transferring
them to RIPE and making sure that the internal systems and
people are ready to cope with this.

I don't think we are alone here. Many ISPs maintain several
RIR relationships, especially when they have network assets
in multiple RIR regions.

In fact, is there currently a barrier to doing an ERX style
transfer? For instance, imagine that a European ISP built 
a network in the USA, using RIPE addresses, and then decided
to pull out of the USA and sell it to another ISP. The new owner,
whether located in the EU or the US, decides that it wants 
to maintain an ARIN relationship for the address blocks used
in its American network. Assume that the ownership transfer of
IP addresses within RIPE has already been done. Can this ISP
transfer these addresses to ARIN under current rules?

If not, why not? What are the specific barriers? If this was
a US incorporated owner would it make a difference?

> However, I also agree with Geoff that the larger issue is the 
> potential for unintended consequences.

That's what happens when you try to fix something that ain't broke.

Quite frankly, I have not seen anything yet which sets out the
issues and shows that there is clearly a concrete problem that
needs to be fixed. So far it seems more like a game of "me too!"
but I'm not convinced that any of the participants have clearly
explained what problem they are trying to solve.

I'm not interested in policies whose rationale is jumping on
someone else's bandwagon when I don't even know where that
wagon is headed.

--Michael Dillon
 


From sleibrand at internap.com  Tue Feb 12 11:24:16 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Tue, 12 Feb 2008 10:24:16 -0600
Subject: [ppml] [sig-policy] Policy Proposal:
	IPv4	TransferPolicy	Proposal
In-Reply-To: <D03E4899F2FB3D4C8464E8C76B3B68B001F2B7D7@E03MVC4-UKBR.domain1.systemhost.net>
References: <47B0794F.40205@arin.net><7.0.1.0.1.20080211164859.05618d40@lacnic.net><47B0C378.8090401@apnic.net><7.0.1.0.1.20080211202317.04fe9300@lacnic.net><47B0D496.2030800@apnic.net>	<20080212152613.GB14759@ussenterprise.ufp.org>
	<D03E4899F2FB3D4C8464E8C76B3B68B001F2B7D7@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <47B1C830.9060309@internap.com>

michael.dillon at bt.com wrote:
> In fact, is there currently a barrier to doing an ERX style
> transfer? For instance, imagine that a European ISP built 
> a network in the USA, using RIPE addresses, and then decided
> to pull out of the USA and sell it to another ISP. The new owner,
> whether located in the EU or the US, decides that it wants 
> to maintain an ARIN relationship for the address blocks used
> in its American network. Assume that the ownership transfer of
> IP addresses within RIPE has already been done. Can this ISP
> transfer these addresses to ARIN under current rules?
>
> If not, why not? What are the specific barriers? If this was
> a US incorporated owner would it make a difference?
>   

My understanding of ERX is that it allows legacy (classful) blocks to be 
transferred between registries.  I think it would be possible to 
ERX-transfer a Class A /8 or a Class B /16 to another RIR, and then 
transfer that space under that RIR's transfer policy.  However, I don't 
think there are any good mechanisms for delegating whois and DNS 
authority for arbitrary CIDR blocks, so I'm not sure the same thing 
would be possible for a non-legacy non-classful allocation or assignment 
received from an RIR.

>
> That's what happens when you try to fix something that ain't broke.
>
> Quite frankly, I have not seen anything yet which sets out the
> issues and shows that there is clearly a concrete problem that
> needs to be fixed. So far it seems more like a game of "me too!"
> but I'm not convinced that any of the participants have clearly
> explained what problem they are trying to solve.
>
> I'm not interested in policies whose rationale is jumping on
> someone else's bandwagon when I don't even know where that
> wagon is headed.
>   

The problem that needs to be fixed is that in a couple years we'll no 
longer be able to assign IPv4 addresses, and it doesn't appear that all 
the technology will be in place to allow everyone to switch to IPv6 at 
that point.  Given that dual-stack will be required, there will be a 
continued requirement to be able to get IPv4 addresses.  Unless we 
provide an incentive to encourage organizations to free up IPv4 space, 
there will not be sufficient IPv4 addresses returned to RIRs to meet 
that demand.  Conversely, if we create a transfer policy that enables a 
market, that will provide IPv4 holders the necessary incentive to free 
up IPv4 space (increasing IPv4 supply), and will encourage organizations 
needing IP addresses to use IPv6 or otherwise reduce their IPv4 needs 
(reducing IPv4 demand).  By balancing supply and demand, a transfer 
market reduces the overall disruption (cost) to the community of 
transitioning from IPv4 to IPv6.

-Scott



From jweyand at computerdata.com  Tue Feb 12 12:04:03 2008
From: jweyand at computerdata.com (Jim Weyand)
Date: Tue, 12 Feb 2008 12:04:03 -0500
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
Message-ID: <1582DCBFF968F044A9A910C0AB177C902CE55A@cliff.cdi.local>

Well done!  However I see one small issue that probably reflects my lack
of understanding:

Section 8.4.3 of the proposal below references NRPM 4.2.2. regarding
minimum allocation size and section 8.4.1 says, "The transferee may only
receive one IPv4 address transfer every 6 months."  

However NRPM 4.2.2.2.2. says, " Provide information showing that the
requested IP address space will be utilized within three months and
demonstrating..."

Which of course would mean that, to be consistent with the NRPM, a
transferee could only buy a three month supply of addresses every six
months.

  
-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of
Member Services
Sent: Monday, February 11, 2008 11:35 AM
To: ppml at arin.net
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal

Resending with a typo that has been corrected in 8.4.2 below. The 
original text is supposed to have "24 months" twice in that section.

Member Services
American Registry for Internet Numbers (ARIN)




ARIN received the following policy proposal. In accordance with the ARIN
Internet Resource Policy Evaluation Process, the proposal is being
posted to the ARIN Public Policy Mailing List (PPML) and being placed on
ARIN's website.

The ARIN Advisory Council (AC) will review this proposal at their next
regularly scheduled meeting. The AC may decide to:

   1. Accept the proposal as written. If the AC accepts the proposal, it
will be posted as a formal policy proposal to PPML and it will be
presented at a Public Policy Meeting.

   2. Not accept the proposal. If the AC does not accept the proposal,
the AC will explain their decision via the PPML. If a proposal is not
accepted, then the author may elect to use the petition process to
advance their proposal. If the author elects not to petition or the
petition fails, then the proposal will be closed.

The AC shepherds for this proposal are Scott Leibrand and Stacy Taylor.

The AC invites everyone to comment on this 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.

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal Name: IPv4 Transfer Policy Proposal

Author: ARIN Advisory Council

Proposal Version: 1.0

Submission Date: 02/07/2008

Proposal type: modify

Policy term: permanent

Policy statement:

Replace the current NRPM section 8 with the following --

8.         Transfers

[8.1.     Transfers - retain as is:

Number resources are non-transferable and are not assignable to any
other organization unless ARIN has expressly and in writing approved a
request for transfer.  ARIN is tasked with making prudent decisions on
whether to approve the transfer of number resources.

It should be understood that number resources are not "sold" under ARIN
administration. Rather, number resources are assigned to an organization
for its exclusive use for the purpose stated in the request, provided
the terms of the Registration Services Agreement continue to be met and
the stated purpose for the number resources remains the same. Number
resources are administered and assigned according to ARIN's published
policies.

Number resources are issued, based on justified need, to organizations,
not to individuals representing those organizations. Thus, if a company
goes out of business, regardless of the reason, the point of contact
(POC) listed for the number resource does not have the authority to
sell, transfer, assign, or give the number resource to any other person
or organization. The POC must notify ARIN if a business fails so the
assigned number resources can be returned to the available pool of
number resources if a transfer is not requested and justified.]


[8.2 - remove the word "only", and retitle to "M&A Transfer
Requirements":

8.2.      M&A Transfer Requirements

ARIN will consider requests for the transfer of number resources upon
receipt of evidence that the new entity has acquired the assets which
had, as of the date of the acquisition or proposed reorganization,
justified the current entity's use of the number resource. Examples of
assets that justify use of the number resource include, but are not
limited to:

     * Existing customer base
     * Qualified hardware inventory
     * Specific software requirements.]


[8.3 - retitle to "M&A Transfer Documentation Requirements":

8.3.      M&A Transfer Documentation Requirements

In evaluating a request for transfer, ARIN may require the requesting
organization to provide any of the following documents, as applicable,
plus any other documents deemed appropriate:

     * An authenticated copy of the instrument(s) effecting the transfer
       of assets, e.g., bill of sale, certificate of merger, contract,
       deed, or court decree
     * A detailed inventory of all assets utilized by the requesting
       party in maintaining and using the number resource
     * A list of the requesting party's customers using the number
resource.

If further justification is required, the requesting party may be asked
to provide any of the following, or other supporting documentation, as
applicable:

     * A general listing of the assets or components acquired
     * A specific description of acquisitions, including:
           o Type and quantity of equipment
           o Customer base
     * A description of how number resources are being utilized
     * Network engineering plans, including:
           o Host counts
           o Subnet masking
           o Network diagrams
           o Reassignments to customers]

8.4.      Requirements for Simple Transfer of IPv4 Addresses

After the exhaustion of the IANA IPv4 free pool, ARIN will also process
IPv4 address transfer requests subject to the following conditions.

8.4.1    Conditions on the transferor:

     * The transferor resides in the ARIN service area.
     * The transferor has signed an RSA and/or a legacy RSA covering the
       IPv4 addresses transferred.
     * The transferor has no outstanding balances with ARIN.
     * The transferor has not received any IPv4 allocations or
       assignments from ARIN (through ordinary allocations or
       assignments, or through this Simple Transfer policy) within the
       preceding 24 months.
     * The transferor may not request any IPv4 allocations or
assignments
       from ARIN (through ordinary allocations or assignments, or
through
       this Simple Transfer policy) within the subsequent 24 months.

8.4.2    Conditions on the transferee:

     * The transferee resides in the ARIN service area and intends to
use
       the transferred IPv4 addresses within the ARIN service area.
     * The transferee has no outstanding balances with ARIN.
     * The transferee's need is confirmed by ARIN, according to current
       ARIN policies, including but not limited to confirmation of
       utilization rate of any prior IPv4 allocations, assignments, or
       previously transferred IPv4 addresses held by the transferee.
     * The transferee signs (or has previously signed) an RSA covering
       the IPv4 addresses transferred.
     * The transferee has not provided any IPv4 addresses for transfer
       through this Simple Transfer process within the preceding 24
       months.
     * The transferee may not provide any IPv4 addresses for transfer
       through this Simple Transfer process within the subsequent 24
       months, except in the case of business failure.
     * The transferee may only receive one IPv4 address transfer every 6
       months.



8.4.3    Conditions on the IPv4 address block to be transferred:

     * The IPv4 block must comply with applicable ARIN requirements,
       including minimum allocation size (i.e. NRPM 4.2.2., 4.2.4.,
       4.3.2., 4.3.6.).  However, an IPv4 allocation or assignment of
/24
       or larger, but smaller than the current minimum allocation size,
       may be transferred as a whole resource, but may not be
subdivided.
     * The IPv4 block must currently be registered for use within the
       ARIN service area, either as part of an address block assigned by
       IANA to ARIN, or as part of a legacy address block allocated
       within the ARIN service area.
     * There must exist no dispute as to the status of the IPv4 block or
       regarding the allocation or assignment of such block to the
       transferor.
     * The transferor may retain one contiguous address range out of
       their original allocation or assignment for their own use, and
       transfer the other contiguous address range.  If the address
range
       to be transferred consists of multiple non-aggregatable CIDR
       blocks, each may be transferred to a different transferee.  The
       retained address range may not be further subdivided or
       transferred for a period of 12 months.

8.4.4    Fees

     * Completion of a transfer requires payment of a transfer fee
       according to ARIN's schedule of fees.
     * The transferee will be subject to all future ARIN membership and
       service fees according to the transferee's total address
holdings.

8.4.5    Pre-qualification

     * An interested transferee must seek pre-qualification from ARIN to
       confirm its eligibility to receive a transfer (including
       satisfaction of need according to current ARIN policies) before
       making any solicitation for transfer.  Upon pre-qualification,
       ARIN will provide the transferee with documentation of the
       pre-qualification, including the size (CIDR prefix length) of the
       largest IPv4 address block the transferee is eligible to receive,
       and the expiration date of the pre-qualification.
     * An interested transferor must seek pre-qualification from ARIN to
       confirm its eligibility to offer a transfer (including lack of
       outstanding balances and having signed an RSA) before offering
       IPv4 address resources for transfer.  Upon pre-qualification,
ARIN
       will provide the transferor with documentation of the
       pre-qualification, including the exact network address and size
       (CIDR prefix length) the transferor is eligible to provide, and
       the expiration date of the pre-qualification.

8.5.      Safe Harbor for IPv4 Transfers through this Simple Transfer
Process

IPv4 address resources being made available for transfer shall be exempt
from ARIN audit until expiration of the transfer pre-qualification or
completion of the transfer.  In the event that a transfer
pre-qualification expires, ARIN shall have up to 90 days to initiate an
audit prior to this exemption being reinstated through subsequent
transfer pre-qualification. This will not extend the end of the
exemption.

8.6.      Simple IPv4 Transfers to or from Organizations Under Common
Ownership or Control

If an IPv4 transferor or transferee is under common ownership or control
with any other organization that holds one or more IPv4 blocks, the IPv4
transfer request must report all such organizations under common
ownership or control.

When evaluating compliance with IPv4 Simple Transfer conditions, ARIN
may consider a transferor's transfer request in light of requests from
other organizations under common ownership or control with the
transferor.  Similarly, ARIN may consider a transferee's request in
light of requests from other organizations under common ownership or
control with the transferee.  In evaluating requests from other
organizations under common ownership or control, ARIN staff will
consider the relationship between the organizations, the degree of
coordination between the organizations, and the bona fide use of the
addresses at issue to determine whether all appropriate conditions are
met.

8.7.      Record-keeping and Publication of Simple Transfers of IPv4
Addresses

ARIN will develop and operate a listing service to assist interested
transferors and transferees by providing them a centralized location to
post information about IPv4 blocks available from prequalified
transferors and IPv4 blocks needed by prequalified transferees.

After completion of the transfer, ARIN will update the registration
records pertaining to the IPv4 block at issue.  ARIN will adjust its
records as to the holdings of the transferor and transferee.

After the transfer, ARIN will publish WHOIS data that reflects the
current allocation or assignment of the transferred block.  ARIN will
also make available information about any prior recipient(s) of such
block.  ARIN will also publish a log of all transfers, including block,
transferor, transferee, and date.


Rationale:

The ARIN Board of Trustees asked the Advisory Council to consider a set
of questions around the depletion of the free pool of IPv4 addresses,
the transition to IPv6 for Internet address needs in the future, and
ARIN's possible role in easing the transition.

Over the past few years the AC has spent a great deal of time reflecting
on these issues as a group, as individuals, and in consultation with
the community. One outcome of this process is this policy proposal,
which the AC is submitting for consideration at the next meeting. We are
proposing some changes to existing ARIN policy regarding the transfer of
IP address block registrations between subscribers, which will allow for
the emergence of trade in IPv4 address space, with ARIN to provide a
listing service for address blocks available for transfer under the
liberalized policy.  We are aware that this proposal, if adopted, will
mark a major change in ARIN's role in the community and the Internet.

This policy proposal would create a transfer mechanism for IPv4 number
resources between those who have excess resources and those who have a
need, thereby allowing ARIN to continue to serve its mission after IANA
free pool exhaustion.  This proposal would also set conditions on such
transfers intended to preserve as much as possible the existing policy
related to efficient, needs-based resource issuance, and would leverage
ARIN's extensive control systems, audit trails, and recognized position
as a trusted agent to avoid speculation and hoarding and diminish the
likelihood and extent of an uncontrolled 'black market' where the risk
and potential for fraud is immeasurably higher.

Many of the transfer conditions are self-explanatory, but some worth
highlighting are that:

     * To discourage speculation, a waiting period (proposed at 24
       months) is required before a transferee (or ordinary resource
       recipient) can become a transferor, or vice versa.
     * Transferees must qualify for IPv4 space (just as they do today
       when getting it from ARIN) before they can receive address space
       by transfer, or solicit space on a listing service.
     * To discourage unnecessarily rapid growth of routing tables, an
       allocation or assignment may not be arbitrarily deaggregated.  To
       allow a transferor to downsize within their existing space, they
       may split off a contiguous address range, once every 12 months,
       and transfer the resulting netblock(s), which are subject to
       ARIN's minimum allocation size, to one or more transferee(s).
     * A transferee may receive one transfer every 6 months, so they'll
       be incented to transfer a block appropriately sized for their
       needs, which will further discourage deaggregation and keep
       smaller blocks available for smaller organizations.

The proposal would also have ARIN develop and operate a listing service
to facilitate transfers and provide an authoritative central source of
information on space available and requested for transfer.  It would not
prohibit private party transactions, but would require that potential
transferors and transferees be pre-qualified first, so that neither
party will encounter any unexpected surprises when they ask ARIN to
process the transfer.

Timetable for implementation: Immediately, with most aspects of policy
taking effect upon IANA exhaustion, per the policy text.




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


From sleibrand at internap.com  Tue Feb 12 12:06:39 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Tue, 12 Feb 2008 11:06:39 -0600
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <1582DCBFF968F044A9A910C0AB177C902CE55A@cliff.cdi.local>
References: <1582DCBFF968F044A9A910C0AB177C902CE55A@cliff.cdi.local>
Message-ID: <47B1D21F.5030807@internap.com>

No, I think that reflects my failure to actually re-read 4.2.2 when 
writing 8.4.3.  :-)  I'll look into that and see what revisions are 
needed are needed to make them consistent.  Good catch.

Thanks,
Scott

Jim Weyand wrote:
> Well done!  However I see one small issue that probably reflects my lack
> of understanding:
>
> Section 8.4.3 of the proposal below references NRPM 4.2.2. regarding
> minimum allocation size and section 8.4.1 says, "The transferee may only
> receive one IPv4 address transfer every 6 months."  
>
> However NRPM 4.2.2.2.2. says, " Provide information showing that the
> requested IP address space will be utilized within three months and
> demonstrating..."
>
> Which of course would mean that, to be consistent with the NRPM, a
> transferee could only buy a three month supply of addresses every six
> months.
>
>   
> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of
> Member Services
> Sent: Monday, February 11, 2008 11:35 AM
> To: ppml at arin.net
> Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
>
> Resending with a typo that has been corrected in 8.4.2 below. The 
> original text is supposed to have "24 months" twice in that section.
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
>
>
> ARIN received the following policy proposal. In accordance with the ARIN
> Internet Resource Policy Evaluation Process, the proposal is being
> posted to the ARIN Public Policy Mailing List (PPML) and being placed on
> ARIN's website.
>
> The ARIN Advisory Council (AC) will review this proposal at their next
> regularly scheduled meeting. The AC may decide to:
>
>    1. Accept the proposal as written. If the AC accepts the proposal, it
> will be posted as a formal policy proposal to PPML and it will be
> presented at a Public Policy Meeting.
>
>    2. Not accept the proposal. If the AC does not accept the proposal,
> the AC will explain their decision via the PPML. If a proposal is not
> accepted, then the author may elect to use the petition process to
> advance their proposal. If the author elects not to petition or the
> petition fails, then the proposal will be closed.
>
> The AC shepherds for this proposal are Scott Leibrand and Stacy Taylor.
>
> The AC invites everyone to comment on this 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.
>
> The ARIN Internet Resource Policy Evaluation Process can be found at:
> http://www.arin.net/policy/irpep.html
>
> Mailing list subscription information can be found at:
> http://www.arin.net/mailing_lists/
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Policy Proposal Name: IPv4 Transfer Policy Proposal
>
> Author: ARIN Advisory Council
>
> Proposal Version: 1.0
>
> Submission Date: 02/07/2008
>
> Proposal type: modify
>
> Policy term: permanent
>
> Policy statement:
>
> Replace the current NRPM section 8 with the following --
>
> 8.         Transfers
>
> [8.1.     Transfers - retain as is:
>
> Number resources are non-transferable and are not assignable to any
> other organization unless ARIN has expressly and in writing approved a
> request for transfer.  ARIN is tasked with making prudent decisions on
> whether to approve the transfer of number resources.
>
> It should be understood that number resources are not "sold" under ARIN
> administration. Rather, number resources are assigned to an organization
> for its exclusive use for the purpose stated in the request, provided
> the terms of the Registration Services Agreement continue to be met and
> the stated purpose for the number resources remains the same. Number
> resources are administered and assigned according to ARIN's published
> policies.
>
> Number resources are issued, based on justified need, to organizations,
> not to individuals representing those organizations. Thus, if a company
> goes out of business, regardless of the reason, the point of contact
> (POC) listed for the number resource does not have the authority to
> sell, transfer, assign, or give the number resource to any other person
> or organization. The POC must notify ARIN if a business fails so the
> assigned number resources can be returned to the available pool of
> number resources if a transfer is not requested and justified.]
>
>
> [8.2 - remove the word "only", and retitle to "M&A Transfer
> Requirements":
>
> 8.2.      M&A Transfer Requirements
>
> ARIN will consider requests for the transfer of number resources upon
> receipt of evidence that the new entity has acquired the assets which
> had, as of the date of the acquisition or proposed reorganization,
> justified the current entity's use of the number resource. Examples of
> assets that justify use of the number resource include, but are not
> limited to:
>
>      * Existing customer base
>      * Qualified hardware inventory
>      * Specific software requirements.]
>
>
> [8.3 - retitle to "M&A Transfer Documentation Requirements":
>
> 8.3.      M&A Transfer Documentation Requirements
>
> In evaluating a request for transfer, ARIN may require the requesting
> organization to provide any of the following documents, as applicable,
> plus any other documents deemed appropriate:
>
>      * An authenticated copy of the instrument(s) effecting the transfer
>        of assets, e.g., bill of sale, certificate of merger, contract,
>        deed, or court decree
>      * A detailed inventory of all assets utilized by the requesting
>        party in maintaining and using the number resource
>      * A list of the requesting party's customers using the number
> resource.
>
> If further justification is required, the requesting party may be asked
> to provide any of the following, or other supporting documentation, as
> applicable:
>
>      * A general listing of the assets or components acquired
>      * A specific description of acquisitions, including:
>            o Type and quantity of equipment
>            o Customer base
>      * A description of how number resources are being utilized
>      * Network engineering plans, including:
>            o Host counts
>            o Subnet masking
>            o Network diagrams
>            o Reassignments to customers]
>
> 8.4.      Requirements for Simple Transfer of IPv4 Addresses
>
> After the exhaustion of the IANA IPv4 free pool, ARIN will also process
> IPv4 address transfer requests subject to the following conditions.
>
> 8.4.1    Conditions on the transferor:
>
>      * The transferor resides in the ARIN service area.
>      * The transferor has signed an RSA and/or a legacy RSA covering the
>        IPv4 addresses transferred.
>      * The transferor has no outstanding balances with ARIN.
>      * The transferor has not received any IPv4 allocations or
>        assignments from ARIN (through ordinary allocations or
>        assignments, or through this Simple Transfer policy) within the
>        preceding 24 months.
>      * The transferor may not request any IPv4 allocations or
> assignments
>        from ARIN (through ordinary allocations or assignments, or
> through
>        this Simple Transfer policy) within the subsequent 24 months.
>
> 8.4.2    Conditions on the transferee:
>
>      * The transferee resides in the ARIN service area and intends to
> use
>        the transferred IPv4 addresses within the ARIN service area.
>      * The transferee has no outstanding balances with ARIN.
>      * The transferee's need is confirmed by ARIN, according to current
>        ARIN policies, including but not limited to confirmation of
>        utilization rate of any prior IPv4 allocations, assignments, or
>        previously transferred IPv4 addresses held by the transferee.
>      * The transferee signs (or has previously signed) an RSA covering
>        the IPv4 addresses transferred.
>      * The transferee has not provided any IPv4 addresses for transfer
>        through this Simple Transfer process within the preceding 24
>        months.
>      * The transferee may not provide any IPv4 addresses for transfer
>        through this Simple Transfer process within the subsequent 24
>        months, except in the case of business failure.
>      * The transferee may only receive one IPv4 address transfer every 6
>        months.
>
>
>
> 8.4.3    Conditions on the IPv4 address block to be transferred:
>
>      * The IPv4 block must comply with applicable ARIN requirements,
>        including minimum allocation size (i.e. NRPM 4.2.2., 4.2.4.,
>        4.3.2., 4.3.6.).  However, an IPv4 allocation or assignment of
> /24
>        or larger, but smaller than the current minimum allocation size,
>        may be transferred as a whole resource, but may not be
> subdivided.
>      * The IPv4 block must currently be registered for use within the
>        ARIN service area, either as part of an address block assigned by
>        IANA to ARIN, or as part of a legacy address block allocated
>        within the ARIN service area.
>      * There must exist no dispute as to the status of the IPv4 block or
>        regarding the allocation or assignment of such block to the
>        transferor.
>      * The transferor may retain one contiguous address range out of
>        their original allocation or assignment for their own use, and
>        transfer the other contiguous address range.  If the address
> range
>        to be transferred consists of multiple non-aggregatable CIDR
>        blocks, each may be transferred to a different transferee.  The
>        retained address range may not be further subdivided or
>        transferred for a period of 12 months.
>
> 8.4.4    Fees
>
>      * Completion of a transfer requires payment of a transfer fee
>        according to ARIN's schedule of fees.
>      * The transferee will be subject to all future ARIN membership and
>        service fees according to the transferee's total address
> holdings.
>
> 8.4.5    Pre-qualification
>
>      * An interested transferee must seek pre-qualification from ARIN to
>        confirm its eligibility to receive a transfer (including
>        satisfaction of need according to current ARIN policies) before
>        making any solicitation for transfer.  Upon pre-qualification,
>        ARIN will provide the transferee with documentation of the
>        pre-qualification, including the size (CIDR prefix length) of the
>        largest IPv4 address block the transferee is eligible to receive,
>        and the expiration date of the pre-qualification.
>      * An interested transferor must seek pre-qualification from ARIN to
>        confirm its eligibility to offer a transfer (including lack of
>        outstanding balances and having signed an RSA) before offering
>        IPv4 address resources for transfer.  Upon pre-qualification,
> ARIN
>        will provide the transferor with documentation of the
>        pre-qualification, including the exact network address and size
>        (CIDR prefix length) the transferor is eligible to provide, and
>        the expiration date of the pre-qualification.
>
> 8.5.      Safe Harbor for IPv4 Transfers through this Simple Transfer
> Process
>
> IPv4 address resources being made available for transfer shall be exempt
> from ARIN audit until expiration of the transfer pre-qualification or
> completion of the transfer.  In the event that a transfer
> pre-qualification expires, ARIN shall have up to 90 days to initiate an
> audit prior to this exemption being reinstated through subsequent
> transfer pre-qualification. This will not extend the end of the
> exemption.
>
> 8.6.      Simple IPv4 Transfers to or from Organizations Under Common
> Ownership or Control
>
> If an IPv4 transferor or transferee is under common ownership or control
> with any other organization that holds one or more IPv4 blocks, the IPv4
> transfer request must report all such organizations under common
> ownership or control.
>
> When evaluating compliance with IPv4 Simple Transfer conditions, ARIN
> may consider a transferor's transfer request in light of requests from
> other organizations under common ownership or control with the
> transferor.  Similarly, ARIN may consider a transferee's request in
> light of requests from other organizations under common ownership or
> control with the transferee.  In evaluating requests from other
> organizations under common ownership or control, ARIN staff will
> consider the relationship between the organizations, the degree of
> coordination between the organizations, and the bona fide use of the
> addresses at issue to determine whether all appropriate conditions are
> met.
>
> 8.7.      Record-keeping and Publication of Simple Transfers of IPv4
> Addresses
>
> ARIN will develop and operate a listing service to assist interested
> transferors and transferees by providing them a centralized location to
> post information about IPv4 blocks available from prequalified
> transferors and IPv4 blocks needed by prequalified transferees.
>
> After completion of the transfer, ARIN will update the registration
> records pertaining to the IPv4 block at issue.  ARIN will adjust its
> records as to the holdings of the transferor and transferee.
>
> After the transfer, ARIN will publish WHOIS data that reflects the
> current allocation or assignment of the transferred block.  ARIN will
> also make available information about any prior recipient(s) of such
> block.  ARIN will also publish a log of all transfers, including block,
> transferor, transferee, and date.
>
>
> Rationale:
>
> The ARIN Board of Trustees asked the Advisory Council to consider a set
> of questions around the depletion of the free pool of IPv4 addresses,
> the transition to IPv6 for Internet address needs in the future, and
> ARIN's possible role in easing the transition.
>
> Over the past few years the AC has spent a great deal of time reflecting
> on these issues as a group, as individuals, and in consultation with
> the community. One outcome of this process is this policy proposal,
> which the AC is submitting for consideration at the next meeting. We are
> proposing some changes to existing ARIN policy regarding the transfer of
> IP address block registrations between subscribers, which will allow for
> the emergence of trade in IPv4 address space, with ARIN to provide a
> listing service for address blocks available for transfer under the
> liberalized policy.  We are aware that this proposal, if adopted, will
> mark a major change in ARIN's role in the community and the Internet.
>
> This policy proposal would create a transfer mechanism for IPv4 number
> resources between those who have excess resources and those who have a
> need, thereby allowing ARIN to continue to serve its mission after IANA
> free pool exhaustion.  This proposal would also set conditions on such
> transfers intended to preserve as much as possible the existing policy
> related to efficient, needs-based resource issuance, and would leverage
> ARIN's extensive control systems, audit trails, and recognized position
> as a trusted agent to avoid speculation and hoarding and diminish the
> likelihood and extent of an uncontrolled 'black market' where the risk
> and potential for fraud is immeasurably higher.
>
> Many of the transfer conditions are self-explanatory, but some worth
> highlighting are that:
>
>      * To discourage speculation, a waiting period (proposed at 24
>        months) is required before a transferee (or ordinary resource
>        recipient) can become a transferor, or vice versa.
>      * Transferees must qualify for IPv4 space (just as they do today
>        when getting it from ARIN) before they can receive address space
>        by transfer, or solicit space on a listing service.
>      * To discourage unnecessarily rapid growth of routing tables, an
>        allocation or assignment may not be arbitrarily deaggregated.  To
>        allow a transferor to downsize within their existing space, they
>        may split off a contiguous address range, once every 12 months,
>        and transfer the resulting netblock(s), which are subject to
>        ARIN's minimum allocation size, to one or more transferee(s).
>      * A transferee may receive one transfer every 6 months, so they'll
>        be incented to transfer a block appropriately sized for their
>        needs, which will further discourage deaggregation and keep
>        smaller blocks available for smaller organizations.
>
> The proposal would also have ARIN develop and operate a listing service
> to facilitate transfers and provide an authoritative central source of
> information on space available and requested for transfer.  It would not
> prohibit private party transactions, but would require that potential
> transferors and transferees be pre-qualified first, so that neither
> party will encounter any unexpected surprises when they ask ARIN to
> process the transfer.
>
> Timetable for implementation: Immediately, with most aspects of policy
> taking effect upon IANA exhaustion, per the policy text.
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at 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 (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues.
>   


From stephen at sprunk.org  Tue Feb 12 11:59:56 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Tue, 12 Feb 2008 10:59:56 -0600
Subject: [ppml] [sig-policy] Policy Proposal: IPv4TransferPolicy	Proposal
References: <47B0794F.40205@arin.net><7.0.1.0.1.20080211164859.05618d40@lacnic.net><47B0C378.8090401@apnic.net><7.0.1.0.1.20080211202317.04fe9300@lacnic.net><47B0D496.2030800@apnic.net><20080212152613.GB14759@ussenterprise.ufp.org>
	<D03E4899F2FB3D4C8464E8C76B3B68B001F2B7D7@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <00bb01c86d9a$249c3fb0$4b3816ac@atlanta.polycom.com>

Thus spake <michael.dillon at bt.com>
> In fact, is there currently a barrier to doing an ERX style
> transfer?

ERX was only for legacy registrations, which were all on convenient classful 
boundaries, limited in number, and in specific /8s that were already a mess 
from a DNS perspective; supporting an unknown number of transfers on 
arbitrary boundaries in any /8 is a rather more complex and painful 
undertaking.

> For instance, imagine that a European ISP built a network in the USA,
> using RIPE addresses,

They're not supposed to do that; while it's not written into the policies 
anywhere I can find, it seems to be accepted that addresses are only to be 
used in the region of the RIR that issued them, minus incidental use like a 
large network on one continent dropping a handful of routers at IXes on 
another continent.  If you've got actual customers in a given region, you 
should be getting addresses for them from the respective RIR, not the one 
where your headquarters is arbitrarily located this year.

How well the above is enforced in practice, I can't tell; my guess is that 
we don't see much "registry shopping" today because most members of the 
community voluntarily do the right thing, the RIRs' policies are largely 
equivalent, and the RIRs' staffs are doing a bit of enforcement via internal 
policies _not_ voted on by their members.  This probably needs fixing, but 
it doesn't seem urgent at this point.

> Assume that the ownership transfer of IP addresses within RIPE has
> already been done. Can this ISP transfer these addresses to ARIN
> under current rules?
>
> If not, why not? What are the specific barriers? If this was
> a US incorporated owner would it make a difference?

AFAIK, there is no process in place to transfer non-legacy blocks from one 
RIR to another.  If you have addresses in a /8 delegated by IANA to a given 
RIR, status quo is that they'll be registered with that RIR forever. 
Perhaps that needs to be changed, but we'd need a global policy to do it and 
AFAIK there is no such proposal on the table at present -- and we're past 
the deadline for any new proposals in the current ARIN cycle.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking 



From owen at delong.com  Tue Feb 12 13:47:46 2008
From: owen at delong.com (Owen DeLong)
Date: Tue, 12 Feb 2008 10:47:46 -0800
Subject: [ppml] [sig-policy] Policy Proposal: IPv4TransferPolicy	Proposal
In-Reply-To: <00bb01c86d9a$249c3fb0$4b3816ac@atlanta.polycom.com>
References: <47B0794F.40205@arin.net><7.0.1.0.1.20080211164859.05618d40@lacnic.net><47B0C378.8090401@apnic.net><7.0.1.0.1.20080211202317.04fe9300@lacnic.net><47B0D496.2030800@apnic.net><20080212152613.GB14759@ussenterprise.ufp.org>
	<D03E4899F2FB3D4C8464E8C76B3B68B001F2B7D7@E03MVC4-UKBR.domain1.systemhost.net>
	<00bb01c86d9a$249c3fb0$4b3816ac@atlanta.polycom.com>
Message-ID: <E028FBEC-757E-4091-855D-137FC79B1B5F@delong.com>

>> For instance, imagine that a European ISP built a network in the USA,
>> using RIPE addresses,
>
> They're not supposed to do that; while it's not written into the  
> policies
> anywhere I can find, it seems to be accepted that addresses are only  
> to be
> used in the region of the RIR that issued them, minus incidental use  
> like a
> large network on one continent dropping a handful of routers at IXes  
> on
> another continent.  If you've got actual customers in a given  
> region, you
> should be getting addresses for them from the respective RIR, not  
> the one
> where your headquarters is arbitrarily located this year.
>
This isn't entirely true.  For example, an international organization  
with
a backbone connecting their various sites could get a single delegation
from a single RIR for their global network.  It is possible (although  
not
common) to obtain and advertise a single aggregate worldwide.

> How well the above is enforced in practice, I can't tell; my guess  
> is that
> we don't see much "registry shopping" today because most members of  
> the
> community voluntarily do the right thing, the RIRs' policies are  
> largely
> equivalent, and the RIRs' staffs are doing a bit of enforcement via  
> internal
> policies _not_ voted on by their members.  This probably needs  
> fixing, but
> it doesn't seem urgent at this point.
>
Actually, the registries do a pretty good job of enforcing what should  
be
enforced.  That is, if the addresses aren't going to be advertised at  
least
from the source region, then, they should be obtained from an RIR that
covers at least one of the locations where they will be advertised.

There isn't much RIR shopping today, primarily because there aren't
that many organizations with the international backbone resources
necessary to make it feasible, and, the few that do don't really have
a need to RIR-shop.  Secondarily, the RIR policies and practices
are similar enough that there isn't really any major advantage to
be obtained by RIR shopping.

>> Assume that the ownership transfer of IP addresses within RIPE has
>> already been done. Can this ISP transfer these addresses to ARIN
>> under current rules?
>>
>> If not, why not? What are the specific barriers? If this was
>> a US incorporated owner would it make a difference?
>
> AFAIK, there is no process in place to transfer non-legacy blocks  
> from one
> RIR to another.  If you have addresses in a /8 delegated by IANA to  
> a given
> RIR, status quo is that they'll be registered with that RIR forever.
> Perhaps that needs to be changed, but we'd need a global policy to  
> do it and
> AFAIK there is no such proposal on the table at present -- and we're  
> past
> the deadline for any new proposals in the current ARIN cycle.
>
That reflects my understanding as well.  I'm not convinced that there
is significant benefit to providing for inter-regional transfers of
non-legacy space compared to the overhead of creating the policies
and, more importantly the processes to do such a thing.

Owen



From BillD at cait.wustl.edu  Tue Feb 12 13:50:12 2008
From: BillD at cait.wustl.edu (Bill Darte)
Date: Tue, 12 Feb 2008 12:50:12 -0600
Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer Policy
	Proposal
In-Reply-To: <7.0.1.0.1.20080212110845.05a8bb50@lacnic.net>
References: <47B0794F.40205@arin.net><7.0.1.0.1.20080211164859.05618d40@lacnic.net><47B0C378.8090401@apnic.net><7.0.1.0.1.20080211202317.04fe9300@lacnic.net><FEA070315E40A3489D38398C35FE7BB20298B1E4CD@EDAMAME.arin.net><7.0.1.0.1.20080212102939.04fec760@lacnic.net><47B19344.7040707@psg.com><FEA070315E40A3489D38398C35FE7BB20298B1E506@EDAMAME.arin.net>
	<7.0.1.0.1.20080212110845.05a8bb50@lacnic.net>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D0308754B475@ex1.cait.wustl.edu>

I wish that a global strategy were more understandable and within reach.

What are we talking about....global strategy to what?

The problem (a problem) is more localized than the RIR.  Need and
acquistion of address space (of whatever type) is localized within the
requestor.... The RIR and global mission is to make fair and relatively
inexpensive allocations and assignments of those resources.

That strategy could be to try and force organizations to request 1 type
of resource vs another or to encourage it or to, whatever.

Please define the need against which a global strategy may be applied
and how does it differ what appears to be similar policy proposals
emerging from RIRs?

Bill Darte
 

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Raul Echeberria
> Sent: Tuesday, February 12, 2008 8:11 AM
> To: Ray Plzak; Randy Bush
> Cc: ppml at arin.net; sig-policy at apnic.net
> Subject: Re: [ppml] [sig-policy] Policy Proposal: IPv4 
> Transfer Policy Proposal
> 
> 
> Ray
> 
> My point is that we first need a global strategy and later 
> probably global and/or coordinated policies for implementing 
> that strategy.
> And of course, I agree with you regarding commitments, and 
> rest that you said.
> 
> Raul
> 
> 
> At 09:45 a.m. 12/02/2008, Ray Plzak wrote:
> >Merely pointing out that there are implications to the use 
> of the term 
> >globally coordinated policy, a term that has been used many 
> times over 
> >the past several months, perhaps a little to glibly.
> >
> >Even a global and coordinated strategy will require 
> commitments, once 
> >made, must not be subject to disassembly by the subsequent 
> actions of a 
> >single RIR. Once that happens the global and coordinated strategy is 
> >neither global or coordinated. Think locally while acting 
> globally is 
> >more than just a catchy phrase.
> >
> >Ray
> >
> > > -----Original Message-----
> > > From: Randy Bush [mailto:randy at psg.com]
> > > Sent: Tuesday, February 12, 2008 7:38 AM
> > > To: Raul Echeberria
> > > Cc: Ray Plzak; ppml at arin.net; sig-policy at apnic.net
> > > Subject: Re: [sig-policy] [ppml] Policy Proposal: IPv4 Transfer 
> > > Policy Proposal
> > >
> > > > I am not necessarily claiming for a global or a 
> coordinated policy 
> > > > (maybe yes), but for a global "and" coordinated strategy for 
> > > > dealing with a global problem.
> > >
> > > too radical.  it is our right to think locally while 
> acting globally.
> > > that's why there are five rirs, right?
> > >
> > > randy
> >
> >*              sig-policy:  APNIC SIG on resource management 
> >policy           *
> >_______________________________________________
> >sig-policy mailing list
> >sig-policy at lists.apnic.net
> >http://mailman.apnic.net/mailman/listinfo/sig-policy
> >
> >
> >--
> >No virus found in this incoming message.
> >Checked by AVG Free Edition.
> >Version: 7.5.516 / Virus Database: 269.20.2/1273 - Release Date: 
> >12/02/2008 09:31 a.m.
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at 
> info at arin.net if you experience any issues.
> 


From BillD at cait.wustl.edu  Tue Feb 12 14:12:10 2008
From: BillD at cait.wustl.edu (Bill Darte)
Date: Tue, 12 Feb 2008 13:12:10 -0600
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <1202807058.11775.13.camel@obelix.sandbu>
References: <NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net>
	<1202807058.11775.13.camel@obelix.sandbu>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D0308754B477@ex1.cait.wustl.edu>

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Per Heldal
> Sent: Tuesday, February 12, 2008 3:04 AM
> To: Ted Mittelstaedt
> Cc: ppml at arin.net
> Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
> 
> 
> On Mon, 2008-02-11 at 16:36 -0800, Ted Mittelstaedt wrote:
> > I have some concerns with this proposal.
> > 
> > This policy seems to undermine the idea that IP addressing 
> is assigned 
> > on the basis of proving need.  It lends credibility to the 
> idea that 
> > IP addressing is property, and could open the door to any number of 
> > lawsuits based on this.  For example if an organization "purchases" 
> > IPv4 they could then file a lawsuit against a large provider which 
> > decided to block access from that purchased block, claiming 
> > discriminatory behavior.
> 
> The suggested policy also seems to be in conflict with the 
> RIR principle of not being involved in routing. Wherever 
> there's money to be made there's greed and that can't be 
> contained by simply telling people to "be nice". The value of 
> this kind of policy is questionable if it cannot be enforced. 
> To regulate other people's use of resources is fundamentally 
> different from the task of coordinating handouts from a resource-pool.


The transfer policy proposal does not attempt to eliminate greed, nor
does it try and enforce people to be nice.
It trys to coordinate transfers in such a way that does not abandon the
notion of 'justified need' and also provides continuing stability in the
industry and confidence that the address resources and associated ARIN
services that are being transferred are as close to the free-pool
precedent as possible, by way of thinking...

The policy does not restrict people from transferring resource in some
other way and with whatever conditions and qualifications are made... I
intends to give the ARIN region an alternative and clear set of
conditions under which transfers are made and recognized.  The expected
value is that people with TRUST this process more if ARIN contributes to
or coordinates it.


Bill Darte


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


From bicknell at ufp.org  Tue Feb 12 14:34:04 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 12 Feb 2008 14:34:04 -0500
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <1202807058.11775.13.camel@obelix.sandbu>
References: <NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net>
	<1202807058.11775.13.camel@obelix.sandbu>
Message-ID: <20080212193404.GB32279@ussenterprise.ufp.org>

In a message written on Tue, Feb 12, 2008 at 10:04:18AM +0100, Per Heldal wrote:
> The suggested policy also seems to be in conflict with the RIR principle
> of not being involved in routing. Wherever there's money to be made

I don't believe there is any such RIR principle.

All of the RIR's take a lot of input from those who do routing.
Many of the allocation policies were written by those familar with
routing in an effort to lead to an efficient, stable routing system.

What the RIR's have said repeatedly is that they cannot guarantee
routeability.  No RIR can promise that some ISP will get your route
in a table somewhere.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20080212/5c11af1e/attachment.bin>

From plzak at arin.net  Tue Feb 12 14:46:54 2008
From: plzak at arin.net (Ray Plzak)
Date: Tue, 12 Feb 2008 14:46:54 -0500
Subject: [ppml] [sig-policy] Policy Proposal: IPv4 TransferPolicy
 Proposal
In-Reply-To: <47B1C830.9060309@internap.com>
References: <47B0794F.40205@arin.net><7.0.1.0.1.20080211164859.05618d40@lacnic.net><47B0C378.8090401@apnic.net><7.0.1.0.1.20080211202317.04fe9300@lacnic.net><47B0D496.2030800@apnic.net>
	<20080212152613.GB14759@ussenterprise.ufp.org>
	<D03E4899F2FB3D4C8464E8C76B3B68B001F2B7D7@E03MVC4-UKBR.domain1.systemhost.net>
	<47B1C830.9060309@internap.com>
Message-ID: <FEA070315E40A3489D38398C35FE7BB20298B1E628@EDAMAME.arin.net>

The purpose of the ERX (Early Registration Transfer) project was to align the administration of the DNS of a legacy netblock to the region in which that recipient was resident. Prior to this, holders of address space that they received from the InterNIC had all of the attributes of their record in the database of the RIR where they resided (for example a European legacy holder's whois record was in the RIPE database) except for those attributes that pertained to the DNS. All DNS records were maintained by ARIN as ARIN was the administrator for all legacy address space zones. This caused the holder of such address space to have to deal with two RIRs for routine database maintenance. ERX changed this so that the holder only had to interact with one RIR. DNS maintenance was accomplished by production of the zone file by all the RIRs concerned with the servers being operated by the RIR holding the most records in the /8. The ERX process is not a means by which holders of address space may transfer holding  between RIRs. It is a strictly a means by which to administer the DNS of a /8 zone when more than 1 RIR has holdings in that zone.

Ray

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of
> Scott Leibrand
> Sent: Tuesday, February 12, 2008 11:24 AM
> To: michael.dillon at bt.com
> Cc: ppml at arin.net
> Subject: Re: [ppml] [sig-policy] Policy Proposal: IPv4 TransferPolicy
> Proposal
>
> michael.dillon at bt.com wrote:
> > In fact, is there currently a barrier to doing an ERX style
> > transfer? For instance, imagine that a European ISP built
> > a network in the USA, using RIPE addresses, and then decided
> > to pull out of the USA and sell it to another ISP. The new owner,
> > whether located in the EU or the US, decides that it wants
> > to maintain an ARIN relationship for the address blocks used
> > in its American network. Assume that the ownership transfer of
> > IP addresses within RIPE has already been done. Can this ISP
> > transfer these addresses to ARIN under current rules?
> >
> > If not, why not? What are the specific barriers? If this was
> > a US incorporated owner would it make a difference?
> >
>
> My understanding of ERX is that it allows legacy (classful) blocks to
> be
> transferred between registries.  I think it would be possible to
> ERX-transfer a Class A /8 or a Class B /16 to another RIR, and then
> transfer that space under that RIR's transfer policy.  However, I don't
> think there are any good mechanisms for delegating whois and DNS
> authority for arbitrary CIDR blocks, so I'm not sure the same thing
> would be possible for a non-legacy non-classful allocation or
> assignment
> received from an RIR.
>
> >
> > That's what happens when you try to fix something that ain't broke.
> >
> > Quite frankly, I have not seen anything yet which sets out the
> > issues and shows that there is clearly a concrete problem that
> > needs to be fixed. So far it seems more like a game of "me too!"
> > but I'm not convinced that any of the participants have clearly
> > explained what problem they are trying to solve.
> >
> > I'm not interested in policies whose rationale is jumping on
> > someone else's bandwagon when I don't even know where that
> > wagon is headed.
> >
>
> The problem that needs to be fixed is that in a couple years we'll no
> longer be able to assign IPv4 addresses, and it doesn't appear that all
> the technology will be in place to allow everyone to switch to IPv6 at
> that point.  Given that dual-stack will be required, there will be a
> continued requirement to be able to get IPv4 addresses.  Unless we
> provide an incentive to encourage organizations to free up IPv4 space,
> there will not be sufficient IPv4 addresses returned to RIRs to meet
> that demand.  Conversely, if we create a transfer policy that enables a
> market, that will provide IPv4 holders the necessary incentive to free
> up IPv4 space (increasing IPv4 supply), and will encourage
> organizations
> needing IP addresses to use IPv6 or otherwise reduce their IPv4 needs
> (reducing IPv4 demand).  By balancing supply and demand, a transfer
> market reduces the overall disruption (cost) to the community of
> transitioning from IPv4 to IPv6.
>
> -Scott
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at info at arin.net if
> you experience any issues.



From heldal at eml.cc  Tue Feb 12 14:48:30 2008
From: heldal at eml.cc (Per Heldal)
Date: Tue, 12 Feb 2008 20:48:30 +0100
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D0308754B477@ex1.cait.wustl.edu>
References: <NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net>
	<1202807058.11775.13.camel@obelix.sandbu>
	<EACF8B735E9CBA4B8BAF9E4165D0308754B477@ex1.cait.wustl.edu>
Message-ID: <1202845710.11775.22.camel@obelix.sandbu>

On Tue, 2008-02-12 at 13:12 -0600, Bill Darte wrote:
> > -----Original Message-----
> > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> > Behalf Of Per Heldal
> > Sent: Tuesday, February 12, 2008 3:04 AM
> > To: Ted Mittelstaedt
> > Cc: ppml at arin.net
> > Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
> > 
> > 
> > On Mon, 2008-02-11 at 16:36 -0800, Ted Mittelstaedt wrote:
> > > I have some concerns with this proposal.
> > > 
> > > This policy seems to undermine the idea that IP addressing 
> > is assigned 
> > > on the basis of proving need.  It lends credibility to the 
> > idea that 
> > > IP addressing is property, and could open the door to any number of 
> > > lawsuits based on this.  For example if an organization "purchases" 
> > > IPv4 they could then file a lawsuit against a large provider which 
> > > decided to block access from that purchased block, claiming 
> > > discriminatory behavior.
> > 
> > The suggested policy also seems to be in conflict with the 
> > RIR principle of not being involved in routing. Wherever 
> > there's money to be made there's greed and that can't be 
> > contained by simply telling people to "be nice". The value of 
> > this kind of policy is questionable if it cannot be enforced. 
> > To regulate other people's use of resources is fundamentally 
> > different from the task of coordinating handouts from a resource-pool.
> 
> 
> The transfer policy proposal does not attempt to eliminate greed, nor
> does it try and enforce people to be nice.
> It trys to coordinate transfers in such a way that does not abandon the
> notion of 'justified need' and also provides continuing stability in the
> industry and confidence that the address resources and associated ARIN
> services that are being transferred are as close to the free-pool
> precedent as possible, by way of thinking...
> 

You define conditions which must be met to approve transfer, yet claim
to place no restrictions on the process transfer ??? 

> The policy does not restrict people from transferring resource in some
> other way and with whatever conditions and qualifications are made... I
> intends to give the ARIN region an alternative and clear set of
> conditions under which transfers are made and recognized.  The expected
> value is that people with TRUST this process more if ARIN contributes to
> or coordinates it.

I agree with the motive, but think it's naive to expect the desired
effect unless there are sanctions in place to deal with offenders (LIRs
required to drop/filter disputed blocks or similar), but then you're
back in conflict with the traditional hands-off-approach to routing
again.


//per

 



From heldal at eml.cc  Tue Feb 12 15:10:40 2008
From: heldal at eml.cc (Per Heldal)
Date: Tue, 12 Feb 2008 21:10:40 +0100
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <20080212193404.GB32279@ussenterprise.ufp.org>
References: <NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net>
	<1202807058.11775.13.camel@obelix.sandbu>
	<20080212193404.GB32279@ussenterprise.ufp.org>
Message-ID: <1202847040.11775.42.camel@obelix.sandbu>


On Tue, 2008-02-12 at 14:34 -0500, Leo Bicknell wrote:
> In a message written on Tue, Feb 12, 2008 at 10:04:18AM +0100, Per Heldal wrote:
> > The suggested policy also seems to be in conflict with the RIR principle
> > of not being involved in routing. Wherever there's money to be made
> 
> I don't believe there is any such RIR principle.
> 

Not to say what is right or wrong, but there has been a general attitude
against operational involvement in routing. At least within the RIRs I
know (RIPE, ARIN and APNIC) going back to the late 90's. That has
translated into e.g.:

- weak or missing mechanisms to deal with policy offenders.

- weak and mainly unofficial recommendations wrt various aspects of
prefix filtering.

The general expression communicated has been "we're not the routing
police" ... which may be ok, until you create policies that make no
sense unenforced.


> All of the RIR's take a lot of input from those who do routing.
> Many of the allocation policies were written by those familar with
> routing in an effort to lead to an efficient, stable routing system.
> 
> What the RIR's have said repeatedly is that they cannot guarantee
> routeability.  No RIR can promise that some ISP will get your route
> in a table somewhere.

All the RIRs can guarantee under current policies is uniqueness wrt the
allocations they make from the blocks they've been delegated authority
for. 

("RIR" is here the ops-unit that do the actual work. For the
RIR-community things can quickly change if there's political motivation
within the community for change.)


//per



From david.kessens at nsn.com  Tue Feb 12 16:49:34 2008
From: david.kessens at nsn.com (David Kessens)
Date: Tue, 12 Feb 2008 13:49:34 -0800
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <7.0.1.0.1.20080211202317.04fe9300@lacnic.net>
References: <47B0794F.40205@arin.net>
	<7.0.1.0.1.20080211164859.05618d40@lacnic.net>
	<47B0C378.8090401@apnic.net>
	<7.0.1.0.1.20080211202317.04fe9300@lacnic.net>
Message-ID: <20080212214934.GF6961@nsn.com>


Raul,

On Mon, Feb 11, 2008 at 08:31:34PM -0300, Raul Echeberria wrote:
> 
> One observation.
> 
> Accepting transfers only within the region is a 
> way to keep the IP addresses within the regions 
> in which they were originally allocated.
> I don't know if it is good or not, but a fact.

I would formulate this slightly different:

Accepting transfers within the region is a way to keep the IP addresses
*registered* within the same region.

When the problems are big enough, people will find ways around
arbritrary and restrictive procedures that are designed to keep
addresses within a certain region.

In addition, liquidity is key to providing a viable and vibrant
marketplace. Barriers to this usually only benefit people in the
arbitrage business in addition to larger corporations that have a much
easier time to operate across borders.

David Kessens
---


From schiller at uu.net  Tue Feb 12 16:52:18 2008
From: schiller at uu.net (Jason Schiller)
Date: Tue, 12 Feb 2008 16:52:18 -0500 (EST)
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal - 24
 month freeze
In-Reply-To: <47B07198.2050106@arin.net>
Message-ID: <Pine.GSO.4.20.0802121630530.24719-100000@meno.corp.us.uu.net>

I have concerns about section 8.4.1 and 8.4.2.  At a high level these
sections say if you receive a transfer (act as a transferee) or transfer a
block (act as a transferor) then you will be prevented from requesting
additional address space for 24 months.

This may be problematic if one of the following occurs:

1.  Sell or spin off a portion of the network that is less profitable,
(this includes some network assets, all of its customers on those assets,
and a transfer of the associated addresses) but continue to grow the
remaining network thereby requiring additional addresses.  

2. Purchase another company that represents a profitable niche market or
profitable niche service, (this includes some of its network assets, all
of its customers on those assets and transfer of the associated
addresses) but continue to grow the pre-exist network thereby requiring
additional addresses, while maintaining the purchased customer base or
services and their associated address utilization

3. Performing two or more spin offs or acquisitions with a 24 month period
with no need for additional addresses.

Is this 24 month freeze the intention of the policy, or an over sight?

___Jason

On Tue, 12 Feb 2008 michael.dillon at bt.com wrote:
> Most of the time, when IP addresses are transferred, it is
> coupled to the sale of network assets. 

On Mon, 11 Feb 2008, Member Services wrote:

> 8.4.      Requirements for Simple Transfer of IPv4 Addresses
> 
> After the exhaustion of the IANA IPv4 free pool, ARIN will also process
> IPv4 address transfer requests subject to the following conditions.
> 
> 8.4.1    Conditions on the transferor:
> 
>      * The transferor resides in the ARIN service area.
>      * The transferor has signed an RSA and/or a legacy RSA covering the
>        IPv4 addresses transferred.
>      * The transferor has no outstanding balances with ARIN.
>      * The transferor has not received any IPv4 allocations or
>        assignments from ARIN (through ordinary allocations or
>        assignments, or through this Simple Transfer policy) within the
>        preceding 24 months.
>      * The transferor may not request any IPv4 allocations or assignments
>        from ARIN (through ordinary allocations or assignments, or through
>        this Simple Transfer policy) within the subsequent 24 months.
> 
> 8.4.2    Conditions on the transferee:
> 
>      * The transferee resides in the ARIN service area and intends to use
>        the transferred IPv4 addresses within the ARIN service area.
>      * The transferee has no outstanding balances with ARIN.
>      * The transferee?s need is confirmed by ARIN, according to current
>        ARIN policies, including but not limited to confirmation of
>        utilization rate of any prior IPv4 allocations, assignments, or
>        previously transferred IPv4 addresses held by the transferee.
>      * The transferee signs (or has previously signed) an RSA covering
>        the IPv4 addresses transferred.
>      * The transferee has not provided any IPv4 addresses for transfer
>        through this Simple Transfer process within the preceding 2
>        months.
>      * The transferee may not provide any IPv4 addresses for transfer
>        through this Simple Transfer process within the subsequent 24
>        months, except in the case of business failure.
>      * The transferee may only receive one IPv4 address transfer every 6
>        months.
> 
> 
> 



From sleibrand at internap.com  Tue Feb 12 17:12:07 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Tue, 12 Feb 2008 16:12:07 -0600
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal - 24
 month freeze
In-Reply-To: <Pine.GSO.4.20.0802121630530.24719-100000@meno.corp.us.uu.net>
References: <Pine.GSO.4.20.0802121630530.24719-100000@meno.corp.us.uu.net>
Message-ID: <47B219B7.9070209@internap.com>

Jason Schiller wrote:
> I have concerns about section 8.4.1 and 8.4.2.  At a high level these
> sections say if you receive a transfer (act as a transferee) or transfer a
> block (act as a transferor) then you will be prevented from requesting
> additional address space for 24 months.
>   

The 24 month timeframe is only if you want to switch from being a 
transferor to a transferee, or vice versa. That is to prevent 
speculation. If you perform an M&A transfer (the kind allowed by current 
policy), those restrictions do not apply, and you can still get 
addresses as a transferee through the Simple IPv4 transfer policy.

There is a 6-month restriction on getting additional address space, 
which is intended to make sure you get a big enough block the first time 
to meet your needs for that timeframe, rather than scraping up lots of 
smaller netblocks. However, it doesn't sound like that's what you're 
referring to.

-Scott

> This may be problematic if one of the following occurs:
>
> 1.  Sell or spin off a portion of the network that is less profitable,
> (this includes some network assets, all of its customers on those assets,
> and a transfer of the associated addresses) but continue to grow the
> remaining network thereby requiring additional addresses.  
>
> 2. Purchase another company that represents a profitable niche market or
> profitable niche service, (this includes some of its network assets, all
> of its customers on those assets and transfer of the associated
> addresses) but continue to grow the pre-exist network thereby requiring
> additional addresses, while maintaining the purchased customer base or
> services and their associated address utilization
>
> 3. Performing two or more spin offs or acquisitions with a 24 month period
> with no need for additional addresses.
>
> Is this 24 month freeze the intention of the policy, or an over sight?
>
> ___Jason
>
> On Tue, 12 Feb 2008 michael.dillon at bt.com wrote:
>   
>> Most of the time, when IP addresses are transferred, it is
>> coupled to the sale of network assets. 
>>     
>
> On Mon, 11 Feb 2008, Member Services wrote:
>
>   
>> 8.4.      Requirements for Simple Transfer of IPv4 Addresses
>>
>> After the exhaustion of the IANA IPv4 free pool, ARIN will also process
>> IPv4 address transfer requests subject to the following conditions.
>>
>> 8.4.1    Conditions on the transferor:
>>
>>      * The transferor resides in the ARIN service area.
>>      * The transferor has signed an RSA and/or a legacy RSA covering the
>>        IPv4 addresses transferred.
>>      * The transferor has no outstanding balances with ARIN.
>>      * The transferor has not received any IPv4 allocations or
>>        assignments from ARIN (through ordinary allocations or
>>        assignments, or through this Simple Transfer policy) within the
>>        preceding 24 months.
>>      * The transferor may not request any IPv4 allocations or assignments
>>        from ARIN (through ordinary allocations or assignments, or through
>>        this Simple Transfer policy) within the subsequent 24 months.
>>
>> 8.4.2    Conditions on the transferee:
>>
>>      * The transferee resides in the ARIN service area and intends to use
>>        the transferred IPv4 addresses within the ARIN service area.
>>      * The transferee has no outstanding balances with ARIN.
>>      * The transferee?s need is confirmed by ARIN, according to current
>>        ARIN policies, including but not limited to confirmation of
>>        utilization rate of any prior IPv4 allocations, assignments, or
>>        previously transferred IPv4 addresses held by the transferee.
>>      * The transferee signs (or has previously signed) an RSA covering
>>        the IPv4 addresses transferred.
>>      * The transferee has not provided any IPv4 addresses for transfer
>>        through this Simple Transfer process within the preceding 2
>>        months.
>>      * The transferee may not provide any IPv4 addresses for transfer
>>        through this Simple Transfer process within the subsequent 24
>>        months, except in the case of business failure.
>>      * The transferee may only receive one IPv4 address transfer every 6
>>        months.
>>
>>
>>
>>     
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues.
>   


From JOHN at egh.com  Tue Feb 12 17:14:43 2008
From: JOHN at egh.com (John Santos)
Date: Tue, 12 Feb 2008 17:14:43 -0500
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal - 24
	month freeze
In-Reply-To: <Pine.GSO.4.20.0802121630530.24719-100000@meno.corp.us.uu.net>
Message-ID: <1080212170120.549A-100000@Ives.egh.com>

On Tue, 12 Feb 2008, Jason Schiller wrote:

> I have concerns about section 8.4.1 and 8.4.2.  At a high level these
> sections say if you receive a transfer (act as a transferee) or transfer a
> block (act as a transferor) then you will be prevented from requesting
> additional address space for 24 months.
> 
> This may be problematic if one of the following occurs:
> 
> 1.  Sell or spin off a portion of the network that is less profitable,
> (this includes some network assets, all of its customers on those assets,
> and a transfer of the associated addresses) but continue to grow the
> remaining network thereby requiring additional addresses.  
> 
> 2. Purchase another company that represents a profitable niche market or
> profitable niche service, (this includes some of its network assets, all
> of its customers on those assets and transfer of the associated
> addresses) but continue to grow the pre-exist network thereby requiring
> additional addresses, while maintaining the purchased customer base or
> services and their associated address utilization
> 
> 3. Performing two or more spin offs or acquisitions with a 24 month period
> with no need for additional addresses.
> 
> Is this 24 month freeze the intention of the policy, or an over sight?
> 
> ___Jason
> 

My understanding is that is has always been possible to transfer
address space when companies merge or are acquired by other companies,
(or presumably when part of a company is spun off.)  The physical
network with its addresses intact is transfered to the new company.
For example, HP now controls the DEC /8 because DEC merged with Compaq
and HP then bought the combined Compaq/DEC.  And a million other
examples.  I think the theory is if the original company had demonstrated
need for the address space, and the new company is continuing to operate
the original network, then it clearly has need for the (same) address
space.

As I understand it, the new policy here is intended to deal with cases
where there is *no* ongoing business relationship between the transferor
and the transferee, one just has available address space which the other
needs, and they've come to an agreement (pending ARIN approval), presumably
for cash or other consideration.

So Jason's scenario would fall under existing policies and the new
policy would not apply.

Please correct me if I'm wrong.

(Maybe DEC isn't a good example above because it's most likely a legacy,
but I'm sure there are a hundreds if not thousands of other examples.)



-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

From sleibrand at internap.com  Wed Feb 13 10:33:28 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Wed, 13 Feb 2008 10:33:28 -0500
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <D03E4899F2FB3D4C8464E8C76B3B68B001F2B4F7@E03MVC4-UKBR.domain1.systemhost.net>
References: <NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net>	<47B12650.2060107@internap.com>
	<D03E4899F2FB3D4C8464E8C76B3B68B001F2B4F7@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <47B30DC8.5020907@internap.com>

michael.dillon at bt.com wrote:
>> Yes.  There is a large installed base for whom migrating to 
>> IPv6 may be painful (expensive).  Reducing the community's 
>> total expense for operating their IP networks is a benefit to 
>> the Internet community.
>>     
>
> RED HERRING!
>
> Given the fact that ISPs who implement IPv6 transit service
> will also have to implement transition mechanisms such as
> Teredo, 6to4, etc., there is no imperative for any part of
> the installed base to migrate to IPv6 before they are ready.
>
> The imperative today is for those organizations with steadily
> growing networks at the heart of their business model (ISPs) 
> to begin transitioning. Whether it is painful or not, they must
> do it or die because network growth is fundamental to their
> being.
>   

I think you make an unjustified assumption that ISPs will be able to 
deploy IPv6-only service to new customers and operate transition 
mechanisms such as Teredo, 6to4, etc.

An alternative, and IMO more likely, transition mechanism is to use two 
much more familiar technologies: dual stack and NAT.  Many consumer ISPs 
will be able to start providing IPv6 support, provide the ability for 
their customers to dual-stack, and then start providing NAT'd RFC1918 
addresses to their DHCP customers instead of public IPs.  This will be 
fairly easy for some ISPs, and more difficult for others (such as 
business ISPs, with more static-IP customers and smaller DHCP pools).  
In addition, there will be a great diversity of IPv6 support in 
middleboxes (home routers, enterprise firewalls, etc.)

Given this diversity in cost of migrating to IPv6 (dual-stack) and 
reducing IPv4 demand, there is an opportunity to allow organizations for 
whom the migration cost is higher to delay migration until IPv6 
technology is better developed/deployed, and in the mean time get IPv4 
addresses from other organizations for whom the migration cost is 
lower.  Additionally, such a transfer policy would provide an incentive 
to encourage organizations to migrate their installed base to some form 
of IPv6 where it's easier to do so, rather than requiring growing 
networks to do so if it's more expensive for them.

> If an ISP decided to try and avoid implementing IPv6 by getting
> IPv4 addresses from other sources, they are simply backing
> themselves into a corner and relying on their competitors to
> operate transition mechanisms for them. This is a risky strategy
> since the market segment who are willing to buy IPv4 network
> access will be steadily shrinking. In addition, their existing
> customers will begin to move away because the ISP is perceived
> as being incompetent and at risk of hitting a brick wall.
>   

I suspect that after ARIN free pool exhaustion, all ISPs will offer some 
form of IPv6 service.  To do so successfully, and support dual-stack, 
however, there will be a continued need for IPv4 addresses.  In some 
cases, a network may be able to free up enough IPv4 addresses to allow 
them to transfer them to other organizations.  In other cases, they'll 
be able to free up some, but not all, of their existing IPv4 addresses 
and use the remainder for growth.  In other cases, growth may overtake 
the ability of a network to cost-effectively reclaim IPv4 addresses 
(possibly due to a small install base), so continued availability of 
addresses from other organizations will be essential to avoiding much 
higher transition costs than are necessary.

>   
>>  This policy 
>> proposal allows organizations to choose what's best for them, 
>> rather than forcing a one-size-fits-all solution.
>>     
>
> I disagree that this policy does what you say. In fact this policy
> is trying to set up a market for buying and selling IP addresses.
>   

I don't think we're in disagreement here.  This policy proposal allows 
organizations to choose what's best for them by setting up a market for 
transferring IP addresses.  The addresses aren't property, so no one 
will be buying and selling the addresses themselves, but the underlying 
market economics will be similar.
> Under current policy, an ISP who migrates infrastructure to IPv6
> can return their IPv4 addresses to ARIN. And an ISP who is not
> migrating can continue to apply to ARIN for more IPv4 addresses 
> and receive the returned ones.
>
> This is clear and simple and easy to understand. It is the way
> that IPv4 allocation has always been done and is fully understood
> by everybody who deals with IP networking. Any new policy like
> the one proposed, simply muddies the waters and creates confusion.
>   

Yes, it is clear and simple, but it is not sufficient.  If a network has 
no incentive to go to the trouble of renumbering out of IPv4 addresses, 
they won't return them, and there won't be enough IPv4 addresses to meet 
the needs of those who need more addresses.  However, if the transfer 
process can cover the cost of renumbering, many more organizations will 
choose to do so.  To put it in basic economic terms, if we fix the price 
of scarce IPv4 addresses at zero (by leaving policy unchanged), supply 
will be insufficient to meet demand after the free pool is exhausted.  
If we allow price to be set by a market, the price will rise to the 
point where it increases supply and reduces demand enough to get them 
into balance.

-Scott


From schiller at uu.net  Wed Feb 13 10:36:17 2008
From: schiller at uu.net (Jason Schiller)
Date: Wed, 13 Feb 2008 10:36:17 -0500 (EST)
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal - 24
 month freeze
In-Reply-To: <47B219B7.9070209@internap.com>
Message-ID: <Pine.GSO.4.20.0802131034100.25103-100000@meno.corp.us.uu.net>

Scott,

Thanks for the clarification...

It wasn't clear to me from the text that section 8.4 does not apply to M&A
transfers even after IANA exhaustion.  Maybe that could be a bit more
specific?

__Jason

==========================================================================
Jason Schiller                                               (703)886.6648
Senior Internet Network Engineer                         fax:(703)886.0512
Public IP Global Network Engineering                       schiller at uu.net
UUNET / Verizon                         jason.schiller at verizonbusiness.com

The good news about having an email address that is twice as long is that
it increases traffic on the Internet.

On Tue, 12 Feb 2008, Scott Leibrand wrote:

> Date: Tue, 12 Feb 2008 16:12:07 -0600
> From: Scott Leibrand <sleibrand at internap.com>
> To: Jason Schiller <jason.schiller at verizonbusiness.com>
> Cc: ppml at arin.net
> Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal - 24
>     month freeze
> 
> Jason Schiller wrote:
> > I have concerns about section 8.4.1 and 8.4.2.  At a high level these
> > sections say if you receive a transfer (act as a transferee) or transfer a
> > block (act as a transferor) then you will be prevented from requesting
> > additional address space for 24 months.
> >   
> 
> The 24 month timeframe is only if you want to switch from being a 
> transferor to a transferee, or vice versa. That is to prevent 
> speculation. If you perform an M&A transfer (the kind allowed by current 
> policy), those restrictions do not apply, and you can still get 
> addresses as a transferee through the Simple IPv4 transfer policy.
> 
> There is a 6-month restriction on getting additional address space, 
> which is intended to make sure you get a big enough block the first time 
> to meet your needs for that timeframe, rather than scraping up lots of 
> smaller netblocks. However, it doesn't sound like that's what you're 
> referring to.
> 
> -Scott
> 
> > This may be problematic if one of the following occurs:
> >
> > 1.  Sell or spin off a portion of the network that is less profitable,
> > (this includes some network assets, all of its customers on those assets,
> > and a transfer of the associated addresses) but continue to grow the
> > remaining network thereby requiring additional addresses.  
> >
> > 2. Purchase another company that represents a profitable niche market or
> > profitable niche service, (this includes some of its network assets, all
> > of its customers on those assets and transfer of the associated
> > addresses) but continue to grow the pre-exist network thereby requiring
> > additional addresses, while maintaining the purchased customer base or
> > services and their associated address utilization
> >
> > 3. Performing two or more spin offs or acquisitions with a 24 month period
> > with no need for additional addresses.
> >
> > Is this 24 month freeze the intention of the policy, or an over sight?
> >
> > ___Jason
> >
> > On Tue, 12 Feb 2008 michael.dillon at bt.com wrote:
> >   
> >> Most of the time, when IP addresses are transferred, it is
> >> coupled to the sale of network assets. 
> >>     
> >
> > On Mon, 11 Feb 2008, Member Services wrote:
> >
> >   
> >> 8.4.      Requirements for Simple Transfer of IPv4 Addresses
> >>
> >> After the exhaustion of the IANA IPv4 free pool, ARIN will also process
> >> IPv4 address transfer requests subject to the following conditions.
> >>
> >> 8.4.1    Conditions on the transferor:
> >>
> >>      * The transferor resides in the ARIN service area.
> >>      * The transferor has signed an RSA and/or a legacy RSA covering the
> >>        IPv4 addresses transferred.
> >>      * The transferor has no outstanding balances with ARIN.
> >>      * The transferor has not received any IPv4 allocations or
> >>        assignments from ARIN (through ordinary allocations or
> >>        assignments, or through this Simple Transfer policy) within the
> >>        preceding 24 months.
> >>      * The transferor may not request any IPv4 allocations or assignments
> >>        from ARIN (through ordinary allocations or assignments, or through
> >>        this Simple Transfer policy) within the subsequent 24 months.
> >>
> >> 8.4.2    Conditions on the transferee:
> >>
> >>      * The transferee resides in the ARIN service area and intends to use
> >>        the transferred IPv4 addresses within the ARIN service area.
> >>      * The transferee has no outstanding balances with ARIN.
> >>      * The transferee???s need is confirmed by ARIN, according to current
> >>        ARIN policies, including but not limited to confirmation of
> >>        utilization rate of any prior IPv4 allocations, assignments, or
> >>        previously transferred IPv4 addresses held by the transferee.
> >>      * The transferee signs (or has previously signed) an RSA covering
> >>        the IPv4 addresses transferred.
> >>      * The transferee has not provided any IPv4 addresses for transfer
> >>        through this Simple Transfer process within the preceding 2
> >>        months.
> >>      * The transferee may not provide any IPv4 addresses for transfer
> >>        through this Simple Transfer process within the subsequent 24
> >>        months, except in the case of business failure.
> >>      * The transferee may only receive one IPv4 address transfer every 6
> >>        months.
> >>
> >>
> >>
> >>     
> >
> >   
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to the ARIN Public Policy
> > Mailing List (PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/ppml
> > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues.
> >   
> 



From sleibrand at internap.com  Wed Feb 13 10:42:44 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Wed, 13 Feb 2008 10:42:44 -0500
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal - 24
 month freeze
In-Reply-To: <Pine.GSO.4.20.0802131034100.25103-100000@meno.corp.us.uu.net>
References: <Pine.GSO.4.20.0802131034100.25103-100000@meno.corp.us.uu.net>
Message-ID: <47B30FF4.30409@internap.com>

Ok. How about adding this last sentence to the first paragraph of 8.4:

8.4. Requirements for Simple Transfer of IPv4 Addresses


After the exhaustion of the IANA IPv4 free pool, ARIN will also process 
IPv4 address transfer requests subject to the following conditions. 
These conditions apply only to Simple IPv4 transfers, not to M&A 
transfers performed according to section 8.3.


-Scott

Jason Schiller wrote:
> Scott,
>
> Thanks for the clarification...
>
> It wasn't clear to me from the text that section 8.4 does not apply to M&A
> transfers even after IANA exhaustion.  Maybe that could be a bit more
> specific?
>
> __Jason
>
> ==========================================================================
> Jason Schiller                                               (703)886.6648
> Senior Internet Network Engineer                         fax:(703)886.0512
> Public IP Global Network Engineering                       schiller at uu.net
> UUNET / Verizon                         jason.schiller at verizonbusiness.com
>
> The good news about having an email address that is twice as long is that
> it increases traffic on the Internet.
>
> On Tue, 12 Feb 2008, Scott Leibrand wrote:
>
>   
>> Date: Tue, 12 Feb 2008 16:12:07 -0600
>> From: Scott Leibrand <sleibrand at internap.com>
>> To: Jason Schiller <jason.schiller at verizonbusiness.com>
>> Cc: ppml at arin.net
>> Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal - 24
>>     month freeze
>>
>> Jason Schiller wrote:
>>     
>>> I have concerns about section 8.4.1 and 8.4.2.  At a high level these
>>> sections say if you receive a transfer (act as a transferee) or transfer a
>>> block (act as a transferor) then you will be prevented from requesting
>>> additional address space for 24 months.
>>>   
>>>       
>> The 24 month timeframe is only if you want to switch from being a 
>> transferor to a transferee, or vice versa. That is to prevent 
>> speculation. If you perform an M&A transfer (the kind allowed by current 
>> policy), those restrictions do not apply, and you can still get 
>> addresses as a transferee through the Simple IPv4 transfer policy.
>>
>> There is a 6-month restriction on getting additional address space, 
>> which is intended to make sure you get a big enough block the first time 
>> to meet your needs for that timeframe, rather than scraping up lots of 
>> smaller netblocks. However, it doesn't sound like that's what you're 
>> referring to.
>>
>> -Scott
>>
>>     
>>> This may be problematic if one of the following occurs:
>>>
>>> 1.  Sell or spin off a portion of the network that is less profitable,
>>> (this includes some network assets, all of its customers on those assets,
>>> and a transfer of the associated addresses) but continue to grow the
>>> remaining network thereby requiring additional addresses.  
>>>
>>> 2. Purchase another company that represents a profitable niche market or
>>> profitable niche service, (this includes some of its network assets, all
>>> of its customers on those assets and transfer of the associated
>>> addresses) but continue to grow the pre-exist network thereby requiring
>>> additional addresses, while maintaining the purchased customer base or
>>> services and their associated address utilization
>>>
>>> 3. Performing two or more spin offs or acquisitions with a 24 month period
>>> with no need for additional addresses.
>>>
>>> Is this 24 month freeze the intention of the policy, or an over sight?
>>>
>>> ___Jason
>>>
>>> On Tue, 12 Feb 2008 michael.dillon at bt.com wrote:
>>>   
>>>       
>>>> Most of the time, when IP addresses are transferred, it is
>>>> coupled to the sale of network assets. 
>>>>     
>>>>         
>>> On Mon, 11 Feb 2008, Member Services wrote:
>>>
>>>   
>>>       
>>>> 8.4.      Requirements for Simple Transfer of IPv4 Addresses
>>>>
>>>> After the exhaustion of the IANA IPv4 free pool, ARIN will also process
>>>> IPv4 address transfer requests subject to the following conditions.
>>>>
>>>> 8.4.1    Conditions on the transferor:
>>>>
>>>>      * The transferor resides in the ARIN service area.
>>>>      * The transferor has signed an RSA and/or a legacy RSA covering the
>>>>        IPv4 addresses transferred.
>>>>      * The transferor has no outstanding balances with ARIN.
>>>>      * The transferor has not received any IPv4 allocations or
>>>>        assignments from ARIN (through ordinary allocations or
>>>>        assignments, or through this Simple Transfer policy) within the
>>>>        preceding 24 months.
>>>>      * The transferor may not request any IPv4 allocations or assignments
>>>>        from ARIN (through ordinary allocations or assignments, or through
>>>>        this Simple Transfer policy) within the subsequent 24 months.
>>>>
>>>> 8.4.2    Conditions on the transferee:
>>>>
>>>>      * The transferee resides in the ARIN service area and intends to use
>>>>        the transferred IPv4 addresses within the ARIN service area.
>>>>      * The transferee has no outstanding balances with ARIN.
>>>>      * The transferee?s need is confirmed by ARIN, according to current
>>>>        ARIN policies, including but not limited to confirmation of
>>>>        utilization rate of any prior IPv4 allocations, assignments, or
>>>>        previously transferred IPv4 addresses held by the transferee.
>>>>      * The transferee signs (or has previously signed) an RSA covering
>>>>        the IPv4 addresses transferred.
>>>>      * The transferee has not provided any IPv4 addresses for transfer
>>>>        through this Simple Transfer process within the preceding 2
>>>>        months.
>>>>      * The transferee may not provide any IPv4 addresses for transfer
>>>>        through this Simple Transfer process within the subsequent 24
>>>>        months, except in the case of business failure.
>>>>      * The transferee may only receive one IPv4 address transfer every 6
>>>>        months.
>>>>
>>>>
>>>>
>>>>     
>>>>         
>>>   
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to the ARIN Public Policy
>>> Mailing List (PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/ppml
>>> Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues.
>>>   
>>>       
>
>   


From sleibrand at internap.com  Wed Feb 13 11:13:22 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Wed, 13 Feb 2008 11:13:22 -0500
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <47B1D21F.5030807@internap.com>
References: <1582DCBFF968F044A9A910C0AB177C902CE55A@cliff.cdi.local>
	<47B1D21F.5030807@internap.com>
Message-ID: <47B31722.5080600@internap.com>

Jim,

Reading over 4.2 and 4.3 of the NRPM, I see lots of different conditions 
for different types of networks.  Specifically, the text in 4.2.2.1.3 
and 4.2.2.2.2 requiring that the requested IP address space will be 
utilized within three months refers to organizations justifying an 
initial allocation on the basis of their use of PA space, and is 
intended to minimize delay in renumbering out of PA space (if 
applicable) and beginning to use and route the new space.  As I read 
those sections, they don't require 100% utilization within three months.

However, in 4.2.4.3 and 4.2.4.4, it does appear that a new ISP that 
needs additional space before they've been an ARIN member for a year can 
only justify a three-month supply of addresses.  After that, they can 
get six months' worth.  In the case of end users, they can get over a 
year's worth of space according to 4.3.3.

Given all this confusion, I'd like to decouple the 8.4 transfer policy's 
transfer sizes somewhat from the allocation and assignment sizes in 4.2 
and 4.3, by adding the following bullet point to 8.4.2:

    * The transferee may request and receive a contiguous CIDR block
      large enough to provide a 12 month supply of IPv4 addresses.

That will preserve the requirement that need and efficient use are 
justified, but would bypass the sections of 4.2 and 4.3 concerned with 
preventing hoarding (intentional or otherwise).  My assumption here is 
that the cost of transferring addresses and a 12-month supply rule would 
act as a sufficient brake to prevent anyone from getting more addresses 
than they need for that timeframe.  The 12-month supply should also be 
sufficient, in concert with the one-block-every-6-months condition, to 
ensure that transferees get enough address space to limit unnecessary 
deaggregation.

Thoughts?

-Scott
>
>
>             4.2.2.1.3. Three months
>
> Provide detailed information showing specifically how a /20 will be 
> utilized within three months.
>
>
>             4.2.2.2.2. Three months
>
> Provide information showing that the requested IP address space will 
> be utilized within three months and demonstrating an intent to 
> announce the requested space in a multihomed fashion.
>
>
>             4.2.2.2.4. Additional requests following the initial
>             allocation
>
> To receive additional address space following the initial allocation, 
> multihomed organizations must have returned the original IP address 
> space to its provider in its entirety and must provide justification 
> for a new allocation as described above in the section titled 
> Requirements for Requesting Initial Address Space.
>
>
>           4.2.4.3. Three months
>
> Provide detailed information showing specifically that the address 
> space will be utilized within three months. Determination of the 
> appropriate allocation to be issued is based on efficient utilization 
> of space within this three-month time frame.
>
>
>           4.2.4.4. Six months
>
> After a subscriber has been a member of ARIN for one year they may 
> choose to request a six-month supply of IP addresses.
>
>
>         4.3.3. Utilization rate
>
> Utilization rate of address space is a key factor in justifying a new 
> assignment of IP address space. Requesters must show exactly how 
> previous address assignments have been utilized and must provide 
> appropriate details to verify their one-year growth projection. The 
> basic criteria that must be met are:
>
>     * A 25% immediate utilization rate, and
>     * A 50% utilization rate within one year.
>


Scott Leibrand wrote:
> No, I think that reflects my failure to actually re-read 4.2.2 when 
> writing 8.4.3.  :-)  I'll look into that and see what revisions are 
> needed are needed to make them consistent.  Good catch.
>
> Thanks,
> Scott
>
> Jim Weyand wrote:
>   
>> Well done!  However I see one small issue that probably reflects my lack
>> of understanding:
>>
>> Section 8.4.3 of the proposal below references NRPM 4.2.2. regarding
>> minimum allocation size and section 8.4.1 says, "The transferee may only
>> receive one IPv4 address transfer every 6 months."  
>>
>> However NRPM 4.2.2.2.2. says, " Provide information showing that the
>> requested IP address space will be utilized within three months and
>> demonstrating..."
>>
>> Which of course would mean that, to be consistent with the NRPM, a
>> transferee could only buy a three month supply of addresses every six
>> months.
>>
>>   
>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of
>> Member Services
>> Sent: Monday, February 11, 2008 11:35 AM
>> To: ppml at arin.net
>> Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
>>
>> Resending with a typo that has been corrected in 8.4.2 below. The 
>> original text is supposed to have "24 months" twice in that section.
>>
>> Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>>
>>
>> ARIN received the following policy proposal. In accordance with the ARIN
>> Internet Resource Policy Evaluation Process, the proposal is being
>> posted to the ARIN Public Policy Mailing List (PPML) and being placed on
>> ARIN's website.
>>
>> The ARIN Advisory Council (AC) will review this proposal at their next
>> regularly scheduled meeting. The AC may decide to:
>>
>>    1. Accept the proposal as written. If the AC accepts the proposal, it
>> will be posted as a formal policy proposal to PPML and it will be
>> presented at a Public Policy Meeting.
>>
>>    2. Not accept the proposal. If the AC does not accept the proposal,
>> the AC will explain their decision via the PPML. If a proposal is not
>> accepted, then the author may elect to use the petition process to
>> advance their proposal. If the author elects not to petition or the
>> petition fails, then the proposal will be closed.
>>
>> The AC shepherds for this proposal are Scott Leibrand and Stacy Taylor.
>>
>> The AC invites everyone to comment on this 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.
>>
>> The ARIN Internet Resource Policy Evaluation Process can be found at:
>> http://www.arin.net/policy/irpep.html
>>
>> Mailing list subscription information can be found at:
>> http://www.arin.net/mailing_lists/
>>
>> Regards,
>>
>> Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> ## * ##
>>
>>
>> Policy Proposal Name: IPv4 Transfer Policy Proposal
>>
>> Author: ARIN Advisory Council
>>
>> Proposal Version: 1.0
>>
>> Submission Date: 02/07/2008
>>
>> Proposal type: modify
>>
>> Policy term: permanent
>>
>> Policy statement:
>>
>> Replace the current NRPM section 8 with the following --
>>
>> 8.         Transfers
>>
>> [8.1.     Transfers - retain as is:
>>
>> Number resources are non-transferable and are not assignable to any
>> other organization unless ARIN has expressly and in writing approved a
>> request for transfer.  ARIN is tasked with making prudent decisions on
>> whether to approve the transfer of number resources.
>>
>> It should be understood that number resources are not "sold" under ARIN
>> administration. Rather, number resources are assigned to an organization
>> for its exclusive use for the purpose stated in the request, provided
>> the terms of the Registration Services Agreement continue to be met and
>> the stated purpose for the number resources remains the same. Number
>> resources are administered and assigned according to ARIN's published
>> policies.
>>
>> Number resources are issued, based on justified need, to organizations,
>> not to individuals representing those organizations. Thus, if a company
>> goes out of business, regardless of the reason, the point of contact
>> (POC) listed for the number resource does not have the authority to
>> sell, transfer, assign, or give the number resource to any other person
>> or organization. The POC must notify ARIN if a business fails so the
>> assigned number resources can be returned to the available pool of
>> number resources if a transfer is not requested and justified.]
>>
>>
>> [8.2 - remove the word "only", and retitle to "M&A Transfer
>> Requirements":
>>
>> 8.2.      M&A Transfer Requirements
>>
>> ARIN will consider requests for the transfer of number resources upon
>> receipt of evidence that the new entity has acquired the assets which
>> had, as of the date of the acquisition or proposed reorganization,
>> justified the current entity's use of the number resource. Examples of
>> assets that justify use of the number resource include, but are not
>> limited to:
>>
>>      * Existing customer base
>>      * Qualified hardware inventory
>>      * Specific software requirements.]
>>
>>
>> [8.3 - retitle to "M&A Transfer Documentation Requirements":
>>
>> 8.3.      M&A Transfer Documentation Requirements
>>
>> In evaluating a request for transfer, ARIN may require the requesting
>> organization to provide any of the following documents, as applicable,
>> plus any other documents deemed appropriate:
>>
>>      * An authenticated copy of the instrument(s) effecting the transfer
>>        of assets, e.g., bill of sale, certificate of merger, contract,
>>        deed, or court decree
>>      * A detailed inventory of all assets utilized by the requesting
>>        party in maintaining and using the number resource
>>      * A list of the requesting party's customers using the number
>> resource.
>>
>> If further justification is required, the requesting party may be asked
>> to provide any of the following, or other supporting documentation, as
>> applicable:
>>
>>      * A general listing of the assets or components acquired
>>      * A specific description of acquisitions, including:
>>            o Type and quantity of equipment
>>            o Customer base
>>      * A description of how number resources are being utilized
>>      * Network engineering plans, including:
>>            o Host counts
>>            o Subnet masking
>>            o Network diagrams
>>            o Reassignments to customers]
>>
>> 8.4.      Requirements for Simple Transfer of IPv4 Addresses
>>
>> After the exhaustion of the IANA IPv4 free pool, ARIN will also process
>> IPv4 address transfer requests subject to the following conditions.
>>
>> 8.4.1    Conditions on the transferor:
>>
>>      * The transferor resides in the ARIN service area.
>>      * The transferor has signed an RSA and/or a legacy RSA covering the
>>        IPv4 addresses transferred.
>>      * The transferor has no outstanding balances with ARIN.
>>      * The transferor has not received any IPv4 allocations or
>>        assignments from ARIN (through ordinary allocations or
>>        assignments, or through this Simple Transfer policy) within the
>>        preceding 24 months.
>>      * The transferor may not request any IPv4 allocations or
>> assignments
>>        from ARIN (through ordinary allocations or assignments, or
>> through
>>        this Simple Transfer policy) within the subsequent 24 months.
>>
>> 8.4.2    Conditions on the transferee:
>>
>>      * The transferee resides in the ARIN service area and intends to
>> use
>>        the transferred IPv4 addresses within the ARIN service area.
>>      * The transferee has no outstanding balances with ARIN.
>>      * The transferee's need is confirmed by ARIN, according to current
>>        ARIN policies, including but not limited to confirmation of
>>        utilization rate of any prior IPv4 allocations, assignments, or
>>        previously transferred IPv4 addresses held by the transferee.
>>      * The transferee signs (or has previously signed) an RSA covering
>>        the IPv4 addresses transferred.
>>      * The transferee has not provided any IPv4 addresses for transfer
>>        through this Simple Transfer process within the preceding 24
>>        months.
>>      * The transferee may not provide any IPv4 addresses for transfer
>>        through this Simple Transfer process within the subsequent 24
>>        months, except in the case of business failure.
>>      * The transferee may only receive one IPv4 address transfer every 6
>>        months.
>>
>>
>>
>> 8.4.3    Conditions on the IPv4 address block to be transferred:
>>
>>      * The IPv4 block must comply with applicable ARIN requirements,
>>        including minimum allocation size (i.e. NRPM 4.2.2., 4.2.4.,
>>        4.3.2., 4.3.6.).  However, an IPv4 allocation or assignment of
>> /24
>>        or larger, but smaller than the current minimum allocation size,
>>        may be transferred as a whole resource, but may not be
>> subdivided.
>>      * The IPv4 block must currently be registered for use within the
>>        ARIN service area, either as part of an address block assigned by
>>        IANA to ARIN, or as part of a legacy address block allocated
>>        within the ARIN service area.
>>      * There must exist no dispute as to the status of the IPv4 block or
>>        regarding the allocation or assignment of such block to the
>>        transferor.
>>      * The transferor may retain one contiguous address range out of
>>        their original allocation or assignment for their own use, and
>>        transfer the other contiguous address range.  If the address
>> range
>>        to be transferred consists of multiple non-aggregatable CIDR
>>        blocks, each may be transferred to a different transferee.  The
>>        retained address range may not be further subdivided or
>>        transferred for a period of 12 months.
>>
>> 8.4.4    Fees
>>
>>      * Completion of a transfer requires payment of a transfer fee
>>        according to ARIN's schedule of fees.
>>      * The transferee will be subject to all future ARIN membership and
>>        service fees according to the transferee's total address
>> holdings.
>>
>> 8.4.5    Pre-qualification
>>
>>      * An interested transferee must seek pre-qualification from ARIN to
>>        confirm its eligibility to receive a transfer (including
>>        satisfaction of need according to current ARIN policies) before
>>        making any solicitation for transfer.  Upon pre-qualification,
>>        ARIN will provide the transferee with documentation of the
>>        pre-qualification, including the size (CIDR prefix length) of the
>>        largest IPv4 address block the transferee is eligible to receive,
>>        and the expiration date of the pre-qualification.
>>      * An interested transferor must seek pre-qualification from ARIN to
>>        confirm its eligibility to offer a transfer (including lack of
>>        outstanding balances and having signed an RSA) before offering
>>        IPv4 address resources for transfer.  Upon pre-qualification,
>> ARIN
>>        will provide the transferor with documentation of the
>>        pre-qualification, including the exact network address and size
>>        (CIDR prefix length) the transferor is eligible to provide, and
>>        the expiration date of the pre-qualification.
>>
>> 8.5.      Safe Harbor for IPv4 Transfers through this Simple Transfer
>> Process
>>
>> IPv4 address resources being made available for transfer shall be exempt
>> from ARIN audit until expiration of the transfer pre-qualification or
>> completion of the transfer.  In the event that a transfer
>> pre-qualification expires, ARIN shall have up to 90 days to initiate an
>> audit prior to this exemption being reinstated through subsequent
>> transfer pre-qualification. This will not extend the end of the
>> exemption.
>>
>> 8.6.      Simple IPv4 Transfers to or from Organizations Under Common
>> Ownership or Control
>>
>> If an IPv4 transferor or transferee is under common ownership or control
>> with any other organization that holds one or more IPv4 blocks, the IPv4
>> transfer request must report all such organizations under common
>> ownership or control.
>>
>> When evaluating compliance with IPv4 Simple Transfer conditions, ARIN
>> may consider a transferor's transfer request in light of requests from
>> other organizations under common ownership or control with the
>> transferor.  Similarly, ARIN may consider a transferee's request in
>> light of requests from other organizations under common ownership or
>> control with the transferee.  In evaluating requests from other
>> organizations under common ownership or control, ARIN staff will
>> consider the relationship between the organizations, the degree of
>> coordination between the organizations, and the bona fide use of the
>> addresses at issue to determine whether all appropriate conditions are
>> met.
>>
>> 8.7.      Record-keeping and Publication of Simple Transfers of IPv4
>> Addresses
>>
>> ARIN will develop and operate a listing service to assist interested
>> transferors and transferees by providing them a centralized location to
>> post information about IPv4 blocks available from prequalified
>> transferors and IPv4 blocks needed by prequalified transferees.
>>
>> After completion of the transfer, ARIN will update the registration
>> records pertaining to the IPv4 block at issue.  ARIN will adjust its
>> records as to the holdings of the transferor and transferee.
>>
>> After the transfer, ARIN will publish WHOIS data that reflects the
>> current allocation or assignment of the transferred block.  ARIN will
>> also make available information about any prior recipient(s) of such
>> block.  ARIN will also publish a log of all transfers, including block,
>> transferor, transferee, and date.
>>
>>
>> Rationale:
>>
>> The ARIN Board of Trustees asked the Advisory Council to consider a set
>> of questions around the depletion of the free pool of IPv4 addresses,
>> the transition to IPv6 for Internet address needs in the future, and
>> ARIN's possible role in easing the transition.
>>
>> Over the past few years the AC has spent a great deal of time reflecting
>> on these issues as a group, as individuals, and in consultation with
>> the community. One outcome of this process is this policy proposal,
>> which the AC is submitting for consideration at the next meeting. We are
>> proposing some changes to existing ARIN policy regarding the transfer of
>> IP address block registrations between subscribers, which will allow for
>> the emergence of trade in IPv4 address space, with ARIN to provide a
>> listing service for address blocks available for transfer under the
>> liberalized policy.  We are aware that this proposal, if adopted, will
>> mark a major change in ARIN's role in the community and the Internet.
>>
>> This policy proposal would create a transfer mechanism for IPv4 number
>> resources between those who have excess resources and those who have a
>> need, thereby allowing ARIN to continue to serve its mission after IANA
>> free pool exhaustion.  This proposal would also set conditions on such
>> transfers intended to preserve as much as possible the existing policy
>> related to efficient, needs-based resource issuance, and would leverage
>> ARIN's extensive control systems, audit trails, and recognized position
>> as a trusted agent to avoid speculation and hoarding and diminish the
>> likelihood and extent of an uncontrolled 'black market' where the risk
>> and potential for fraud is immeasurably higher.
>>
>> Many of the transfer conditions are self-explanatory, but some worth
>> highlighting are that:
>>
>>      * To discourage speculation, a waiting period (proposed at 24
>>        months) is required before a transferee (or ordinary resource
>>        recipient) can become a transferor, or vice versa.
>>      * Transferees must qualify for IPv4 space (just as they do today
>>        when getting it from ARIN) before they can receive address space
>>        by transfer, or solicit space on a listing service.
>>      * To discourage unnecessarily rapid growth of routing tables, an
>>        allocation or assignment may not be arbitrarily deaggregated.  To
>>        allow a transferor to downsize within their existing space, they
>>        may split off a contiguous address range, once every 12 months,
>>        and transfer the resulting netblock(s), which are subject to
>>        ARIN's minimum allocation size, to one or more transferee(s).
>>      * A transferee may receive one transfer every 6 months, so they'll
>>        be incented to transfer a block appropriately sized for their
>>        needs, which will further discourage deaggregation and keep
>>        smaller blocks available for smaller organizations.
>>
>> The proposal would also have ARIN develop and operate a listing service
>> to facilitate transfers and provide an authoritative central source of
>> information on space available and requested for transfer.  It would not
>> prohibit private party transactions, but would require that potential
>> transferors and transferees be pre-qualified first, so that neither
>> party will encounter any unexpected surprises when they ask ARIN to
>> process the transfer.
>>
>> Timetable for implementation: Immediately, with most aspects of policy
>> taking effect upon IANA exhaustion, per the policy text.
>>
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the ARIN
>> Public Policy
>> Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml
>> Please contact the ARIN Member Services Help Desk at 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 (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml
>> Please contact the ARIN Member Services Help Desk at 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 (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues.
>   


From kkargel at polartel.com  Wed Feb 13 12:19:07 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 13 Feb 2008 11:19:07 -0600
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <47B30DC8.5020907@internap.com>
References: <NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net>	<47B12650.2060107@internap.com><D03E4899F2FB3D4C8464E8C76B3B68B001F2B4F7@E03MVC4-UKBR.domain1.systemhost.net>
	<47B30DC8.5020907@internap.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail>

Just to give some feedback FROM one the ISP's you are talking about..
Our plan is to go dual stack as soon as ANY of our upstream providers
can feed us dual stack.  We are already working on the enterprise dual
stack routing, and have actually established an IPv6 tunnel connection
(that I don't want to route real traffic over and abuse the network that
was so kind as to let us connect).  Luckily, we use exclusively Cisco
routing hardware, which has dual stack funtionality built in.  

There is no way we will be able to go IPv6 only until ALL of the major
content providers are IPv6 functional, and ALL of the email providers
are compliant.  Think of how you would complain if your ISP went IPv6
and told you that you could now email to "some" places..  or even "most"
places.  

There are a lot of things that need to be functional before IPv6 is a
reality for ISP's..  little stuff like IPv6 RBL's, bug free IPv6 VPN
compatibility with ALL of the major VPN hardware and software vendors,
IPv6 connectivity for entertainment networks like Xbox Live and PS3,
gaming sites, IM protocols, and a host of other applications that
consumers rightfully demand.  Any one of these "trivial" services not
working is a deal killer for an ISP converting to IPv6 only.  

So whether or not it is more expensive, more work, or otherwise more
painful, ISP's will be forced to maintain IPv4 connectivity until
content there is obsoleted.

What tends to be forgotten, is that for the little guys IPv6 will not be
a complete solution until EVERYTHING that is available on IPv4 is also
available on IPv6 and the use is just as transparant to the end user.  

Kevin


> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Scott Leibrand
> Sent: Wednesday, February 13, 2008 9:33 AM
> To: michael.dillon at bt.com
> Cc: ppml at arin.net
> Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
> 
> michael.dillon at bt.com wrote:
> >> Yes.  There is a large installed base for whom migrating to
> >> IPv6 may be painful (expensive).  Reducing the community's total 
> >> expense for operating their IP networks is a benefit to 
> the Internet 
> >> community.
> >>     
> >
> > RED HERRING!
> >
> > Given the fact that ISPs who implement IPv6 transit service 
> will also 
> > have to implement transition mechanisms such as Teredo, 6to4, etc., 
> > there is no imperative for any part of the installed base 
> to migrate 
> > to IPv6 before they are ready.
> >
> > The imperative today is for those organizations with 
> steadily growing 
> > networks at the heart of their business model (ISPs) to begin 
> > transitioning. Whether it is painful or not, they must do it or die 
> > because network growth is fundamental to their being.
> >   
> 
> I think you make an unjustified assumption that ISPs will be 
> able to deploy IPv6-only service to new customers and operate 
> transition mechanisms such as Teredo, 6to4, etc.
> 
> An alternative, and IMO more likely, transition mechanism is 
> to use two much more familiar technologies: dual stack and 
> NAT.  Many consumer ISPs will be able to start providing IPv6 
> support, provide the ability for their customers to 
> dual-stack, and then start providing NAT'd RFC1918 addresses 
> to their DHCP customers instead of public IPs.  This will be 
> fairly easy for some ISPs, and more difficult for others 
> (such as business ISPs, with more static-IP customers and 
> smaller DHCP pools).  
> In addition, there will be a great diversity of IPv6 support 
> in middleboxes (home routers, enterprise firewalls, etc.)
> 
> Given this diversity in cost of migrating to IPv6 
> (dual-stack) and reducing IPv4 demand, there is an 
> opportunity to allow organizations for whom the migration 
> cost is higher to delay migration until IPv6 technology is 
> better developed/deployed, and in the mean time get IPv4 
> addresses from other organizations for whom the migration 
> cost is lower.  Additionally, such a transfer policy would 
> provide an incentive to encourage organizations to migrate 
> their installed base to some form of IPv6 where it's easier 
> to do so, rather than requiring growing networks to do so if 
> it's more expensive for them.
> 
> > If an ISP decided to try and avoid implementing IPv6 by getting
> > IPv4 addresses from other sources, they are simply backing 
> themselves 
> > into a corner and relying on their competitors to operate 
> transition 
> > mechanisms for them. This is a risky strategy since the 
> market segment 
> > who are willing to buy IPv4 network access will be steadily 
> shrinking. 
> > In addition, their existing customers will begin to move 
> away because 
> > the ISP is perceived as being incompetent and at risk of hitting a 
> > brick wall.
> >   
> 
> I suspect that after ARIN free pool exhaustion, all ISPs will 
> offer some form of IPv6 service.  To do so successfully, and 
> support dual-stack, however, there will be a continued need 
> for IPv4 addresses.  In some cases, a network may be able to 
> free up enough IPv4 addresses to allow them to transfer them 
> to other organizations.  In other cases, they'll be able to 
> free up some, but not all, of their existing IPv4 addresses 
> and use the remainder for growth.  In other cases, growth may 
> overtake the ability of a network to cost-effectively reclaim 
> IPv4 addresses (possibly due to a small install base), so 
> continued availability of addresses from other organizations 
> will be essential to avoiding much higher transition costs 
> than are necessary.
> 
> >   
> >>  This policy
> >> proposal allows organizations to choose what's best for 
> them, rather 
> >> than forcing a one-size-fits-all solution.
> >>     
> >
> > I disagree that this policy does what you say. In fact this 
> policy is 
> > trying to set up a market for buying and selling IP addresses.
> >   
> 
> I don't think we're in disagreement here.  This policy 
> proposal allows organizations to choose what's best for them 
> by setting up a market for transferring IP addresses.  The 
> addresses aren't property, so no one will be buying and 
> selling the addresses themselves, but the underlying market 
> economics will be similar.
> > Under current policy, an ISP who migrates infrastructure to 
> IPv6 can 
> > return their IPv4 addresses to ARIN. And an ISP who is not 
> migrating 
> > can continue to apply to ARIN for more IPv4 addresses and 
> receive the 
> > returned ones.
> >
> > This is clear and simple and easy to understand. It is the way that 
> > IPv4 allocation has always been done and is fully understood by 
> > everybody who deals with IP networking. Any new policy like the one 
> > proposed, simply muddies the waters and creates confusion.
> >   
> 
> Yes, it is clear and simple, but it is not sufficient.  If a 
> network has no incentive to go to the trouble of renumbering 
> out of IPv4 addresses, they won't return them, and there 
> won't be enough IPv4 addresses to meet the needs of those who 
> need more addresses.  However, if the transfer process can 
> cover the cost of renumbering, many more organizations will 
> choose to do so.  To put it in basic economic terms, if we 
> fix the price of scarce IPv4 addresses at zero (by leaving 
> policy unchanged), supply will be insufficient to meet demand 
> after the free pool is exhausted.  
> If we allow price to be set by a market, the price will rise 
> to the point where it increases supply and reduces demand 
> enough to get them into balance.
> 
> -Scott
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at 
> info at arin.net if you experience any issues.
> 


From michael.dillon at bt.com  Wed Feb 13 12:37:14 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 13 Feb 2008 17:37:14 -0000
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <47B30DC8.5020907@internap.com>
References: <NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net>	<47B12650.2060107@internap.com>
	<D03E4899F2FB3D4C8464E8C76B3B68B001F2B4F7@E03MVC4-UKBR.domain1.systemhost.net>
	<47B30DC8.5020907@internap.com>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B001F2BED3@E03MVC4-UKBR.domain1.systemhost.net>

> > The imperative today is for those organizations with 
> steadily growing 
> > networks at the heart of their business model (ISPs) to begin 
> > transitioning. Whether it is painful or not, they must do it or die 
> > because network growth is fundamental to their being.

> Given this diversity in cost of migrating to IPv6 
> (dual-stack) and reducing IPv4 demand, there is an 
> opportunity to allow organizations for whom the migration 
> cost is higher to delay migration until IPv6 technology is 
> better developed/deployed, and in the mean time get IPv4 
> addresses from other organizations for whom the migration 
> cost is lower.  Additionally, such a transfer policy would 
> provide an incentive to encourage organizations to migrate 
> their installed base to some form of IPv6 where it's easier 
> to do so, rather than requiring growing networks to do so if 
> it's more expensive for them.

I agree that there will be diverse scenarios playing out, but
as I said, the pioneers of IPv6 deployment, not migration, wil
be ISPs since network growth is at the core of their business
model. This does not mean that they will be shrinking their
IPv4 networks, and even if they do recover some IPv4 address
space, there is no benefit to them to transfer it to someone
else. In fact, the benefit to ISPs is to reuse those IPv4
address to continue selling IPv4 services to the market segment
which demands that.

Given that this whole thing plays out at a time when there is
a worldwide scarcity of IPv4 addresses, I can't see any reason
for anyone to give up the IPv4 addresses that they have until
they are absolutely sure that doing so does not risk serious
business losses. That will take years after IANA runs out of
IPv4 addresses.

An then there is the technical issue of having a usable aggregate
of IPv4 addresses to transfer and not scattered small blocks.
An ISP has a number of ways of using scattered small blocks,
including carrying many long prefixes in their iBGP, but in
the global Internet, only large blocks/short prefixes are usable.

> I suspect that after ARIN free pool exhaustion, all ISPs will 
> offer some form of IPv6 service.  To do so successfully, and 
> support dual-stack, however, there will be a continued need 
> for IPv4 addresses.

That's why I don't believe many ISPs will go to dual stack on
any kind of scale. It is simpler to use MPLS with 6PE at the
edge, or build an IPv6 mesh over GRE or PWE3 on an IPv4 core.
This isolates the impact of IPv6 to the edge, and only to those
edge routers which are needed for IPv6 services.

> > I disagree that this policy does what you say. In fact this 
> policy is 
> > trying to set up a market for buying and selling IP addresses.
> 
> I don't think we're in disagreement here.  This policy 
> proposal allows organizations to choose what's best for them 
> by setting up a market for transferring IP addresses.  

As I have said in the past, you can't have a market without
liquidity and a resource that is not only scarce, but has a 
cap on supply, simply cannot provide that liquidity. I have
no doubt that there will be a few sales of IP address blocks, 
regardless of whether or not any RIR implements policies to
allow it, but the prices will not follow a pattern, and
will not be predictable. In general asking prices will be
astronomically high, and some sales will actually take
place at very high prices. But other sales will go through at
a fraction of the asking price because the only reason the
address block is on the market is because the seller genuinely
has no use for them any more.

> Yes, it is clear and simple, but it is not sufficient.  If a 
> network has no incentive to go to the trouble of renumbering 
> out of IPv4 addresses, they won't return them, and there 
> won't be enough IPv4 addresses to meet the needs of those who 
> need more addresses. 

Since when is it our job to provide incentives to install NAT
or IPv6? People have been warned by the RIRs and ICANN that IPv4
is running out. There will be more warnings. Those who don't heed
the warnings will get what they deserve. IPv6 and IPv4 are amazingly 
flexible technologies and with the two to three years of advance
warning there is no need for anyone to suffer. If an organization
knows that they are absolutely dependent on IPv4 for some part
of their network where inflexible devices are attached, they should
begin now to make the rest of their network usable without IPv4.
In the worst case, where an org needs a steady supply of globally
unique IPv4 addresses, they can borrow a block like 126/8 by
ensuring that they filter out any route announcements from Softbank
Japan. Or similar with another /8.

It is not against the law to use IP addresses allocated to another
organization if you have no need to communicate with that other 
organization. If you talk to systems integrators you will learn that
this is common practice, not just in the enterprise, but you even run
across it inside telecom companies.

Running out of IPv4 addresses is not like hitting a brick wall.
It's more like colliding with a giant marshmallow and wondering how
to get out of the sticky mess.

--Michael Dillon


From BillD at cait.wustl.edu  Wed Feb 13 13:08:35 2008
From: BillD at cait.wustl.edu (Bill Darte)
Date: Wed, 13 Feb 2008 12:08:35 -0600
Subject: [ppml] IPv6 getting real: was Policy Proposal: IPv4 Transfer Policy
	Proposal
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail>
References: <NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net>	<47B12650.2060107@internap.com><D03E4899F2FB3D4C8464E8C76B3B68B001F2B4F7@E03MVC4-UKBR.domain1.systemhost.net><47B30DC8.5020907@internap.com>
	<70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D0308754B504@ex1.cait.wustl.edu>


> 
> There is no way we will be able to go IPv6 only until ALL of 
> the major content providers are IPv6 functional, and ALL of 
> the email providers are compliant.  Think of how you would 
> complain if your ISP went IPv6 and told you that you could 
> now email to "some" places..  or even "most"
> places.  
> 
> There are a lot of things that need to be functional before 
> IPv6 is a reality for ISP's..  little stuff like IPv6 RBL's, 
> bug free IPv6 VPN compatibility with ALL of the major VPN 
> hardware and software vendors,
> IPv6 connectivity for entertainment networks like Xbox Live 
> and PS3, gaming sites, IM protocols, and a host of other 
> applications that consumers rightfully demand.  Any one of 
> these "trivial" services not working is a deal killer for an 
> ISP converting to IPv6 only.  
> 
(Snip)
> 
> What tends to be forgotten, is that for the little guys IPv6 
> will not be a complete solution until EVERYTHING that is 
> available on IPv4 is also available on IPv6 and the use is 
> just as transparant to the end user.  
> 
> Kevin
> 


Thanks for this list of things that you feel must become 'real' before
there can be a significant adoption of IPv6 by the industry.

I would like to call for others to consider what among this listing of
things may NOT be a problem in your experience, and ALSO other serious
items that Kevin may have missed including applications.

I believe it is important to identify all the stumbling blocks (perhaps
as a checklist) that may exist so potential adopters can get a heads up
and importantly begin to apply leverage to their vendors for
support...in order to reduce the number of hurdles.

Or perhaps a comprehensive checklist already exists that I'm unaware
of... 

Finally, I'm interested in initiatives that you know exist or
could/should exist (open source projects, research needed, etc.) that
would help reduce these stumbling blocks.

It would be nice to consider what ARIN (beyond policy and within its
charter and mission) could support to promote adoption.

Bill Darte
ARIN AC


From sleibrand at internap.com  Wed Feb 13 13:36:25 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Wed, 13 Feb 2008 13:36:25 -0500
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail>
References: <NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net>	<47B12650.2060107@internap.com><D03E4899F2FB3D4C8464E8C76B3B68B001F2B4F7@E03MVC4-UKBR.domain1.systemhost.net>	<47B30DC8.5020907@internap.com>
	<70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail>
Message-ID: <47B338A9.4010500@internap.com>

Thanks for that perspective, Kevin.

Do you see a transfer policy like this one as necessary to maintain IPv4 
connectivity during the transition?  If not, how do you think ISPs like 
you will deal with the continued need for IPv4 addressing after free 
pool exhaustion?  If so, do you think that this proposed transfer policy 
strikes a good balance between providing the conditions for a liquid 
market and preventing unnecessary routing table growth and speculative 
market behavior?

Thanks,
Scott

Kevin Kargel wrote:
> Just to give some feedback FROM one the ISP's you are talking about..
> Our plan is to go dual stack as soon as ANY of our upstream providers
> can feed us dual stack.  We are already working on the enterprise dual
> stack routing, and have actually established an IPv6 tunnel connection
> (that I don't want to route real traffic over and abuse the network that
> was so kind as to let us connect).  Luckily, we use exclusively Cisco
> routing hardware, which has dual stack funtionality built in.  
>
> There is no way we will be able to go IPv6 only until ALL of the major
> content providers are IPv6 functional, and ALL of the email providers
> are compliant.  Think of how you would complain if your ISP went IPv6
> and told you that you could now email to "some" places..  or even "most"
> places.  
>
> There are a lot of things that need to be functional before IPv6 is a
> reality for ISP's..  little stuff like IPv6 RBL's, bug free IPv6 VPN
> compatibility with ALL of the major VPN hardware and software vendors,
> IPv6 connectivity for entertainment networks like Xbox Live and PS3,
> gaming sites, IM protocols, and a host of other applications that
> consumers rightfully demand.  Any one of these "trivial" services not
> working is a deal killer for an ISP converting to IPv6 only.  
>
> So whether or not it is more expensive, more work, or otherwise more
> painful, ISP's will be forced to maintain IPv4 connectivity until
> content there is obsoleted.
>
> What tends to be forgotten, is that for the little guys IPv6 will not be
> a complete solution until EVERYTHING that is available on IPv4 is also
> available on IPv6 and the use is just as transparant to the end user.  
>
> Kevin
>
>
>   
>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
>> Behalf Of Scott Leibrand
>> Sent: Wednesday, February 13, 2008 9:33 AM
>> To: michael.dillon at bt.com
>> Cc: ppml at arin.net
>> Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
>>
>> michael.dillon at bt.com wrote:
>>     
>>>> Yes.  There is a large installed base for whom migrating to
>>>> IPv6 may be painful (expensive).  Reducing the community's total 
>>>> expense for operating their IP networks is a benefit to 
>>>>         
>> the Internet 
>>     
>>>> community.
>>>>     
>>>>         
>>> RED HERRING!
>>>
>>> Given the fact that ISPs who implement IPv6 transit service 
>>>       
>> will also 
>>     
>>> have to implement transition mechanisms such as Teredo, 6to4, etc., 
>>> there is no imperative for any part of the installed base 
>>>       
>> to migrate 
>>     
>>> to IPv6 before they are ready.
>>>
>>> The imperative today is for those organizations with 
>>>       
>> steadily growing 
>>     
>>> networks at the heart of their business model (ISPs) to begin 
>>> transitioning. Whether it is painful or not, they must do it or die 
>>> because network growth is fundamental to their being.
>>>   
>>>       
>> I think you make an unjustified assumption that ISPs will be 
>> able to deploy IPv6-only service to new customers and operate 
>> transition mechanisms such as Teredo, 6to4, etc.
>>
>> An alternative, and IMO more likely, transition mechanism is 
>> to use two much more familiar technologies: dual stack and 
>> NAT.  Many consumer ISPs will be able to start providing IPv6 
>> support, provide the ability for their customers to 
>> dual-stack, and then start providing NAT'd RFC1918 addresses 
>> to their DHCP customers instead of public IPs.  This will be 
>> fairly easy for some ISPs, and more difficult for others 
>> (such as business ISPs, with more static-IP customers and 
>> smaller DHCP pools).  
>> In addition, there will be a great diversity of IPv6 support 
>> in middleboxes (home routers, enterprise firewalls, etc.)
>>
>> Given this diversity in cost of migrating to IPv6 
>> (dual-stack) and reducing IPv4 demand, there is an 
>> opportunity to allow organizations for whom the migration 
>> cost is higher to delay migration until IPv6 technology is 
>> better developed/deployed, and in the mean time get IPv4 
>> addresses from other organizations for whom the migration 
>> cost is lower.  Additionally, such a transfer policy would 
>> provide an incentive to encourage organizations to migrate 
>> their installed base to some form of IPv6 where it's easier 
>> to do so, rather than requiring growing networks to do so if 
>> it's more expensive for them.
>>
>>     
>>> If an ISP decided to try and avoid implementing IPv6 by getting
>>> IPv4 addresses from other sources, they are simply backing 
>>>       
>> themselves 
>>     
>>> into a corner and relying on their competitors to operate 
>>>       
>> transition 
>>     
>>> mechanisms for them. This is a risky strategy since the 
>>>       
>> market segment 
>>     
>>> who are willing to buy IPv4 network access will be steadily 
>>>       
>> shrinking. 
>>     
>>> In addition, their existing customers will begin to move 
>>>       
>> away because 
>>     
>>> the ISP is perceived as being incompetent and at risk of hitting a 
>>> brick wall.
>>>   
>>>       
>> I suspect that after ARIN free pool exhaustion, all ISPs will 
>> offer some form of IPv6 service.  To do so successfully, and 
>> support dual-stack, however, there will be a continued need 
>> for IPv4 addresses.  In some cases, a network may be able to 
>> free up enough IPv4 addresses to allow them to transfer them 
>> to other organizations.  In other cases, they'll be able to 
>> free up some, but not all, of their existing IPv4 addresses 
>> and use the remainder for growth.  In other cases, growth may 
>> overtake the ability of a network to cost-effectively reclaim 
>> IPv4 addresses (possibly due to a small install base), so 
>> continued availability of addresses from other organizations 
>> will be essential to avoiding much higher transition costs 
>> than are necessary.
>>
>>     
>>>   
>>>       
>>>>  This policy
>>>> proposal allows organizations to choose what's best for 
>>>>         
>> them, rather 
>>     
>>>> than forcing a one-size-fits-all solution.
>>>>     
>>>>         
>>> I disagree that this policy does what you say. In fact this 
>>>       
>> policy is 
>>     
>>> trying to set up a market for buying and selling IP addresses.
>>>   
>>>       
>> I don't think we're in disagreement here.  This policy 
>> proposal allows organizations to choose what's best for them 
>> by setting up a market for transferring IP addresses.  The 
>> addresses aren't property, so no one will be buying and 
>> selling the addresses themselves, but the underlying market 
>> economics will be similar.
>>     
>>> Under current policy, an ISP who migrates infrastructure to 
>>>       
>> IPv6 can 
>>     
>>> return their IPv4 addresses to ARIN. And an ISP who is not 
>>>       
>> migrating 
>>     
>>> can continue to apply to ARIN for more IPv4 addresses and 
>>>       
>> receive the 
>>     
>>> returned ones.
>>>
>>> This is clear and simple and easy to understand. It is the way that 
>>> IPv4 allocation has always been done and is fully understood by 
>>> everybody who deals with IP networking. Any new policy like the one 
>>> proposed, simply muddies the waters and creates confusion.
>>>   
>>>       
>> Yes, it is clear and simple, but it is not sufficient.  If a 
>> network has no incentive to go to the trouble of renumbering 
>> out of IPv4 addresses, they won't return them, and there 
>> won't be enough IPv4 addresses to meet the needs of those who 
>> need more addresses.  However, if the transfer process can 
>> cover the cost of renumbering, many more organizations will 
>> choose to do so.  To put it in basic economic terms, if we 
>> fix the price of scarce IPv4 addresses at zero (by leaving 
>> policy unchanged), supply will be insufficient to meet demand 
>> after the free pool is exhausted.  
>> If we allow price to be set by a market, the price will rise 
>> to the point where it increases supply and reduces demand 
>> enough to get them into balance.
>>
>> -Scott
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to 
>> the ARIN Public Policy Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml
>> Please contact the ARIN Member Services Help Desk at 
>> 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 (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues.
>   


From jaitken at aitken.com  Wed Feb 13 13:45:50 2008
From: jaitken at aitken.com (Jeff Aitken)
Date: Wed, 13 Feb 2008 18:45:50 +0000
Subject: [ppml] IPv6 getting real: was Policy Proposal: IPv4 Transfer
	Policy Proposal
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D0308754B504@ex1.cait.wustl.edu>
References: <NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net>
	<70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail>
	<EACF8B735E9CBA4B8BAF9E4165D0308754B504@ex1.cait.wustl.edu>
Message-ID: <20080213184550.GB64078@eagle.aitken.com>

On Wed, Feb 13, 2008 at 12:08:35PM -0600, Bill Darte wrote:
> I believe it is important to identify all the stumbling blocks (perhaps
> as a checklist) that may exist so potential adopters can get a heads up
> and importantly begin to apply leverage to their vendors for
> support...in order to reduce the number of hurdles.
> 
> Or perhaps a comprehensive checklist already exists that I'm unaware
> of... 

Hi Bill,

>From Randy's presentation in Albuquerque:

    http://www.civil-tongue.net/clusterf/

Is that what you were looking for?


--Jeff



From sleibrand at internap.com  Wed Feb 13 13:56:17 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Wed, 13 Feb 2008 13:56:17 -0500
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <D03E4899F2FB3D4C8464E8C76B3B68B001F2BED3@E03MVC4-UKBR.domain1.systemhost.net>
References: <NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net>	<47B12650.2060107@internap.com>	<D03E4899F2FB3D4C8464E8C76B3B68B001F2B4F7@E03MVC4-UKBR.domain1.systemhost.net>	<47B30DC8.5020907@internap.com>
	<D03E4899F2FB3D4C8464E8C76B3B68B001F2BED3@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <47B33D51.5020503@internap.com>

michael.dillon at bt.com wrote:
>
> I agree that there will be diverse scenarios playing out, but
> as I said, the pioneers of IPv6 deployment, not migration, wil
> be ISPs since network growth is at the core of their business
> model. This does not mean that they will be shrinking their
> IPv4 networks, and even if they do recover some IPv4 address
> space, there is no benefit to them to transfer it to someone
> else. In fact, the benefit to ISPs is to reuse those IPv4
> address to continue selling IPv4 services to the market segment
> which demands that.
>   

Of course there will be a benefit to transferring the IPv4 addresses to 
someone else: that someone else will pay you for them.  If they're 
willing to pay you more than you could make by continuing to sell IPv4 
services, you take the deal.  If not, someone else does.

> Given that this whole thing plays out at a time when there is
> a worldwide scarcity of IPv4 addresses, I can't see any reason
> for anyone to give up the IPv4 addresses that they have until
> they are absolutely sure that doing so does not risk serious
> business losses. That will take years after IANA runs out of
> IPv4 addresses.
>   

Is there a scarcity of land on Manhattan?  There certainly is a fixed 
pool of land there, which is fully utilized.  However, that doesn't stop 
developers from buying land and putting it to more productive use.  No 
one selling land on Manhattan is risking serious business losses, 
because they can lease or buy the land they need on the real estate market.

If, however, the transfer of land on Manhattan (or IPv4 addresses) were 
prohibited, then what you said would be very true.

> An then there is the technical issue of having a usable aggregate
> of IPv4 addresses to transfer and not scattered small blocks.
> An ISP has a number of ways of using scattered small blocks,
> including carrying many long prefixes in their iBGP, but in
> the global Internet, only large blocks/short prefixes are usable.
>   

Yes, which is why transferors will likely have an asking price high 
enough to fund the renumbering out of a block large enough to transfer.

>   
>> I suspect that after ARIN free pool exhaustion, all ISPs will 
>> offer some form of IPv6 service.  To do so successfully, and 
>> support dual-stack, however, there will be a continued need 
>> for IPv4 addresses.
>>     
>
> That's why I don't believe many ISPs will go to dual stack on
> any kind of scale. It is simpler to use MPLS with 6PE at the
> edge, or build an IPv6 mesh over GRE or PWE3 on an IPv4 core.
> This isolates the impact of IPv6 to the edge, and only to those
> edge routers which are needed for IPv6 services.
>   

You're missing my point.  It doesn't matter what the ISP does with their 
infrastructure: that's not the bulk of their addresses.  What matters is 
how they provide services to their customers, each of which needs IPv4 
and IPv6 addresses for decent interconnectivity.  I predict that many 
ISPs will offer their customers dual stack service at the edge, and that 
the IPv4 portion of that service will become a NAT'd private address in 
a lot of cases.

>
> As I have said in the past, you can't have a market without
> liquidity and a resource that is not only scarce, but has a 
> cap on supply, simply cannot provide that liquidity. I have
> no doubt that there will be a few sales of IP address blocks, 
> regardless of whether or not any RIR implements policies to
> allow it, but the prices will not follow a pattern, and
> will not be predictable. In general asking prices will be
> astronomically high, and some sales will actually take
> place at very high prices. But other sales will go through at
> a fraction of the asking price because the only reason the
> address block is on the market is because the seller genuinely
> has no use for them any more.
>   

It's possible that an IPv4 transfer market will be somewhat illiquid.  
That will certainly be true if it's a black market.  However, I think 
this proposed transfer policy moves us in the direction of improving the 
liquidity of the market, by legitimizing transfers and allowing a 
central listing service (order book) so that potential transferors and 
transferees can see prices and behave accordingly.  One such behavior, 
IMO, will be address holders freeing up additional addresses to transfer 
as a rising price makes it worth their while.  Therefore, I think the 
market created by this transfer policy would be sufficiently liquid to 
ensure a continued supply of IPv4 address resources at reasonable cost.

>> Yes, it is clear and simple, but it is not sufficient.  If a 
>> network has no incentive to go to the trouble of renumbering 
>> out of IPv4 addresses, they won't return them, and there 
>> won't be enough IPv4 addresses to meet the needs of those who 
>> need more addresses. 
>>     
>
> Since when is it our job to provide incentives to install NAT
> or IPv6? People have been warned by the RIRs and ICANN that IPv4
> is running out. There will be more warnings. Those who don't heed
> the warnings will get what they deserve. IPv6 and IPv4 are amazingly 
> flexible technologies and with the two to three years of advance
> warning there is no need for anyone to suffer. If an organization
> knows that they are absolutely dependent on IPv4 for some part
> of their network where inflexible devices are attached, they should
> begin now to make the rest of their network usable without IPv4.
>   

Our job is to provide responsible stewardship of Internet number 
resources.  In my opinion, denying organizations access to IPv4 
resources so they will "get what they deserve" is the antithesis of 
stewardship.  And don't forget that not all organizations who will need 
IPv4 resources in 2010 will have existing IPv4 assignments or 
allocations.  Any new business that wants to provide services to the 
general Internet will need to get IPv4 addresses: how do you propose we 
meet their needs?

> In the worst case, where an org needs a steady supply of globally
> unique IPv4 addresses, they can borrow a block like 126/8 by
> ensuring that they filter out any route announcements from Softbank
> Japan. Or similar with another /8.
>
> It is not against the law to use IP addresses allocated to another
> organization if you have no need to communicate with that other 
> organization. If you talk to systems integrators you will learn that
> this is common practice, not just in the enterprise, but you even run
> across it inside telecom companies.
>   

Ouch.  Do you really think such hacks are better than a policy allowing 
the transfer of IPv4 resources?  It seems to me we should be encouraging 
responsible behavior conducive to ensuring continued global uniqueness 
of uniquely assigned IPv4 addresses.

> Running out of IPv4 addresses is not like hitting a brick wall.
> It's more like colliding with a giant marshmallow and wondering how
> to get out of the sticky mess.
>   

And in this analogy this transfer policy is like a garden hose: an 
essential tool to allow everyone (not just those carrying water) to 
clean up the sticky mess.

-Scott


From BillD at cait.wustl.edu  Wed Feb 13 14:04:06 2008
From: BillD at cait.wustl.edu (Bill Darte)
Date: Wed, 13 Feb 2008 13:04:06 -0600
Subject: [ppml] IPv6 getting real: was Policy Proposal: IPv4
	TransferPolicy Proposal
In-Reply-To: <20080213184550.GB64078@eagle.aitken.com>
References: <NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net><70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail><EACF8B735E9CBA4B8BAF9E4165D0308754B504@ex1.cait.wustl.edu>
	<20080213184550.GB64078@eagle.aitken.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D0308754B507@ex1.cait.wustl.edu>

Thanks Jeff, knew one had to exist.
bd
 

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Jeff Aitken
> Sent: Wednesday, February 13, 2008 12:46 PM
> To: ppml at arin.net
> Subject: Re: [ppml] IPv6 getting real: was Policy Proposal: 
> IPv4 TransferPolicy Proposal
> 
> On Wed, Feb 13, 2008 at 12:08:35PM -0600, Bill Darte wrote:
> > I believe it is important to identify all the stumbling blocks 
> > (perhaps as a checklist) that may exist so potential 
> adopters can get 
> > a heads up and importantly begin to apply leverage to their vendors 
> > for support...in order to reduce the number of hurdles.
> > 
> > Or perhaps a comprehensive checklist already exists that 
> I'm unaware 
> > of...
> 
> Hi Bill,
> 
> >From Randy's presentation in Albuquerque:
> 
>     http://www.civil-tongue.net/clusterf/
> 
> Is that what you were looking for?
> 
> 
> --Jeff
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at 
> info at arin.net if you experience any issues.
> 


From andrew.dul at quark.net  Wed Feb 13 14:44:10 2008
From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=)
Date: Wed, 13 Feb 2008 11:44:10 -0800
Subject: [ppml] public policy proposal in network world
Message-ID: <20080213194410.7142.qmail@hoster908.com>

http://www.networkworld.com/news/2008/021308-ipv6-delay.html


From michael.dillon at bt.com  Wed Feb 13 14:47:10 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 13 Feb 2008 19:47:10 -0000
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <47B33D51.5020503@internap.com>
References: <NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net>	<47B12650.2060107@internap.com>	<D03E4899F2FB3D4C8464E8C76B3B68B001F2B4F7@E03MVC4-UKBR.domain1.systemhost.net>	<47B30DC8.5020907@internap.com>
	<D03E4899F2FB3D4C8464E8C76B3B68B001F2BED3@E03MVC4-UKBR.domain1.systemhost.net>
	<47B33D51.5020503@internap.com>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B001F2BF2F@E03MVC4-UKBR.domain1.systemhost.net>

> Is there a scarcity of land on Manhattan?  There certainly is 
> a fixed pool of land there, which is fully utilized.  
> However, that doesn't stop developers from buying land and 
> putting it to more productive use.  No one selling land on 
> Manhattan is risking serious business losses, because they 
> can lease or buy the land they need on the real estate market.

But there are many companies in Manhattan who are *NOT* selling
land because they can't afford to take the risk to their business
of not being in Manhattan. Sometimes events change the level of risk 
such as 9-11 making it clear to the financial services industry
that there was a lower risk if they moved SOME of their operations
away from Manhattan. But NYSE is still there and many companies 
stay in Manhattan to arbitrage the advantage of a few microseconds
less network latency to NYSE.

To date, nobody has show that there is any clear business advantage
for an ISP to stop selling IPv4 services if they have the resources
to do so. The IPv4 runout means that ISPs MUST begin offering IPv6
services, but if they can provide such a good transparent 4-to-6 and
6-to-4 Internet gateway service, that IPv4 customers begin to move
to pure v6 service, there is still no clear reason for the ISP to
NOT use those IPv4 addresses to sell service to customers who still
demand v4.

>  However, 
> I think this proposed transfer policy moves us in the 
> direction of improving the liquidity of the market, 

Moving from an extremely illiquid market to a very
illiquid market really doesn't change things. In either case
you will find it hard to sell IP addresses, hard to figure
out what price to ask, and hard to know if an offered price
is reasonable.

>  One such behavior, 
> IMO, will be address holders freeing up additional addresses 
> to transfer as a rising price makes it worth their while.  

How many hundred thousand dollars per /24 does the price have
to reach before it is worthwhile?

> Our job is to provide responsible stewardship of Internet 
> number resources.  In my opinion, denying organizations 
> access to IPv4 resources so they will "get what they deserve" 
> is the antithesis of stewardship.

You're right. We should be denying them access to IPv4
address blocks because we have run out of them. It's not
our fault that they are running out and we have essentially
zero influence on the decision makers that might return 
unused addresses to the pool, regardless of whether they
can earn 6 figures by doing so.

> Any new business that wants to provide services 
> to the general Internet will need to get IPv4 addresses: how 
> do you propose we meet their needs?

Now you are off in cloud cuckoo land. We need to start with
a basic understanding of the technology here. An IPv4 connected
host can communicate with an IPv6 connected host in the usual
way, through one or more intermediaries. In the IPv4 Internet
we call these intermediaries routers, load-balancers, NAT-boxes. 
Adding IPv6 to the mix also adds NAT-PT boxes, Teredo tunnel servers,
6to4 tunnel servers, tunnel brokers, ISATAP and ALGs (Application
Layer Gateways). These are all things that network operators 
provide for their customers whether in the enterprise or in the
telecom space. So it will be possible for IPv6-connected servers
to provide a service to the general Internet, as well as vice versa.

If an ISP can't make the Internet a basically seamless service,
regardless of IPv6 or IPv4, then they simply won't survive against
their more nimble competition. 

One thing that ARIN staff could do to help this process would be
to run a v6/v4  agnostic and fully transparent meeting network. By
this I mean that you should be able to bring a pure IPv4 laptop or
a pure IPv6 laptop to the meetings, and get equivalent service
including access to any v6 or v4 Internet sites. By fully transparent
I mean that all the technical details of how this service is
supplied should be on display for people to copy and adapt to 
their own networks. Yes, it would mean some development work
on NAT-PT and ALGs to finish the job so that they actually work
in the wild, but this is not an insurmountable task and it fits
in with ARIN's education mandate.

> > It is not against the law to use IP addresses allocated to another 
> > organization if you have no need to communicate with that other 
> > organization. If you talk to systems integrators you will 
> learn that 
> > this is common practice, not just in the enterprise, but 
> you even run 
> > across it inside telecom companies.
> 
> Ouch.  Do you really think such hacks are better than a 
> policy allowing the transfer of IPv4 resources?

Irrelevant. People have been doing this stuff for years and
will undoubtedly continue to do so regardless of what policies
ARIN may enact.

--Michael Dillon


From martin.hannigan at batelnet.bs  Wed Feb 13 15:17:58 2008
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Wed, 13 Feb 2008 15:17:58 -0500
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
Message-ID: <47b35076.179.10ad.4724@batelnet.bs>



> 
> Moving from an extremely illiquid market to a very
> illiquid market really doesn't change things. In either
> case you will find it hard to sell IP addresses, hard to
> figure out what price to ask, and hard to know if an
> offered price is reasonable.


This is wrong. Right now, a unit of IP addresses is worth
about $200,000 not including associated expenses.

-M<






From sleibrand at internap.com  Wed Feb 13 16:11:30 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Wed, 13 Feb 2008 16:11:30 -0500
Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
In-Reply-To: <D03E4899F2FB3D4C8464E8C76B3B68B001F2BF2F@E03MVC4-UKBR.domain1.systemhost.net>
References: <NABBJOELMNGNJNGPKDDOCEHDHFAA.tedm@ipinc.net>	<47B12650.2060107@internap.com>	<D03E4899F2FB3D4C8464E8C76B3B68B001F2B4F7@E03MVC4-UKBR.domain1.systemhost.net>	<47B30DC8.5020907@internap.com>	<D03E4899F2FB3D4C8464E8C76B3B68B001F2BED3@E03MVC4-UKBR.domain1.systemhost.net>	<47B33D51.5020503@internap.com>
	<D03E4899F2FB3D4C8464E8C76B3B68B001F2BF2F@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <47B35D02.4030206@internap.com>

michael.dillon at bt.com wrote:
>> Is there a scarcity of land on Manhattan?  There certainly is 
>> a fixed pool of land there, which is fully utilized.  
>> However, that doesn't stop developers from buying land and 
>> putting it to more productive use.  No one selling land on 
>> Manhattan is risking serious business losses, because they 
>> can lease or buy the land they need on the real estate market.
>>     
>
> But there are many companies in Manhattan who are *NOT* selling
> land because they can't afford to take the risk to their business
> of not being in Manhattan. Sometimes events change the level of risk 
> such as 9-11 making it clear to the financial services industry
> that there was a lower risk if they moved SOME of their operations
> away from Manhattan. But NYSE is still there and many companies 
> stay in Manhattan to arbitrage the advantage of a few microseconds
> less network latency to NYSE.
>   

Does that stop a new financial services firm from opening a Manhattan 
office, or a new employee of that firm from buying a Manhattan condo?  
An effective market does not require many/most asset holders be willing 
to sell, just enough to meet the demand at the market price.

> Moving from an extremely illiquid market to a very
> illiquid market really doesn't change things. In either case
> you will find it hard to sell IP addresses, hard to figure
> out what price to ask, and hard to know if an offered price
> is reasonable.
>   

I acknowledge that there is a risk of an IPv4 transfer market being 
insufficiently liquid to make a significant difference.  However, in 
that scenario, we're right back to the way things would be without this 
policy.

Do you foresee any risks of this policy making things worse, or do you 
just not think it will make things much better?

>>  One such behavior, 
>> IMO, will be address holders freeing up additional addresses 
>> to transfer as a rising price makes it worth their while.  
>>     
>
> How many hundred thousand dollars per /24 does the price have
> to reach before it is worthwhile?
>   

I think that can be calculated based on the cost of setting up NAT in 
your network, changing your DHCP pools to use private addresses, and the 
support costs of giving static public IPs to whatever percentage of your 
customers have problems due to NAT and want to opt out.  If this was 
done in the context of enabling IPv6, I would give a hand-wavy estimate 
that it would cost somewhere in the single-digit thousands of dollars to 
renumber a /24's worth of customers.  That would indicate that at a 
price of $20,000 per /24, significant supply would be available.  (In 
the initial period, I would expect the price to be much lower, as unused 
legacy space comes out of the woodwork.)  If we compare that with 
Marty's estimate of $200,000 on the current (black) market, that means 
that a liberalized transfer policy would be at least 10x better than the 
black market from the perspective of someone n