From fred at cisco.com  Thu Apr  1 01:34:27 2010
From: fred at cisco.com (Fred Baker)
Date: Wed, 31 Mar 2010 22:34:27 -0700
Subject: [arin-ppml] ULA-C
In-Reply-To: <i2q443de7ad1003312051k66d885b8l7b80b6efb64d688e@mail.gmail.com>
References: <014501cacc77$5573fe00$005bfa00$@net> <4BB20FA7.1020100@gmail.com>
	<54827055-3AFB-4510-9592-4B2DD47F3086@delong.com>
	<FC0A880B-AF14-477E-82B3-F2FE9EF3B256@cisco.com>
	<h2m443de7ad1003311736n89055be1wd3cfd334918a8d75@mail.gmail.com>
	<g2m443de7ad1003311740yc2fd9baaz3a3983a2b5bd7b6@mail.gmail.com>
	<4E376686-1540-433A-BC0B-26D1F5445D09@cisco.com>
	<i2q443de7ad1003312051k66d885b8l7b80b6efb64d688e@mail.gmail.com>
Message-ID: <76101A88-2A2E-4FB4-8264-E842F9B3D581@cisco.com>

well, OK. If they don't re-up, and continue using it, they risk your wrath. When they were validly signed up, you didn't exchange that route with them. Now that they are not validly signed up, you adamantly refuse to exchange that route with them.

And....?

On Mar 31, 2010, at 8:51 PM, Chris Grundemann wrote:

> On Wed, Mar 31, 2010 at 18:48, Fred Baker <fred at cisco.com> wrote:
>> well, you didn't answer my question, so maybe I shouldn't have to answer yours :-)
> 
> Fair enough - answer below. =)
> 
>> I have no problem with your statement in principle. I'm just wondering how you enforce it.
> 
> Annual renewal required of the registrant and annual
> registrant-data-verification required of the registry (whois poc
> verification or equivalent). Or, in the case of ULA-C, perhaps
> pentennial renewal and verification would be adequate and appropriate.
> 
> ...Or maybe annual for those blocks which the registry is providing
> reverse DNS and pentennial for those with no service beyond basic
> registration.
> 
>>>> On Mar 31, 2010 6:17 PM, "Fred Baker" <fred at cisco.com> queried:
>>>> If you give a prefix to your favorite admin and have them number their network with it, and then re-assign the prefix to someone else, what's the probability that you have a collision?
> 
> Much greater than if you don't re-assign it. ;-)
> 
>>>> I think you need to accept that once put into use, a ULA will be in use by that administration permanently. You obviously see otherwise.  Fill me in?
> 
> See my previous statements regarding the impermanence of organizations
> and their networks.
> 
> ~Chris
> 
> 
> 
> --
> @ChrisGrundemann
> weblog.chrisgrundemann.com
> www.burningwiththebush.com
> www.coisoc.org

http://www.ipinc.net/IPv4.GIF



From alain_durand at cable.comcast.com  Thu Apr  1 09:17:30 2010
From: alain_durand at cable.comcast.com (Durand, Alain)
Date: Thu, 01 Apr 2010 09:17:30 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <4BE237E0-147E-4F48-883E-052A2136898B@cisco.com>
Message-ID: <C7DA152A.38CF1%alain_durand@cable.comcast.com>

So here we are, re-hashing the discussion from a couple years ago...

To answer Fred's point bellow, the issue is that nothing prevents those ULAs
to be routed on the Internet. It is essentially a matter of how much an
organization is willing to pay its service provider to announce the prefix.

This is more likely to happen with centrally registered prefixes (guaranteed
unique) rather than with self-originated, randomly generated ones.

    - Alain.

On 3/31/10 8:46 PM, "Fred Baker" <fred at cisco.com> wrote:

> well, question. Do you need whois and all that for a local address? We don't
> use them for RFC 1918 addresses...
> 
> If they were global addresses, I'd be right there with you. But a ULA is used
> by your favorite IT department and is not normally shared with very many other
> organizations. It seems like the response to "whois" should be "your IT
> department".



From mcr at sandelman.ca  Thu Apr  1 09:41:19 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Thu, 01 Apr 2010 09:41:19 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <4BE237E0-147E-4F48-883E-052A2136898B@cisco.com> 
References: <014501cacc77$5573fe00$005bfa00$@net> <4BB20FA7.1020100@gmail.com>
	<54827055-3AFB-4510-9592-4B2DD47F3086@delong.com>
	<FC0A880B-AF14-477E-82B3-F2FE9EF3B256@cisco.com>
	<4BB3E8F4.2010403@gmail.com>
	<4BE237E0-147E-4F48-883E-052A2136898B@cisco.com> 
Message-ID: <9575.1270129279@marajade.sandelman.ca>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Fred" == Fred Baker <fred at cisco.com> writes:
    Fred> well, question. Do you need whois and all that for a local
    Fred> address? We don't use them for RFC 1918 addresses...

Whois and reverse DNS is the major reason, in my opinion, for ULA-C.
If ULA-C hasn't got that, then it's just ULA-R with a much lower
probability of non-collision.

Why is whois and reverse DNS useful? 

Whois, because it lets you identify who is leaking.
Reverse DNS because it means that organizations do not need to concern
themselves so much with split-DNS.   Without reverse DNS, IPv6 is really
hard to cope with in my experience.

Split-DNS was easy when enterprises were completely convex, but thanks
to our success, IP is everywhere, and many devices are "inside" some of
the time.

    Fred> On the other hand, I could imagine an allocation "policy" that
    Fred> consists of a web page (not my idea originally, it comes from
    Fred> Brian Carpenter). The web page has some variation on a
    Fred> counter, perhaps using a pseudo-random number generator or a
    Fred> cyclic feedback shift register to spread the numbers all
    Fred> over. When a site accesses the web page, they get a prefix,
    Fred> and the next person that accesses the web page gets the "next"
    Fred> prefix. Next question is who runs the web page; could be IANA,
    Fred> your favorite RIR, or anyone else the community deemed
    Fred> suitable. Along with that, I could imagine the person
    Fred> allocating the prefix having to provide some information, and
    Fred> some checks and balances to limit the probability of
    Fred> issues. The checks and balances would require discussion. They
    Fred> might include a name, address, and email address.

Yes, we can do this.
It has already been done for ULA-R by sixxs:
   
  http://www.sixxs.net/tools/grh/ula/

If IANA were to delegate the reverse to sixxs, well, we'd be pretty much
done, as far as I'm concerned.

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEUAwUBS7SifoCLcPvd0N1lAQKFhQf4xTDdNMztRBUx9M9rDKx+jBk+YSXZgxoI
+52SZ4c+83Rg+VwoBCWYQhhZu/3Apfpi84wg/QvR1kbh5CRBvv61G2zE5X6cvLHY
g4RQxd5P7yIThAgXwUTyJLEj1tWWeHp+No1N3WeIdn0G/PIEj33pNkHD0GtvQYCE
BoLugeBQ7Oz4qsbUmtgzlG1AF3BFp7ZCq2EhU+3+Ztp3Aibh3mKpBQq5K13Hp0mD
sWpHmDvDUsvwFhwgXz1RKsM+5WY+AahnBMsNGzNgSgdIdYLVaVIcommAIQCoqYUf
IFOKZn5fnqWMnNpcSJvCXlD+nvB5c05yqvPmRzVqdUNTlEbALhjd
=05VX
-----END PGP SIGNATURE-----


From michael.dillon at bt.com  Thu Apr  1 09:58:05 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 1 Apr 2010 14:58:05 +0100
Subject: [arin-ppml] ULA-C
In-Reply-To: <C7DA152A.38CF1%alain_durand@cable.comcast.com>
Message-ID: <28E139F46D45AF49A31950F88C49745805AF0188@E03MVZ2-UKDY.domain1.systemhost.net>

> To answer Fred's point bellow, the issue is that nothing 
> prevents those ULAs to be routed on the Internet. 

WRONG!

Filters and ACLs prevent those ULA addresses from being routed
to the Internet, but these are technical measures and they
can be misconfigured, as they often are in the case of
RFC 1918 addresses. ULA-C offers us the opportunity to record
the registrant of each block in a central directory and when
someone encounters packets with ULA-C addresses, they can
find out where they are coming from and more easily get the
problem fixed.

> It is 
> essentially a matter of how much an organization is willing 
> to pay its service provider to announce the prefix.

Show me some evidence. You can black out the supplier's name
and the amount, but I want to see a copy of a signed contract
from any ISP, anywhere, that has agreed to announce an RFC 1918
prefix. Without such evidence, I simply do not believe that 
what you say is possible.

-- Michael Dillon


From alain_durand at cable.comcast.com  Thu Apr  1 11:09:47 2010
From: alain_durand at cable.comcast.com (Durand, Alain)
Date: Thu, 01 Apr 2010 11:09:47 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <28E139F46D45AF49A31950F88C49745805AF0188@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <C7DA2F7B.38D15%alain_durand@cable.comcast.com>

The IPv4 parallel to draw is not with RFC1918 (it is meaningless to
advertize net10 because it is not unique), but with long prefixes in IPv4.
How many /24s in your routing table? Or longer?

   - Alain.

On 4/1/10 9:58 AM, "michael.dillon at bt.com" <michael.dillon at bt.com> wrote:

>> To answer Fred's point bellow, the issue is that nothing
>> prevents those ULAs to be routed on the Internet.
> 
> WRONG!
> 
> Filters and ACLs prevent those ULA addresses from being routed
> to the Internet, but these are technical measures and they
> can be misconfigured, as they often are in the case of
> RFC 1918 addresses. ULA-C offers us the opportunity to record
> the registrant of each block in a central directory and when
> someone encounters packets with ULA-C addresses, they can
> find out where they are coming from and more easily get the
> problem fixed.
> 
>> It is 
>> essentially a matter of how much an organization is willing
>> to pay its service provider to announce the prefix.
> 
> Show me some evidence. You can black out the supplier's name
> and the amount, but I want to see a copy of a signed contract
> from any ISP, anywhere, that has agreed to announce an RFC 1918
> prefix. Without such evidence, I simply do not believe that
> what you say is possible.
> 
> -- Michael Dillon
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From kkargel at polartel.com  Thu Apr  1 12:23:24 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 1 Apr 2010 11:23:24 -0500
Subject: [arin-ppml] ULA-C
In-Reply-To: <68D14357-C52A-4790-A14E-5026D37A495F@delong.com>
References: <014501cacc77$5573fe00$005bfa00$@net> <4BB20FA7.1020100@gmail.com>
	<54827055-3AFB-4510-9592-4B2DD47F3086@delong.com>
	<4BB2BF86.8000000@ibctech.ca>
	<8695009A81378E48879980039EEDAD28876D43D1@MAIL1.polartel.local>
	<68D14357-C52A-4790-A14E-5026D37A495F@delong.com>
Message-ID: <8695009A81378E48879980039EEDAD28876D43F0@MAIL1.polartel.local>

> > I concur that renewal is necessary, though renewal requirements do not
> necessarily need to include money, data refresh could be sufficient.
> >
> > Kevin
> 
> I disagree. Without fees, data-refresh is often responded to out of rote
> without thought or consideration.
> 
> Owen
In this instance I think rote would be sufficient.  The main objective being a live person ping to test that the organization is live and present.  To my understanding the thing we want to make sure of is that the network has not been abandoned.  

Kevin


From farmer at umn.edu  Thu Apr  1 12:41:36 2010
From: farmer at umn.edu (David Farmer)
Date: Thu, 01 Apr 2010 11:41:36 -0500
Subject: [arin-ppml] ULA-C
In-Reply-To: <8695009A81378E48879980039EEDAD28876D43F0@MAIL1.polartel.local>
References: <014501cacc77$5573fe00$005bfa00$@net>
	<4BB20FA7.1020100@gmail.com>	<54827055-3AFB-4510-9592-4B2DD47F3086@delong.com>	<4BB2BF86.8000000@ibctech.ca>	<8695009A81378E48879980039EEDAD28876D43D1@MAIL1.polartel.local>	<68D14357-C52A-4790-A14E-5026D37A495F@delong.com>
	<8695009A81378E48879980039EEDAD28876D43F0@MAIL1.polartel.local>
Message-ID: <4BB4CCC0.7050005@umn.edu>

Kevin Kargel wrote:
>>> I concur that renewal is necessary, though renewal requirements do not
>> necessarily need to include money, data refresh could be sufficient.
>>> Kevin
>> I disagree. Without fees, data-refresh is often responded to out of rote
>> without thought or consideration.
>>
>> Owen
> In this instance I think rote would be sufficient.  The main objective being a live person ping to test that the organization is live and present.  To my understanding the thing we want to make sure of is that the network has not been abandoned.  

I believe what ever the policy is it should be the same as for PI 
assignments.

A fundamental tenant of the consensus that I think is developing is if 
the policy for PI and ULA-C are essentially the same, then ULA-C can be 
implemented without much risk of abuse.  If ULA-C is easier to get or 
maintain, or even if it is only perceived as such, there is a risk of 
abuse.


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


From cgrundemann at gmail.com  Thu Apr  1 13:00:13 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Thu, 1 Apr 2010 11:00:13 -0600
Subject: [arin-ppml] ULA-C
In-Reply-To: <76101A88-2A2E-4FB4-8264-E842F9B3D581@cisco.com>
References: <014501cacc77$5573fe00$005bfa00$@net> <4BB20FA7.1020100@gmail.com>
	<54827055-3AFB-4510-9592-4B2DD47F3086@delong.com>
	<FC0A880B-AF14-477E-82B3-F2FE9EF3B256@cisco.com>
	<h2m443de7ad1003311736n89055be1wd3cfd334918a8d75@mail.gmail.com>
	<g2m443de7ad1003311740yc2fd9baaz3a3983a2b5bd7b6@mail.gmail.com>
	<4E376686-1540-433A-BC0B-26D1F5445D09@cisco.com>
	<i2q443de7ad1003312051k66d885b8l7b80b6efb64d688e@mail.gmail.com>
	<76101A88-2A2E-4FB4-8264-E842F9B3D581@cisco.com>
Message-ID: <g2j443de7ad1004011000y9956e8c0w16ed7233f31d5a36@mail.gmail.com>

On Wed, Mar 31, 2010 at 23:34, Fred Baker <fred at cisco.com> wrote:
> well, OK. If they don't re-up, and continue using it, they risk your wrath. When they were validly signed up, you didn't exchange that route with them. Now that they are not validly signed up, you adamantly refuse to exchange that route with them.
>
> And....?
>

And... this is exactly why we have ARIN and why we pay them.

If the Org doesn't renew (re-up) then it is the registries duty to
determine if they have refused or if they have ceased to exist (or
just don't need the IPs anymore).

By not renewing, the Org runs the risk of no longer having a unique
block of ULA-C and they lose reverse DNS (and any other) services on
said block. This is likely reason enough to keep re-upping as long as
they keep using the IPs (assuming that the process is not overly
onerous).

Another point to consider is that most organizations will likely have
ULA-C AND IPv4 and/or GUA and/or an AS. Assuming that the ULA-C is not
their only resource, the renewal (re-up) process should be a single
touch for all resources - another reason that a functioning Org which
is using the space assigned is unlikely to stop renewing.

And finally, if the Org in question really has only one block of ULA-C
and they stop renewing; then the registry (ARIN) is responsible to
track the Org down and determine if the block can be reclaimed for
some other Org to use.

Plus they get my wrath.

~Chris

>
> http://www.ipinc.net/IPv4.GIF
>
>

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From mcr at sandelman.ca  Thu Apr  1 15:05:03 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Thu, 01 Apr 2010 15:05:03 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <C7DA2F7B.38D15%alain_durand@cable.comcast.com> 
References: <C7DA2F7B.38D15%alain_durand@cable.comcast.com> 
Message-ID: <1443.1270148703@marajade.sandelman.ca>


>>>>> "Alain" == Alain Durand <Durand> writes:
    Alain> The IPv4 parallel to draw is not with RFC1918 (it is
    Alain> meaningless to advertize net10 because it is not unique), but
    Alain> with long prefixes in IPv4.  How many /24s in your routing
    Alain> table? Or longer?

So what?
Show me the IETF or ARIN or RIPE or ... policy that says that they
shouldn't be announced? 

(I'm irked when I see /24s without covering aggregate announcements, and
I could, I'd filter them, and I have done so when I had such powers)

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


From joelja at bogus.com  Thu Apr  1 15:19:38 2010
From: joelja at bogus.com (Joel Jaeggli)
Date: Thu, 01 Apr 2010 12:19:38 -0700
Subject: [arin-ppml] ULA-C
In-Reply-To: <1443.1270148703@marajade.sandelman.ca>
References: <C7DA2F7B.38D15%alain_durand@cable.comcast.com>
	<1443.1270148703@marajade.sandelman.ca>
Message-ID: <4BB4F1CA.4030803@bogus.com>



On 04/01/2010 12:05 PM, Michael Richardson wrote:
> 
>>>>>> "Alain" == Alain Durand <Durand> writes:
>     Alain> The IPv4 parallel to draw is not with RFC1918 (it is
>     Alain> meaningless to advertize net10 because it is not unique), but
>     Alain> with long prefixes in IPv4.  How many /24s in your routingb
>     Alain> table? Or longer?
> 
> So what?
> Show me the IETF or ARIN or RIPE or ... policy that says that they
> shouldn't be announced? 

More to the point there are direct analogies betwen the class-c swamp
and the concerns expressed about the potential for unique assignments to
be advertised at some point in the future. fwiw we do advertise our
swamp space in an aggregated fashion because it's possible to do...

The swamp almost broke the internet the last time around...

> (I'm irked when I see /24s without covering aggregate announcements, and
> I could, I'd filter them, and I have done so when I had such powers)
> 


From farmer at umn.edu  Thu Apr  1 15:51:53 2010
From: farmer at umn.edu (David Farmer)
Date: Thu, 01 Apr 2010 14:51:53 -0500
Subject: [arin-ppml] ULA-C
In-Reply-To: <4BB4F1CA.4030803@bogus.com>
References: <C7DA2F7B.38D15%alain_durand@cable.comcast.com>	<1443.1270148703@marajade.sandelman.ca>
	<4BB4F1CA.4030803@bogus.com>
Message-ID: <4BB4F959.4020701@umn.edu>

Joel Jaeggli wrote:
> 
> On 04/01/2010 12:05 PM, Michael Richardson wrote:
>>>>>>> "Alain" == Alain Durand <Durand> writes:
>>     Alain> The IPv4 parallel to draw is not with RFC1918 (it is
>>     Alain> meaningless to advertize net10 because it is not unique), but
>>     Alain> with long prefixes in IPv4.  How many /24s in your routingb
>>     Alain> table? Or longer?
>>
>> So what?
>> Show me the IETF or ARIN or RIPE or ... policy that says that they
>> shouldn't be announced? 
> 
> More to the point there are direct analogies betwen the class-c swamp
> and the concerns expressed about the potential for unique assignments to
> be advertised at some point in the future. fwiw we do advertise our
> swamp space in an aggregated fashion because it's possible to do...
> 
> The swamp almost broke the internet the last time around...

Is this an issue of ULA-C or PI, I see more of an analogy between the 
swamp and PI, and lest in the fact of lots of unaggregatable routes. 
For a majority of the ISPs ULA or ULA-C can be filtered with a single 
policy statement and have a covering aggregate point at null.

One of the reasons that I believe the RIRs need to be involved in and 
control the policy under which ULA-C is given out is to impose good 
stewardship on the ULA-C resources.  This should help avoid the other 
problem of the swamp, lots of stale or even rotted POC and assignment 
information.

If you are going to have a registry it needs to be properly maintained, 
that cost at least some money and if you doing want to pay for that then 
use ULA-L.  And, this is not just a one-time payment, it costs money to 
maintain the registry over time too.

Further, the costs of maintaining a registry for PI or ULA-C are 
probably not going to be significantly different, you are doing most of 
the same things.

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


From kkargel at polartel.com  Thu Apr  1 16:12:48 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 1 Apr 2010 15:12:48 -0500
Subject: [arin-ppml] ULA-C
In-Reply-To: <4BB4CCC0.7050005@umn.edu>
References: <014501cacc77$5573fe00$005bfa00$@net> <4BB20FA7.1020100@gmail.com>
	<54827055-3AFB-4510-9592-4B2DD47F3086@delong.com>
	<4BB2BF86.8000000@ibctech.ca>
	<8695009A81378E48879980039EEDAD28876D43D1@MAIL1.polartel.local>
	<68D14357-C52A-4790-A14E-5026D37A495F@delong.com>
	<8695009A81378E48879980039EEDAD28876D43F0@MAIL1.polartel.local>
	<4BB4CCC0.7050005@umn.edu>
Message-ID: <8695009A81378E48879980039EEDAD28876D43F3@MAIL1.polartel.local>

> I believe what ever the policy is it should be the same as for PI
> assignments.
> 
> A fundamental tenant of the consensus that I think is developing is if
> the policy for PI and ULA-C are essentially the same, then ULA-C can be
> implemented without much risk of abuse.  If ULA-C is easier to get or
> maintain, or even if it is only perceived as such, there is a risk of
> abuse.
> 
> 
I will buy in to that. 

On a global level I can see that if many people want ULA-C I guess it won't hurt anything so long as it doesn't start finding it's way to the global routing table.  Even if it shows up in local peer routing tables it is pretty benign.

The danger I see with ULA peer relationships is that if I advertise my ULA-* to a peer for private uses I have no control over my peers BGP policies and they may through design or neglect advertise my ULA to their peers, which would/could pollute the global table.  This could get *me* in trouble through no fault of my own.  

On a local (personal)level I just don't see the need for dedicated ULA pools when anyone can roll their own ULA-* out of their GUA.  

My interpretation is that ULA-ish GUA consumption would count toward utilization requirements, so it would not handicap further allocation requests.  Perhaps I am wrong on this one.

Kevin


From farmer at umn.edu  Thu Apr  1 18:09:30 2010
From: farmer at umn.edu (David Farmer)
Date: Thu, 01 Apr 2010 17:09:30 -0500
Subject: [arin-ppml] ULA-C
In-Reply-To: <8695009A81378E48879980039EEDAD28876D43F3@MAIL1.polartel.local>
References: <014501cacc77$5573fe00$005bfa00$@net>
	<4BB20FA7.1020100@gmail.com>	<54827055-3AFB-4510-9592-4B2DD47F3086@delong.com>	<4BB2BF86.8000000@ibctech.ca>	<8695009A81378E48879980039EEDAD28876D43D1@MAIL1.polartel.local>	<68D14357-C52A-4790-A14E-5026D37A495F@delong.com>
	<8695009A81378E48879980039EEDAD28876D43F0@MAIL1.polartel.local>
	<4BB4CCC0.7050005@umn.edu>
	<8695009A81378E48879980039EEDAD28876D43F3@MAIL1.polartel.local>
Message-ID: <4BB5199A.5040506@umn.edu>

Kevin Kargel wrote:
> The danger I see with ULA peer relationships is that if I advertise my ULA-* to a peer for private uses I have no control over my peers BGP policies and they may through design or neglect advertise my ULA to their peers, which would/could pollute the global table.  This could get *me* in trouble through no fault of my own.  

You are right you don't have ultimate control of this issue, your peer 
does, and their other peer has control over what they accept.  This is 
not that much different the GUA though.  Yes, since your peer's, peer's, 
peer is not seeing your ULA route in the global table it is more likely 
they will believe the route, if they are not filtering ULA.

However, you can at least try to help you peer do the right thing and 
add the well-known community "no-export" when sending any routes you 
don't want your peer to announce to anyone else.  They can alway strip 
the community off and do what ever they want but it would help prevent 
them from accidentally announcing it to someone else.

Even with that there is no substitute for good peering practices.

> On a local (personal)level I just don't see the need for dedicated ULA pools when anyone can roll their own ULA-* out of their GUA.  

As I said my local (personal) reasons for wanting this are not 
technical, they are political and to allow me to appease others, both 
within my large organization and at numerous business partners all over 
the world.

> My interpretation is that ULA-ish GUA consumption would count toward utilization requirements, so it would not handicap further allocation requests.  Perhaps I am wrong on this one.

Good question, I do not thinking there should be such thing as PA ULA-C, 
in other words as a provider you don't get a ULA-C allocation and give 
some to your customer.  If your customer wants ULA-C they get it from an 
RIR.  You as a provider could get ULA-C for your internal use only, 
sized appropriately for your network infrastructure.

For a end-user they could get ULA-C equivalent to what they would 
qualify for PI.  An example, if an end-user qualified for a /46 of PI 
they could get a /46 of ULA-C.  In fact I believe they should be able to 
have both at the same time.

Further, it is entirely possible from a policy point of view for a 
end-user site to have a PI /46, a ULA /46, a PA /46 assigned from a 
provider, additional PA /46s from any number of providers, and be 
completely justified.  And, each of those prefixes could have an RA on 
every one of the subnets within the end-users network.  I'm not sure how 
the hosts are going to know how to select the right prefix to use, but 
that is not an number resource policy question, that is an operational 
one. From a policy point of view this should be valid.

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


From mcr at sandelman.ca  Thu Apr  1 21:04:45 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Thu, 01 Apr 2010 21:04:45 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <8695009A81378E48879980039EEDAD28876D43F3@MAIL1.polartel.local> 
References: <014501cacc77$5573fe00$005bfa00$@net> <4BB20FA7.1020100@gmail.com>
	<54827055-3AFB-4510-9592-4B2DD47F3086@delong.com>
	<4BB2BF86.8000000@ibctech.ca>
	<8695009A81378E48879980039EEDAD28876D43D1@MAIL1.polartel.local>
	<68D14357-C52A-4790-A14E-5026D37A495F@delong.com>
	<8695009A81378E48879980039EEDAD28876D43F0@MAIL1.polartel.local>
	<4BB4CCC0.7050005@umn.edu>
	<8695009A81378E48879980039EEDAD28876D43F3@MAIL1.polartel.local>
Message-ID: <16249.1270170285@marajade.sandelman.ca>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Kevin" == Kevin Kargel <kkargel at polartel.com> writes:
    >> I believe what ever the policy is it should be the same as for PI
    >> assignments.
    >> 
    >> A fundamental tenant of the consensus that I think is developing
    >> is if the policy for PI and ULA-C are essentially the same, then
    >> ULA-C can be implemented without much risk of abuse.  If ULA-C is
    >> easier to get or maintain, or even if it is only perceived as
    >> such, there is a risk of abuse.
    >> 
    >> 
    Kevin> I will buy in to that.

    Kevin> On a global level I can see that if many people want ULA-C I
    Kevin> guess it won't hurt anything so long as it doesn't start
    Kevin> finding it's way to the global routing table.  Even if it
    Kevin> shows up in local peer routing tables it is pretty benign.

    Kevin> The danger I see with ULA peer relationships is that if I
    Kevin> advertise my ULA-* to a peer for private uses I have no
    Kevin> control over my peers BGP policies and they may through
    Kevin> design or neglect advertise my ULA to their peers, which
    Kevin> would/could pollute the global table.  This could get *me* in
    Kevin> trouble through no fault of my own.

So, that's why we need ULA-C, rather than "tainted GUA".

The ULA-C will *not* leak into the global routing table, because there
will be lots and lots of filters that reject it.

    Kevin> On a local (personal)level I just don't see the need for
    Kevin> dedicated ULA pools when anyone can roll their own ULA-* out
    Kevin> of their GUA.

Sure.  Show me again, where the 20-person operation that have a cable
connection, and a DSL connection (and thus two sets of GUA-PA), get this
GUA-PI that they need to have stable addresses internally?
Said company has two different types of connections because neither is
reliable enough.

ULA-C is not about ISPs. It's about SME.

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS7VCqoCLcPvd0N1lAQKfMggAqPLdf9Xt1gPa2H+UrWZXReNkKCLzkE7X
AFnJNub+TUhFTViHfYiF8CiHjM3I6+XP5o8vztkVmMfDi6h9oD8IFw8+wqTBfSb4
+6ewawDWlTlTV6Uxn3Hq0pg2p/WltJvkLGs5Fy9MXjKd8dfxZPhrTbFOY0+zSUYR
kR/DmlupONzPHP522JNySRrxDPG3t9YRm5+B5FC32ljUX2gNbUDManaUHRHYQhdy
/1WxqdcrhmS217OEgtUcqkisc0mER/HxTdksbCw8UltXbwtG2hLAo2eiAeb2L6aS
I2QFkWT1jwaB+IU0FXgGzhgCYbqwE0Jqr371sHWssPbr4/aL5FZH5A==
=dlfF
-----END PGP SIGNATURE-----


From owen at delong.com  Thu Apr  1 17:38:10 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 1 Apr 2010 14:38:10 -0700
Subject: [arin-ppml] ULA-C
In-Reply-To: <8695009A81378E48879980039EEDAD28876D43F0@MAIL1.polartel.local>
References: <014501cacc77$5573fe00$005bfa00$@net> <4BB20FA7.1020100@gmail.com>
	<54827055-3AFB-4510-9592-4B2DD47F3086@delong.com>
	<4BB2BF86.8000000@ibctech.ca>
	<8695009A81378E48879980039EEDAD28876D43D1@MAIL1.polartel.local>
	<68D14357-C52A-4790-A14E-5026D37A495F@delong.com>
	<8695009A81378E48879980039EEDAD28876D43F0@MAIL1.polartel.local>
Message-ID: <B5B24327-213D-4BB5-A0CE-1BC7F4B22329@delong.com>


On Apr 1, 2010, at 9:23 AM, Kevin Kargel wrote:

>>> I concur that renewal is necessary, though renewal requirements do not
>> necessarily need to include money, data refresh could be sufficient.
>>> 
>>> Kevin
>> 
>> I disagree. Without fees, data-refresh is often responded to out of rote
>> without thought or consideration.
>> 
>> Owen
> In this instance I think rote would be sufficient.  The main objective being a live person ping to test that the organization is live and present.  To my understanding the thing we want to make sure of is that the network has not been abandoned.  
> 
> Kevin

I'd rather actually make sure the resources are still in active use for something someone considers a useful purpose. A fee which also helps defray the costs of those annual pings and records maintenance is not a bad idea. Otherwise, someone somewhere is subsidizing all that ULA registration. I don't see any reason ULA shouldn't pay its own way.

Owen



From info at arin.net  Fri Apr  2 12:08:45 2010
From: info at arin.net (Member Services)
Date: Fri, 02 Apr 2010 12:08:45 -0400
Subject: [arin-ppml] ARIN XXV Open Policy Hour
Message-ID: <4BB6168D.8080007@arin.net>

Sign up today to present your ideas at the ARIN XXV Open Policy Hour, 
Sunday, 18 April, from 5:00-6:00 PM (EDT).

The Open Policy Hour (OPH) is a showcase for new policy ideas, and we 
want to hear from you. Sign up before Friday, 16 April to guarantee your 
chance at the microphone. Everyone is invited to attend the session and 
raise ideas and suggestions. You do not need to have a formal 
presentation in order to participate. Signing up in advance allows us to 
confirm your turn to present your policy idea, but is not required.

Part One - Draft Policy Background Briefing: ARIN staff provides summary 
information regarding the draft policies up for discussion at the 
meeting. Advisory Council representatives answer general questions about 
the draft policies. The intent is to increase understanding of the 
nature of the proposals, not to discuss the pros or cons of the draft 
policies.

Part Two - Policy Proposal BoF: If you have a policy suggestion for 
which you would like to receive feedback prior to formally submitting it 
to the community, here is your opportunity. You?ll be given a few 
minutes to present your idea before other attendees are invited to 
comment. To sign up to give a presentation, please send an e-mail to 
policy at arin.net by 16 April 2010 with your name, organization, and a 
brief description of your policy subject.

More details are available at: https://www.arin.net/ARIN-XXV/.

If you won?t be with us in Toronto, we are offering remote participation 
during the Open Policy Hour, and throughout the Public Policy and 
Members Meeting. Get all the details and register as a remote 
participant at https://www.arin.net/ARIN-XXV/remote.html.

We look forward to your participation in ARIN XXV.

Please contact Member Services at info at arin.net if you have any questions.

Regards,

Member Services

American Registry for Internet Numbers (ARIN)





From kkargel at polartel.com  Fri Apr  2 14:03:14 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Fri, 2 Apr 2010 13:03:14 -0500
Subject: [arin-ppml] ULA-C
In-Reply-To: <16249.1270170285@marajade.sandelman.ca>
References: <014501cacc77$5573fe00$005bfa00$@net> <4BB20FA7.1020100@gmail.com>
	<54827055-3AFB-4510-9592-4B2DD47F3086@delong.com>
	<4BB2BF86.8000000@ibctech.ca>
	<8695009A81378E48879980039EEDAD28876D43D1@MAIL1.polartel.local>
	<68D14357-C52A-4790-A14E-5026D37A495F@delong.com>
	<8695009A81378E48879980039EEDAD28876D43F0@MAIL1.polartel.local>
	<4BB4CCC0.7050005@umn.edu>
	<8695009A81378E48879980039EEDAD28876D43F3@MAIL1.polartel.local>
	<16249.1270170285@marajade.sandelman.ca>
Message-ID: <8695009A81378E48879980039EEDAD28876D43FA@MAIL1.polartel.local>


> Sure.  Show me again, where the 20-person operation that have a cable
> connection, and a DSL connection (and thus two sets of GUA-PA), get this
> GUA-PI that they need to have stable addresses internally?
> Said company has two different types of connections because neither is
> reliable enough.
> 
> ULA-C is not about ISPs. It's about SME.
> 
So you are telling me that as an ISP I will need to make special routes for each and every DSL customer that has two xSL connections?  

Why doesn't that customer just get his own GUA if this is so important to his business?


From bill at herrin.us  Fri Apr  2 18:13:42 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 2 Apr 2010 18:13:42 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <C7DA152A.38CF1%alain_durand@cable.comcast.com>
References: <4BE237E0-147E-4F48-883E-052A2136898B@cisco.com> 
	<C7DA152A.38CF1%alain_durand@cable.comcast.com>
Message-ID: <m2l3c3e3fca1004021513g46ce65e0y6a9ad62085826806@mail.gmail.com>

On Thu, Apr 1, 2010 at 9:17 AM, Durand, Alain
<alain_durand at cable.comcast.com> wrote:
> To answer Fred's point bellow, the issue is that nothing prevents those ULAs
> to be routed on the Internet. It is essentially a matter of how much an
> organization is willing to pay its service provider to announce the prefix.

That's essentially the same as saying that routing an IPv4 /32 in the
Internet DFZ is "essentially a matter of how much an organization is
willing to pay its service provider to announce the prefix." It's an
intellectually dishonest statement.

-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 alain_durand at cable.comcast.com  Fri Apr  2 19:08:21 2010
From: alain_durand at cable.comcast.com (Durand, Alain)
Date: Fri, 02 Apr 2010 19:08:21 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <m2l3c3e3fca1004021513g46ce65e0y6a9ad62085826806@mail.gmail.com>
Message-ID: <C7DBF125.38E66%alain_durand@cable.comcast.com>




On 4/2/10 6:13 PM, "William Herrin" <bill at herrin.us> wrote:

> On Thu, Apr 1, 2010 at 9:17 AM, Durand, Alain
> <alain_durand at cable.comcast.com> wrote:
>> To answer Fred's point bellow, the issue is that nothing prevents those ULAs
>> to be routed on the Internet. It is essentially a matter of how much an
>> organization is willing to pay its service provider to announce the prefix.
> 
> That's essentially the same as saying that routing an IPv4 /32 in the
> Internet DFZ is "essentially a matter of how much an organization is
> willing to pay its service provider to announce the prefix." It's an
> intellectually dishonest statement.

Do you remember the efforts from Randy Bush & others to limit the length of
the prefixes advertized in the DMZ to /21s? Well, how many /24 (or longer)
do you see now?

  - Alain.



From bill at herrin.us  Fri Apr  2 20:11:15 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 2 Apr 2010 20:11:15 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <C7DBF125.38E66%alain_durand@cable.comcast.com>
References: <m2l3c3e3fca1004021513g46ce65e0y6a9ad62085826806@mail.gmail.com> 
	<C7DBF125.38E66%alain_durand@cable.comcast.com>
Message-ID: <k2s3c3e3fca1004021711xb507bb5dn3311c56572bb8811@mail.gmail.com>

On Fri, Apr 2, 2010 at 7:08 PM, Durand, Alain
<alain_durand at cable.comcast.com> wrote:
>> That's essentially the same as saying that routing an IPv4 /32 in the
>> Internet DFZ is "essentially a matter of how much an organization is
>> willing to pay its service provider to announce the prefix." It's an
>> intellectually dishonest statement.
>
> Do you remember the efforts from Randy Bush & others to limit the length of
> the prefixes advertized in the DMZ to /21s? Well, how many /24 (or longer)
> do you see now?

/24? Lots. Longer? Zero that I see announced from more than one of my transits.

And that's my point. Netops already know to exclude fc00::/7 from the
DFZ. More precisely, netops know to include only 2000::/3 in the
Internet DFZ (http://www.iana.org/assignments/ipv6-address-space/).
Too many people at too many organizations would have to choose to
exceptionally accept a given ULA prefix from within fc00::/8 for it to
be usefully routed on the Internet. this would be -effectively-
impossible.

As for Randy's efforts, you never had a strong consensus to limit IPv4
announcements to /21. A weak consensus sure, but "weak consensus" is
just a fancy way of saying "boisterous minority." The strong consensus
to filter IPv4 at /24 is all but set in stone these days and the
consensus that the IPv6 Internet consists of 2000:/3 until IETF says
otherwise seems likely to stick.

Likely enough to stick, at any rate, that you can tweak fc00::/8 with
the reasonable expectation that there won't be any impact on the IPv6
Internet DFZ.


As you are not an idiot, you already knew all this. That's why I
called your claim that getting a ULA into the DFZ would just be a
question of money intellectually dishonest.

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 alain_durand at cable.comcast.com  Fri Apr  2 22:22:42 2010
From: alain_durand at cable.comcast.com (Durand, Alain)
Date: Fri, 02 Apr 2010 22:22:42 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <k2s3c3e3fca1004021711xb507bb5dn3311c56572bb8811@mail.gmail.com>
Message-ID: <C7DC1EB2.38E87%alain_durand@cable.comcast.com>




On 4/2/10 8:11 PM, "William Herrin" <bill at herrin.us> wrote:

> The strong consensus
> to filter IPv4 at /24 is all but set in stone these days

Do you think this is going to stay that way very long after IANA exhaust?
I personally don't. There is already provision in a policy adopted by ARIN
to allocate /28s out of a reserved /10 to help IPv6 deployment after
exhaustion.

> As you are not an idiot, you already knew all this. That's why I
> called your claim that getting a ULA into the DFZ would just be a
> question of money intellectually dishonest.

Words like these do not help much. We may agree to disagree, but the
discussion should remain courteous.

   - Alain.



From bill at herrin.us  Sun Apr  4 00:00:53 2010
From: bill at herrin.us (William Herrin)
Date: Sun, 4 Apr 2010 00:00:53 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <C7DC1EB2.38E87%alain_durand@cable.comcast.com>
References: <k2s3c3e3fca1004021711xb507bb5dn3311c56572bb8811@mail.gmail.com> 
	<C7DC1EB2.38E87%alain_durand@cable.comcast.com>
Message-ID: <o2o3c3e3fca1004032100y8fcb4ar5591f0bf38f24317@mail.gmail.com>

On Fri, Apr 2, 2010 at 10:22 PM, Durand, Alain
<alain_durand at cable.comcast.com> wrote:
> On 4/2/10 8:11 PM, "William Herrin" <bill at herrin.us> wrote:
>> The strong consensus
>> to filter IPv4 at /24 is all but set in stone these days
>
> Do you think this is going to stay that way very long after IANA exhaust?

Alain,

I think the cost of an IPv4 address has a long way to rise and the
cost of an IPv4 route has a long way to fall before the economics
favor a general shift towards accepting longer prefixes in the DFZ.
Converting allocation to a zero-sum game will certainly increase the
cost of an IPv4 address. But that much? My magic 8-ball says: Very
Doubtful.

For that matter, if the /21 crew hadn't overstepped by also pushing
the notion that folks couldn't multihome unless they had yay many
computers, they'd have probably have managed to pull the bulk of the
/8's back to a maximum prefix length of /21. They had a compelling
case, but boxing small multihomers into a corner where they had to use
PA cutouts proved self-destructive.



>> As you are not an idiot, you already knew all this. That's why I
>> called your claim that getting a ULA into the DFZ would just be a
>> question of money intellectually dishonest.
>
> Words like these do not help much. We may agree to disagree, but the
> discussion should remain courteous.

You're right. I'm just frustrated with the direction this discussion has gone.

The need here is real simple. ULA. From the already-defined ULA pool.
But with registry-guaranteed uniqueness (instead of statistical
uniqueness) and a DNS PTR delegation.

It ain't supposed to be a global unicast address. It's useless if it
we unify policies to the point where the registry function costs the
same as it does for a global unicast address. The NAT boogieman isn't
going to get us any faster with or without it. And for God's sake, we
need an RFC to tell IANA to hand addresses off to a registry or
registries, not micromanage every little detail.

-Bill



-- 
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 info at arin.net  Mon Apr  5 14:44:58 2010
From: info at arin.net (Member Services)
Date: Mon, 05 Apr 2010 14:44:58 -0400
Subject: [arin-ppml] Draft Policy 2010-8: Rework of IPv6 assignment criteria
	- revised
Message-ID: <4BBA2FAA.9040000@arin.net>

Draft Policy 2010-8
Rework of IPv6 assignment criteria

2010-8 has been revised.

"The Change made since the last version that went to PPML are;

1. Section 6.5.8.4 was removed and the current Community Networks policy
was moved as-is from 6.5.9 to 6.5.10.  This move is necessary to make
room for section 6.5.9 Subsequent assignments from this policy to
immediately follow section 6.5.8. Initial assignments.

2. A number of small editorial changes and grammatical corrections."

This draft policy is open for discussion on this mailing list and will
be on the agenda at the upcoming ARIN Public Policy Meeting in Toronto.

Draft Policy 2010-8 is below and can be found at:
https://www.arin.net/policy/proposals/2010_8.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2010-8
Rework of IPv6 assignment criteria

Version/Date: 5 April 2010

Policy statement:

6.5.8. Initial assignments

6.5.8.1. Initial assignment size

Organizations that meet at least one of the following criteria are
eligible to receive a minimum assignment of /48. Requests for larger
initial assignments, reasonably justified with supporting documentation,
will be evaluated based on the number of sites and the number of subnets
needed to support a site.

Organizations may request up to a /48 for each site in their network,
with the overall allocation rounded up to the next whole prefix only as
necessary. A subnet plan demonstrating a utilization of 33,689 or more
subnets within a site is necessary to justify an additional /48 for any
individual site, beyond this the 0.94 HD-Ratio metric of the number of
subnets is used.

All assignments shall be made from distinctly identified prefixes, with
each assignment receiving a reservation for growth of at least a /44.
Such reservations are not guaranteed and ARIN, at its discretion, may
assign them to other organizations at any time.

Note: Organizations with multiple sites are encouraged to consider the
use of /56s for smaller satellite sites.

6.5.8.2. Criteria for initial assignment to Internet connected end-users

Organizations may justify an initial assignment for connecting their own
network to the IPv6 Internet, with an intent to provide global
reachability for the assignment within 12 months, and for addressing
devices directly attached to their network infrastructure, by meeting
one of the following additional criteria:

a. Having a previously justified IPv4 end-user assignment from ARIN or
one of its predecessor registries, or;

b. Currently being IPv6 Multihomed or immediately becoming IPv6
Multihomed and using an assigned valid global AS number, or;

c. By providing a reasonable technical justification indicating why
other IPv6 addresses from an ISP or other LIR are unsuitable and a plan
detailing the utilization of sites and subnets for one, two and five
year periods.

Examples of justifications for why addresses from an ISP or other LIR
may be unsuitable include, but are not limited to:

     * An organization that operates infrastructure critical to life
safety or the functioning of society, has justification based on the
fact that renumbering would have a broader than expected impact than
simply the number of hosts involved. These would include; hospitals,
fire fighting, police, emergency response, power or energy distribution,
water or waste treatment, traffic management and control, etc?
     * Regardless of the number of hosts involved, an organization has
justification if renumbering would affect 1000 or more individuals
either internal or external to the organization.

6.5.8.3 Criteria for initial assignment to non-connected networks

Organizations may justify an initial assignment for operating their own
non-connected IPv6 network and for addressing devices directly attached
to their network infrastructure, by meeting one of the following
additional criteria:

a. Having a previously justified IPv4 end-users assignment from ARIN or
one of its predecessor registries, or;

b. By providing a reasonable technical justification indicating why an
assignment for a non-connected networks is necessary, including the
intended purpose for the assignment, and describing the network
infrastructure the assignment will be used to support. Justification
must include why Unique Local IPv6 Unicast Addresses (ULA) is unsuitable
and a plan detailing the utilization of sites and subnets for one, two
and five year periods.

Examples of justifications for why ULA may be unsuitable include, but
are not limited to:

     * The need for authoritative delegation of reverse DNS, including
documentation why this is necessary.
     * The need for documented uniqueness, beyond the statistical
uniqueness provided by ULA, including documentation why this is necessary.
     * A documented need to connect with other networks connected to or
not connected to the Internet

NOTE: Organizations are encouraged to consider the use of ULA, for
non-connected networks, see RFC 4193 for details.

6.5.9. Subsequent assignments

Subsequent assignments may be made when the need for additional sites or
subnets are justified with reasonable supporting documentation. When
possible, subsequent assignments will be made from an adjacent address
block.

Organizations may request up to a /48 for each site in their network,
with the overall allocation rounded up to the next whole prefix only as
necessary. A subnet plan demonstrating a utilization of 33,689 or more
subnets within a site is necessary to justify an additional /48 for any
individual site, beyond this the 0.94 HD-Ratio metric of the number of
subnets is used.

Note: Organizations with multiple sites are encouraged to consider the
use of /56s for smaller satellite sites.

Move current 6.5.9 Community Network Assignments as-is to section 6.5.10.

Rationale:

This proposal provides a complete rework of the IPv6 end-user assignment
criteria, removing the dependency on IPv4 policy, while maintaining many
of the basic concepts contained in the current policies. The order of
the subsections of 6.5.8 was rearranged moving the initial assignment
size to 6.5.8.1 and subsequent assignments to 6.5.9. This will
facilitate adding future criteria without additional renumbering of
current policies.

The initial assignment criteria include the following general concepts:

     * When Internet connectivity is use to justify resources it is
implied the resources should be advertised to the Internet, within some
reasonable time frame after they are received.
     * Previously justified IPv4 resources may be used to justify the
need for IPv6 resources.
     * Internet multihoming is sufficient justification for an end-user
assignment in and of itself.
     * Other Internet connected end-users must justify why an ISP or LIR
assignment is not sufficient for their needs.
     * Non-connected networks must describe the purpose and network
infrastructure the assignment will be supporting, including why ULA is
not sufficient for their needs.
     * Organizations with multiple sites are allowed to request a /48
for each site, with a suggestion to use /56s for smaller sites.
     * While HD-Ratio is not completely eliminated it really only
applies to situations that an individual site of an organization needs
more that a /48.

Timetable for implementation: Immediate











From mcr at sandelman.ca  Mon Apr  5 22:09:04 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Mon, 05 Apr 2010 22:09:04 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <8695009A81378E48879980039EEDAD28876D43FA@MAIL1.polartel.local> 
References: <014501cacc77$5573fe00$005bfa00$@net> <4BB20FA7.1020100@gmail.com>
	<54827055-3AFB-4510-9592-4B2DD47F3086@delong.com>
	<4BB2BF86.8000000@ibctech.ca>
	<8695009A81378E48879980039EEDAD28876D43D1@MAIL1.polartel.local>
	<68D14357-C52A-4790-A14E-5026D37A495F@delong.com>
	<8695009A81378E48879980039EEDAD28876D43F0@MAIL1.polartel.local>
	<4BB4CCC0.7050005@umn.edu>
	<8695009A81378E48879980039EEDAD28876D43F3@MAIL1.polartel.local>
	<16249.1270170285@marajade.sandelman.ca>
	<8695009A81378E48879980039EEDAD28876D43FA@MAIL1.polartel.local>
Message-ID: <10692.1270519744@marajade.sandelman.ca>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Kevin" == Kevin Kargel <kkargel at polartel.com> writes:
    >> Sure.  Show me again, where the 20-person operation that have a
    >> cable connection, and a DSL connection (and thus two sets of
    >> GUA-PA), get this GUA-PI that they need to have stable addresses
    >> internally?  Said company has two different types of connections
    >> because neither is reliable enough.
    >> 
    >> ULA-C is not about ISPs. It's about SME.

    Kevin> So you are telling me that as an ISP I will need to make
    Kevin> special routes for each and every DSL customer that has two
    Kevin> xSL connections?

    Kevin> Why doesn't that customer just get his own GUA if this is so
    Kevin> important to his business?

If you follow Owen's advice: yes.

If ARIN can get it's head around giving out non-routable address space
for intranet use,  and having customers use multiple PA addresses on
their desktops, then the answer is no.


Either shim6 will get completed and deployed, or there will be NAT66.
(As an ISP, btw, you won't be able to tell the difference.  As someone
who does support into the enterprise from remote,  usually working with
ISPs that can't spell ARIN, I sure know which I am rooting for)


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





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS7qXvYCLcPvd0N1lAQLkYQf7BUnk0R2C6ShUvq6M+FQ27dBZjqfAgfL9
k5nkOsKBYqtajXpRhF2n2rW1pIRonkN5a6hUXdIN2HDQyMSUkzgMPjwKoRrqPtZj
KrPIkL7aZVGvbl+S9/iReMCndiqmigI4ujaq/hy0mT7iWu5WDgVKA/gCZ5l2P/JO
pVxprx6UGkDt0xyw3B2ZNZICZ3Lcwp6JjLnzGEDJRKraidUHoI9NXxhSZDf297OH
8yGwawoYtvTJiuU8LG9S//RdyZ9wrqai7GwNxjOoTSMGv2kie5b5xe/8Wq1BK78g
04LGuTXrtPwWanPVpQGv2Xsgt9Yg7Os9gTlvouGroMsqLzOuBwvtPA==
=5RgL
-----END PGP SIGNATURE-----


From mcr at sandelman.ca  Mon Apr  5 22:09:45 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Mon, 05 Apr 2010 22:09:45 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <C7DBF125.38E66%alain_durand@cable.comcast.com> 
References: <C7DBF125.38E66%alain_durand@cable.comcast.com> 
Message-ID: <10747.1270519785@marajade.sandelman.ca>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Alain" == Alain Durand <Durand> writes:
    >> On Thu, Apr 1, 2010 at 9:17 AM, Durand, Alain
    >> <alain_durand at cable.comcast.com> wrote:
    >>> To answer Fred's point bellow, the issue is that nothing
    >>> prevents those ULAs to be routed on the Internet. It is
    >>> essentially a matter of how much an organization is willing to
    >>> pay its service provider to announce the prefix.
    >> That's essentially the same as saying that routing an IPv4 /32 in
    >> the Internet DFZ is "essentially a matter of how much an
    >> organization is willing to pay its service provider to announce
    >> the prefix." It's an intellectually dishonest statement.

    Alain> Do you remember the efforts from Randy Bush & others to limit
    Alain> the length of the prefixes advertized in the DMZ to /21s? 
    Alain> Well, how many /24 (or longer) do you see now?

Yes. And how many /26s do you see?

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS7qX6ICLcPvd0N1lAQIAqQf/bxnF6TvlQjX5V5cfQ2iiKA56fhIYwyHF
MRcIhMEptghYFR+xHvjieBMtQmDFcKs0XbvyGhn/lE9ncgrb4gJzyK8sUPvTpitK
A1YgErkilojkBmYNLKd7smAmtwT1G5UTUaJTfnWn58qsrBJy5k2JMpoPTbfLoBfS
RAs7aB/PIRho0kxb9JY/n/Y6DTAiB5FuUHTlja9IySuwqjaXMfxeoQMDUaXzu0PI
lrkzE8talOq7LsHzE9+EiRRKspmnr7UAUtzd1jYVHzsQwOSEgXs63sndg/KouWaC
xTIK25b/rw9Q+5hacMGZ9PxRg13l3+2dG8/tC8CWbyPcxI7ERg3kTg==
=QRa/
-----END PGP SIGNATURE-----


From christopher.morrow at gmail.com  Tue Apr  6 01:42:16 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Tue, 6 Apr 2010 01:42:16 -0400
Subject: [arin-ppml] ULA-C and reverse DNS
In-Reply-To: <07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com>
References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net>
	<4BA76279.9060809@umn.edu>
	<07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com>
Message-ID: <k2h75cb24521004052242g4a4cdafy766dcdd1ee2a3b85@mail.gmail.com>

On Mon, Mar 22, 2010 at 8:51 AM, Owen DeLong <owen at delong.com> wrote:
> I agree.
>
> I think that it makes far more sense to make a liberal GUA policy that allows
> people to get GUA if they need it regardless of whether they need it for

for the record I'd vote +1 for essentially no ULA-* ... and just
allowing folks to get GUA for their needs.

-Chris


From ggiesen at akn.ca  Tue Apr  6 02:17:12 2010
From: ggiesen at akn.ca (Gary Giesen)
Date: Tue, 6 Apr 2010 02:17:12 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <t2r75cb24521004052314y4ec0ee6fg9c245666d6ec9bd3@mail.gmail.com>
Message-ID: <C7E04A28.8FAF%ggiesen@akn.ca>

Because 65535 subnets isn't enough?

GG


On 10-04-06 2:14 AM, "Christopher Morrow" <christopher.morrow at gmail.com>
wrote:

> On Fri, Mar 26, 2010 at 6:23 PM, Gary T. Giesen <ggiesen at akn.ca> wrote:
>> Just a clarification on my comments, that's PI GUA space... Few
>> organizations will need more than a single /48, which would at least
> 
> as a clarification, any end site organization with more than a single
> office location is prone to want more than a single /48.
> 
> -Chris
> 
>> contain the number of prefixes being advertised. And with most ISP's
>> (LIR's) only requiring a single prefix for their own PA space, we should
>> a nice reset in table size, allowing hardware to catch up with routing
>> table growth.
>> 
>> GG
>> 
>> On Fri, 2010-03-26 at 18:05 -0400, Gary T. Giesen wrote:
>>> If that's a concern, then get GUA space out of the gate and you'll never
>>> renumber again. I believe GUA should be made cheap and relatively easy
>>> to get (instead of something using something like ULA and NATing it).
>>> 
>>> While some will argue this will lead to an explosion in the v6 routing
>>> table (and there is definitely merit to their argument), the aggregation
>>> gains from people who don't need the capability (especially residential
>>> customers) should more than offset it in the near term, buying time for
>>> for the technology to progress and offer us more TCAM slots to deal with
>>> it in the longer term.
>>> 
>>> GG
>>> 
>>> On Fri, 2010-03-26 at 17:54 -0400, Matthew Kaufman wrote:
>>>> Gary T. Giesen wrote:
>>>>> IMHO it's better to get people used to having no NAT at all (since
>>>>> they're getting used to a new protocol anyways)...
>>>> Please explain how you intend to eliminate manual renumbering for
>>>> corporate internal networks every time they change ISPs.
>>>> 
>>>> (And note that RA and even DHCP6 don't fix all the manual setup of
>>>> things like "what is the address of the intranet web server".)
>>>> 
>>>> There is a real cost to this, and the cost of a NAT device is pretty
>>>> much paid off the first or second time you're forced to renumber.
>>>> 
>>>> Matthew Kaufman
>>> 
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>> 



From christopher.morrow at gmail.com  Tue Apr  6 02:14:31 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Tue, 6 Apr 2010 02:14:31 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <1269642185.5400.460.camel@ggiesen-workstation.netsurf.net>
References: <mailman.736.1269490726.28982.arin-ppml@arin.net>
	<3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com>
	<1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com>
	<3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com>
	<20100326205555.D66402B2126@mx5.roble.com> <4BAD250E.10805@gmail.com>
	<1269640096.5400.411.camel@ggiesen-workstation.netsurf.net>
	<4BAD2D10.4060107@matthew.at>
	<1269641156.5400.439.camel@ggiesen-workstation.netsurf.net>
	<1269642185.5400.460.camel@ggiesen-workstation.netsurf.net>
Message-ID: <t2r75cb24521004052314y4ec0ee6fg9c245666d6ec9bd3@mail.gmail.com>

On Fri, Mar 26, 2010 at 6:23 PM, Gary T. Giesen <ggiesen at akn.ca> wrote:
> Just a clarification on my comments, that's PI GUA space... Few
> organizations will need more than a single /48, which would at least

as a clarification, any end site organization with more than a single
office location is prone to want more than a single /48.

-Chris

> contain the number of prefixes being advertised. And with most ISP's
> (LIR's) only requiring a single prefix for their own PA space, we should
> a nice reset in table size, allowing hardware to catch up with routing
> table growth.
>
> GG
>
> On Fri, 2010-03-26 at 18:05 -0400, Gary T. Giesen wrote:
>> If that's a concern, then get GUA space out of the gate and you'll never
>> renumber again. I believe GUA should be made cheap and relatively easy
>> to get (instead of something using something like ULA and NATing it).
>>
>> While some will argue this will lead to an explosion in the v6 routing
>> table (and there is definitely merit to their argument), the aggregation
>> gains from people who don't need the capability (especially residential
>> customers) should more than offset it in the near term, buying time for
>> for the technology to progress and offer us more TCAM slots to deal with
>> it in the longer term.
>>
>> GG
>>
>> On Fri, 2010-03-26 at 17:54 -0400, Matthew Kaufman wrote:
>> > Gary T. Giesen wrote:
>> > > IMHO it's better to get people used to having no NAT at all (since
>> > > they're getting used to a new protocol anyways)...
>> > Please explain how you intend to eliminate manual renumbering for
>> > corporate internal networks every time they change ISPs.
>> >
>> > (And note that RA and even DHCP6 don't fix all the manual setup of
>> > things like "what is the address of the intranet web server".)
>> >
>> > There is a real cost to this, and the cost of a NAT device is pretty
>> > much paid off the first or second time you're forced to renumber.
>> >
>> > Matthew Kaufman
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>


From christopher.morrow at gmail.com  Tue Apr  6 02:23:28 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Tue, 6 Apr 2010 02:23:28 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <4BB0ED8C.1020607@matthew.at>
References: <4BB0D390.2040502@gih.com>
	<F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA610@Skyhawk>
	<8695009A81378E48879980039EEDAD28876D43A8@MAIL1.polartel.local>
	<4BB0ED8C.1020607@matthew.at>
Message-ID: <j2o75cb24521004052323l7e085e25s19daa875aaf8e8b4@mail.gmail.com>

On Mon, Mar 29, 2010 at 2:12 PM, Matthew Kaufman <matthew at matthew.at> wrote:
> This is easy to do. Assign it from space for which there is an IETF standard
> telling router vendors to never, ever, accept that route via external
> routing protocols.
>

don't businesses use EGP's with their businss partners in today's
network on private links on private networks?

One of the complications with ULA* is address selection, another is
arbitrary breakages like the above. Another is the inability to have
an actually unique (not just semi-unique) address block. Using GUA
everywhere just fits better, folks that want to drop it at their exit
for 'security' or 'privacy' can certainly do that.

-chris


From christopher.morrow at gmail.com  Tue Apr  6 02:27:45 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Tue, 6 Apr 2010 02:27:45 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <C7E04A28.8FAF%ggiesen@akn.ca>
References: <t2r75cb24521004052314y4ec0ee6fg9c245666d6ec9bd3@mail.gmail.com>
	<C7E04A28.8FAF%ggiesen@akn.ca>
Message-ID: <k2m75cb24521004052327ne0e957b2w4ecf79f67a1bd1e2@mail.gmail.com>

On Tue, Apr 6, 2010 at 2:17 AM, Gary Giesen <ggiesen at akn.ca> wrote:
> Because 65535 subnets isn't enough?

because I have 2 locations, one in NYC one in SFO. Running a private
network link between them is more expensive than 2 commodity internet
links, I can't (today) expect longer than a /48 to pass through
inter-AS boundaries... so I need (now) a /47. Now, look at a business
like 'the Limited' who has (at last count) +1200 remote/disconnected
sites... they could need a much larger block than a /48, if they
wanted the benefits of easy multihoming/no-renumbering.

Look at Allstate Insurance that had, at last count +10k remote
sites... a /48 is a single SITE, not a single ORGANIZATION.

Note that none of the above colors the discussion about NAT nor
internal numbering schemes related to ULA*, I was simply pointing out
that it's entirely inaccurate to believe that 'Few Organizations will
need more than a single /48'.

-Chris

> GG
>
>
> On 10-04-06 2:14 AM, "Christopher Morrow" <christopher.morrow at gmail.com>
> wrote:
>
>> On Fri, Mar 26, 2010 at 6:23 PM, Gary T. Giesen <ggiesen at akn.ca> wrote:
>>> Just a clarification on my comments, that's PI GUA space... Few
>>> organizations will need more than a single /48, which would at least
>>
>> as a clarification, any end site organization with more than a single
>> office location is prone to want more than a single /48.
>>
>> -Chris
>>
>>> contain the number of prefixes being advertised. And with most ISP's
>>> (LIR's) only requiring a single prefix for their own PA space, we should
>>> a nice reset in table size, allowing hardware to catch up with routing
>>> table growth.
>>>
>>> GG
>>>
>>> On Fri, 2010-03-26 at 18:05 -0400, Gary T. Giesen wrote:
>>>> If that's a concern, then get GUA space out of the gate and you'll never
>>>> renumber again. I believe GUA should be made cheap and relatively easy
>>>> to get (instead of something using something like ULA and NATing it).
>>>>
>>>> While some will argue this will lead to an explosion in the v6 routing
>>>> table (and there is definitely merit to their argument), the aggregation
>>>> gains from people who don't need the capability (especially residential
>>>> customers) should more than offset it in the near term, buying time for
>>>> for the technology to progress and offer us more TCAM slots to deal with
>>>> it in the longer term.
>>>>
>>>> GG
>>>>
>>>> On Fri, 2010-03-26 at 17:54 -0400, Matthew Kaufman wrote:
>>>>> Gary T. Giesen wrote:
>>>>>> IMHO it's better to get people used to having no NAT at all (since
>>>>>> they're getting used to a new protocol anyways)...
>>>>> Please explain how you intend to eliminate manual renumbering for
>>>>> corporate internal networks every time they change ISPs.
>>>>>
>>>>> (And note that RA and even DHCP6 don't fix all the manual setup of
>>>>> things like "what is the address of the intranet web server".)
>>>>>
>>>>> There is a real cost to this, and the cost of a NAT device is pretty
>>>>> much paid off the first or second time you're forced to renumber.
>>>>>
>>>>> Matthew Kaufman
>>>>
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>>
>
>


From owen at delong.com  Tue Apr  6 02:58:22 2010
From: owen at delong.com (Owen DeLong)
Date: Mon, 5 Apr 2010 23:58:22 -0700
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <t2r75cb24521004052314y4ec0ee6fg9c245666d6ec9bd3@mail.gmail.com>
References: <mailman.736.1269490726.28982.arin-ppml@arin.net>
	<3c3e3fca1003261246o56e7d92s3be1d576a1566ea2@mail.gmail.com>
	<1CD5FFB3-383F-4741-BABF-6F9AFBC1501A@delong.com>
	<3c3e3fca1003261318p2354576eye3ee2fa272c878@mail.gmail.com>
	<20100326205555.D66402B2126@mx5.roble.com>
	<4BAD250E.10805@gmail.com>
	<1269640096.5400.411.camel@ggiesen-workstation.netsurf.net>
	<4BAD2D10.4060107@matthew.at>
	<1269641156.5400.439.camel@ggiesen-workstation.netsurf.net>
	<1269642185.5400.460.camel@ggiesen-workstation.netsurf.net>
	<t2r75cb24521004052314y4ec0ee6fg9c245666d6ec9bd3@mail.gmail.com>
Message-ID: <F3431519-8C95-4461-8AE0-CBF327599DDC@delong.com>

Chris is right.  You should have no problem getting a /48 per location.

Owen

On Apr 5, 2010, at 11:14 PM, Christopher Morrow wrote:

> On Fri, Mar 26, 2010 at 6:23 PM, Gary T. Giesen <ggiesen at akn.ca> wrote:
>> Just a clarification on my comments, that's PI GUA space... Few
>> organizations will need more than a single /48, which would at least
> 
> as a clarification, any end site organization with more than a single
> office location is prone to want more than a single /48.
> 
> -Chris
> 
>> contain the number of prefixes being advertised. And with most ISP's
>> (LIR's) only requiring a single prefix for their own PA space, we should
>> a nice reset in table size, allowing hardware to catch up with routing
>> table growth.
>> 
>> GG
>> 
>> On Fri, 2010-03-26 at 18:05 -0400, Gary T. Giesen wrote:
>>> If that's a concern, then get GUA space out of the gate and you'll never
>>> renumber again. I believe GUA should be made cheap and relatively easy
>>> to get (instead of something using something like ULA and NATing it).
>>> 
>>> While some will argue this will lead to an explosion in the v6 routing
>>> table (and there is definitely merit to their argument), the aggregation
>>> gains from people who don't need the capability (especially residential
>>> customers) should more than offset it in the near term, buying time for
>>> for the technology to progress and offer us more TCAM slots to deal with
>>> it in the longer term.
>>> 
>>> GG
>>> 
>>> On Fri, 2010-03-26 at 17:54 -0400, Matthew Kaufman wrote:
>>>> Gary T. Giesen wrote:
>>>>> IMHO it's better to get people used to having no NAT at all (since
>>>>> they're getting used to a new protocol anyways)...
>>>> Please explain how you intend to eliminate manual renumbering for
>>>> corporate internal networks every time they change ISPs.
>>>> 
>>>> (And note that RA and even DHCP6 don't fix all the manual setup of
>>>> things like "what is the address of the intranet web server".)
>>>> 
>>>> There is a real cost to this, and the cost of a NAT device is pretty
>>>> much paid off the first or second time you're forced to renumber.
>>>> 
>>>> Matthew Kaufman
>>> 
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From michael.dillon at bt.com  Tue Apr  6 04:49:47 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 6 Apr 2010 09:49:47 +0100
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <k2m75cb24521004052327ne0e957b2w4ecf79f67a1bd1e2@mail.gmail.com>
Message-ID: <28E139F46D45AF49A31950F88C49745805AF0623@E03MVZ2-UKDY.domain1.systemhost.net>


> because I have 2 locations, one in NYC one in SFO. Running a 
> private network link between them is more expensive than 2 
> commodity internet links, I can't (today) expect longer than 
> a /48 to pass through inter-AS boundaries... so I need (now) 
> a /47.

Why would you want to run a national network when you have
only two locations?

> Look at Allstate Insurance that had, at last count +10k 
> remote sites... a /48 is a single SITE, not a single ORGANIZATION.

Why would an insurance company want to run a national network?

> Note that none of the above colors the discussion about NAT 
> nor internal numbering schemes related to ULA*, I was simply 
> pointing out that it's entirely inaccurate to believe that 
> 'Few Organizations will need more than a single /48'.

Those of us who believe that few organizations will need more
than a single /48 expect that most organizations will stick
to their knitting and buy network services from an ISP. In other
words the ones that need more than a single /48 will not be
interested in talking to ARIN.

--Michael Dillon


From farmer at umn.edu  Tue Apr  6 07:48:48 2010
From: farmer at umn.edu (David Farmer)
Date: Tue, 06 Apr 2010 06:48:48 -0500
Subject: [arin-ppml]  /48 per Site
In-Reply-To: <k2m75cb24521004052327ne0e957b2w4ecf79f67a1bd1e2@mail.gmail.com>
References: <t2r75cb24521004052314y4ec0ee6fg9c245666d6ec9bd3@mail.gmail.com>	<C7E04A28.8FAF%ggiesen@akn.ca>
	<k2m75cb24521004052327ne0e957b2w4ecf79f67a1bd1e2@mail.gmail.com>
Message-ID: <4BBB1FA0.8000605@umn.edu>

Christopher Morrow wrote:
> On Tue, Apr 6, 2010 at 2:17 AM, Gary Giesen <ggiesen at akn.ca> wrote:
>> Because 65535 subnets isn't enough?
> 
> because I have 2 locations, one in NYC one in SFO. Running a private
> network link between them is more expensive than 2 commodity internet
> links, I can't (today) expect longer than a /48 to pass through
> inter-AS boundaries... so I need (now) a /47. Now, look at a business
> like 'the Limited' who has (at last count) +1200 remote/disconnected
> sites... they could need a much larger block than a /48, if they
> wanted the benefits of easy multihoming/no-renumbering.
> 
> Look at Allstate Insurance that had, at last count +10k remote
> sites... a /48 is a single SITE, not a single ORGANIZATION.
> 
> Note that none of the above colors the discussion about NAT nor
> internal numbering schemes related to ULA*, I was simply pointing out
> that it's entirely inaccurate to believe that 'Few Organizations will
> need more than a single /48'.

Could I please direct you to Draft Policy 2010-8 up for discussion in 
Toronto in less than two weeks, and specifically the following section;

6.5.8.1. Initial assignment size

Organizations that meet at least one of the following criteria are
eligible to receive a minimum assignment of /48. Requests for larger
initial assignments, reasonably justified with supporting documentation,
will be evaluated based on the number of sites and the number of subnets
needed to support a site.

Organizations may request up to a /48 for each site in their network,
with the overall allocation rounded up to the next whole prefix only as
necessary. A subnet plan demonstrating a utilization of 33,689 or more
subnets within a site is necessary to justify an additional /48 for any
individual site, beyond this the 0.94 HD-Ratio metric of the number of
subnets is used.

All assignments shall be made from distinctly identified prefixes, with
each assignment receiving a reservation for growth of at least a /44.
Such reservations are not guaranteed and ARIN, at its discretion, may
assign them to other organizations at any time.

Note: Organizations with multiple sites are encouraged to consider the
use of /56s for smaller satellite sites.

Would this policy text provide what you are looking for? Do you support 
this text?  Do you support DP 2010-8 in general?

Thanks

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


From trejrco at gmail.com  Tue Apr  6 09:21:09 2010
From: trejrco at gmail.com (TJ)
Date: Tue, 6 Apr 2010 09:21:09 -0400
Subject: [arin-ppml] /48 per Site
In-Reply-To: <4BBB1FA0.8000605@umn.edu>
References: <t2r75cb24521004052314y4ec0ee6fg9c245666d6ec9bd3@mail.gmail.com> 
	<C7E04A28.8FAF%ggiesen@akn.ca>
	<k2m75cb24521004052327ne0e957b2w4ecf79f67a1bd1e2@mail.gmail.com>
	<4BBB1FA0.8000605@umn.edu>
Message-ID: <y2s71bfd60c1004060621r18a0b2d5j2ef1f50718a43801@mail.gmail.com>

>
> (Christopher Morrow): because I have 2 locations, one in NYC one in SFO.
>> Running a private
>> network link between them is more expensive than 2 commodity internet
>> links, I can't (today) expect longer than a /48 to pass through
>> inter-AS boundaries... so I need (now) a /47. Now, look at a business
>> like 'the Limited' who has (at last count) +1200 remote/disconnected
>> sites... they could need a much larger block than a /48, if they
>> wanted the benefits of easy multihoming/no-renumbering.
>>
>
These remote sites probably don't host publicly reachable services, so a
simple "use PA addresses (/48 or even /56) and tunnel
to corporate" approach would work just fine, yes?  They could even be
multi-homed, but use something like GRE to have multiple concurrent tunnels
over different providers' addresses to get back to the hub.



>
>> Look at Allstate Insurance that had, at last count +10k remote
>> sites... a /48 is a single SITE, not a single ORGANIZATION.
>>
>
And how many of those remote sites have, say, ~33k network segments?
(I only ask because ... well, see below)



> Note that none of the above colors the discussion about NAT nor
>> internal numbering schemes related to ULA*, I was simply pointing out
>> that it's entirely inaccurate to believe that 'Few Organizations will
>> need more than a single /48'.
>>
>
"Few" is subjective.  Comparable to every company out there, yes - I think
"few" is an accurate term.  In absolute numbers, perhaps resembles a
different descriptor?



> (David Farmer): Could I please direct you to Draft Policy 2010-8 up for
> discussion in Toronto in less than two weeks, and specifically the following
> section;
>
> 6.5.8.1. Initial assignment size
>
> Organizations that meet at least one of the following criteria are
> eligible to receive a minimum assignment of /48. Requests for larger
> initial assignments, reasonably justified with supporting documentation,
> will be evaluated based on the number of sites and the number of subnets
> needed to support a site.
>
> Organizations may request up to a /48 for each site in their network,
> with the overall allocation rounded up to the next whole prefix only as
> necessary. A subnet plan demonstrating a utilization of 33,689 or more
> subnets within a site is necessary to justify an additional /48 for any
> individual site, beyond this the 0.94 HD-Ratio metric of the number of
> subnets is used.
>

So an org with multiple "fairly large" sites (or that can draft an address
plan making it appear so ... ) can get multiple,
discrete, noncontiguous blocks.  Don't most networks of that size have their
own mechanism(s) for back-hauling traffic between sites?  I guess I am
trying to say that I don't see this solving a common problem ... happy to be
wrong though!


All assignments shall be made from distinctly identified prefixes, with
> each assignment receiving a reservation for growth of at least a /44.
> Such reservations are not guaranteed and ARIN, at its discretion, may
> assign them to other organizations at any time.
>
> Note: Organizations with multiple sites are encouraged to consider the
> use of /56s for smaller satellite sites.
>



/TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100406/b91c8dd6/attachment.htm>

From cengel at sponsordirect.com  Tue Apr  6 10:54:55 2010
From: cengel at sponsordirect.com (Chris Engel)
Date: Tue, 6 Apr 2010 10:54:55 -0400
Subject: [arin-ppml] /48 per Site
In-Reply-To: <mailman.937.1270560425.28982.arin-ppml@arin.net>
Message-ID: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA621@Skyhawk>


Not everyone's needs nor approach will be the same, which is kinda the whole point behind this discussion of allowing people different addressing options (PA, PI , ULA-R, ULA-C)  to find the one that THEY feel works best for them. However my general approach for multiple branch offices would definately be some variation of below. Get a small PA assigment from whatever ISP makes the most sense for each branch office, setup tunnels back to corporate from thier branch office/soho firewalls and use private address space (ULA) for everything inside the firewalls. If it made sense for a branch office to advertise something public (probably wouldn't be very much) setup a DMZ off thier firewall with the couple of public addresses they need from thier local ISP and NAT them on the FW to whatever devices are running those.

For my book, this gives the most bang for the buck in terms of flexibility, security and compliance. If your using ULA-C space in this scenerio, you don't even need to worry so much about merger issues from an addressing scheme.





> These remote sites probably don't host publicly reachable
> services, so a simple "use PA addresses (/48 or even /56) and
> tunnel to corporate" approach would work just fine, yes?
> They could even be multi-homed, but use something like GRE to
> have multiple concurrent tunnels over different providers'
> addresses to get back to the hub.



Christopher Engel
Network Infrastructure Manager
SponsorDirect
cengel at sponsordirect.com
www.SponsorDirect.com
p(914) 729-7218
f (914) 729-7201



From kkargel at polartel.com  Tue Apr  6 11:13:38 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 6 Apr 2010 10:13:38 -0500
Subject: [arin-ppml] ULA-C and reverse DNS
In-Reply-To: <k2h75cb24521004052242g4a4cdafy766dcdd1ee2a3b85@mail.gmail.com>
References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net>
	<4BA76279.9060809@umn.edu>	<07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com>
	<k2h75cb24521004052242g4a4cdafy766dcdd1ee2a3b85@mail.gmail.com>
Message-ID: <8695009A81378E48879980039EEDAD28876D4435@MAIL1.polartel.local>



> 
> for the record I'd vote +1 for essentially no ULA-* ... and just
> allowing folks to get GUA for their needs.
> 
> -Chris

I have to agree.  As long as it has a "U" in it then it depletes the pool the same.  We have a big enough pool, let's just make GUA easy and cheap and not worry about ULA.  If they have sufficient GUA then rolling your own ULA is trivial.


From bill at herrin.us  Tue Apr  6 11:23:40 2010
From: bill at herrin.us (William Herrin)
Date: Tue, 6 Apr 2010 11:23:40 -0400
Subject: [arin-ppml] ULA-C and reverse DNS
In-Reply-To: <8695009A81378E48879980039EEDAD28876D4435@MAIL1.polartel.local>
References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net>
	<4BA76279.9060809@umn.edu>
	<07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com> 
	<k2h75cb24521004052242g4a4cdafy766dcdd1ee2a3b85@mail.gmail.com> 
	<8695009A81378E48879980039EEDAD28876D4435@MAIL1.polartel.local>
Message-ID: <o2y3c3e3fca1004060823n3df2085au5f992b20628c65de@mail.gmail.com>

On Tue, Apr 6, 2010 at 11:13 AM, Kevin Kargel <kkargel at polartel.com> wrote:
>> for the record I'd vote +1 for essentially no ULA-* ... and just
>> allowing folks to get GUA for their needs.
>
> I have to agree. ?As long as it has a "U" in it then it depletes
>the pool the same. ?We have a big enough pool, let's just
>make GUA easy and cheap and not worry about ULA. ?If
>they have sufficient GUA then rolling your own ULA is trivial.

Respectfully suggest you figure out how to make registered ULA work in
the $20-$50 range and _then_ think about how to make GUA more like it.
GUA costs $1250, based more or less on the costs of running a registry
according to the policies we've created for GUA. ULA isn't workable at
$1250 a pop and while you guys talk fantasies of shaving two orders of
magnitude off GUA's registry cost the ULA need continues to go
unserved.

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 mcr at sandelman.ca  Tue Apr  6 11:52:16 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Tue, 06 Apr 2010 11:52:16 -0400
Subject: [arin-ppml] ULA-C and reverse DNS
In-Reply-To: <o2y3c3e3fca1004060823n3df2085au5f992b20628c65de@mail.gmail.com> 
References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net>
	<4BA76279.9060809@umn.edu>
	<07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com>
	<k2h75cb24521004052242g4a4cdafy766dcdd1ee2a3b85@mail.gmail.com>
	<8695009A81378E48879980039EEDAD28876D4435@MAIL1.polartel.local>
	<o2y3c3e3fca1004060823n3df2085au5f992b20628c65de@mail.gmail.com>
Message-ID: <17207.1270569136@marajade.sandelman.ca>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "William" == William Herrin <bill at herrin.us> writes:
    William> On Tue, Apr 6, 2010 at 11:13 AM, Kevin Kargel
    William> <kkargel at polartel.com> wrote:
    >>> for the record I'd vote +1 for essentially no ULA-* ... and just
    >>> allowing folks to get GUA for their needs.
    >> I have to agree. ?As long as it has a "U" in it then it depletes
    >> the pool the same. ?We have a big enough pool, let's just make
    >> GUA easy and cheap and not worry about ULA. ?If they have
    >> sufficient GUA then rolling your own ULA is trivial.

    William> Respectfully suggest you figure out how to make registered
    William> ULA work in the $20-$50 range and _then_ think about how to
    William> make GUA more like it.  GUA costs $1250, based more or less
    William> on the costs of running a registry according to the
    William> policies we've created for GUA. ULA isn't workable at $1250
    William> a pop and while you guys talk fantasies of shaving two
    William> orders of magnitude off GUA's registry cost the ULA need
    William> continues to go unserved.

+1

RFC1918 is used in all sorts of places where it shouldn't, not because
getting address space is so hard, but because it requires someone else
to sign off.

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






-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS7tYr4CLcPvd0N1lAQLUkAf+JhSiU4G3UZaaUZ9FrS11K00uNKIcAm2R
hPfuw9yVmNZpvSD97qwYvyLVjVxH/R0clEZ0SAiCrL6qnVIUBc0Xu/c0zrCh7iN4
ZBMd2tA6Ec3eUkqxf2wHS3KO5n7rFusotO4oHD1bbIeIwqlMHnvHxImbv3Qa1Tlt
xcqMPOvGYqMdJH/xvj99uKhUQWx4evZas6FaM47omso5CcPAtslkTvnh0yDjJJF5
Uh20KaKfYZT5rxgUjTdbmVXWg1SL6CtCpyUUkpyZTSCNFO4yAHK+GHKK8jvEcjmU
BVH120Q+x0fd0VHfxHwa34XJ91WGfOtaewJXNjnDVEQNOS5UqPIERQ==
=Smup
-----END PGP SIGNATURE-----


From kkargel at polartel.com  Tue Apr  6 12:24:25 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 6 Apr 2010 11:24:25 -0500
Subject: [arin-ppml] ULA-C and reverse DNS
In-Reply-To: <o2y3c3e3fca1004060823n3df2085au5f992b20628c65de@mail.gmail.com>
References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net>
	<4BA76279.9060809@umn.edu>
	<07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com>
	<k2h75cb24521004052242g4a4cdafy766dcdd1ee2a3b85@mail.gmail.com>
	<8695009A81378E48879980039EEDAD28876D4435@MAIL1.polartel.local>
	<o2y3c3e3fca1004060823n3df2085au5f992b20628c65de@mail.gmail.com>
Message-ID: <8695009A81378E48879980039EEDAD28876D443A@MAIL1.polartel.local>


 

> Respectfully suggest you figure out how to make registered ULA work in
> the $20-$50 range and _then_ think about how to make GUA more like it.
> GUA costs $1250, based more or less on the costs of running a registry
> according to the policies we've created for GUA. ULA isn't workable at
> $1250 a pop and while you guys talk fantasies of shaving two orders of
> magnitude off GUA's registry cost the ULA need continues to go
> unserved.
> 
> Regards,
> Bill Herrin
> 
Hmmm..  what makes ULA cheaper to administer than GUA from an RIR perspective?  One or the other is an artificial economy.


From ggiesen at akn.ca  Tue Apr  6 12:26:39 2010
From: ggiesen at akn.ca (Gary T. Giesen)
Date: Tue, 6 Apr 2010 12:26:39 -0400
Subject: [arin-ppml] ULA-C and reverse DNS
In-Reply-To: <8695009A81378E48879980039EEDAD28876D443A@MAIL1.polartel.local>
References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net>
	<4BA76279.9060809@umn.edu>
	<07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com>
	<k2h75cb24521004052242g4a4cdafy766dcdd1ee2a3b85@mail.gmail.com>
	<8695009A81378E48879980039EEDAD28876D4435@MAIL1.polartel.local>
	<o2y3c3e3fca1004060823n3df2085au5f992b20628c65de@mail.gmail.com>
	<8695009A81378E48879980039EEDAD28876D443A@MAIL1.polartel.local>
Message-ID: <1270571199.18403.11.camel@ggiesen-workstation.netsurf.net>

Absolutely nothing (maybe a little less paperwork). That's why ULA-C is
pointless and GUA should be assigned.

GG

On Tue, 2010-04-06 at 12:24 -0400, Kevin Kargel wrote:
> 
> 
> > Respectfully suggest you figure out how to make registered ULA work in
> > the $20-$50 range and _then_ think about how to make GUA more like it.
> > GUA costs $1250, based more or less on the costs of running a registry
> > according to the policies we've created for GUA. ULA isn't workable at
> > $1250 a pop and while you guys talk fantasies of shaving two orders of
> > magnitude off GUA's registry cost the ULA need continues to go
> > unserved.
> > 
> > Regards,
> > Bill Herrin
> > 
> Hmmm..  what makes ULA cheaper to administer than GUA from an RIR perspective?  One or the other is an artificial economy.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From mcr at sandelman.ca  Tue Apr  6 12:40:13 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Tue, 06 Apr 2010 12:40:13 -0400
Subject: [arin-ppml] ULA-C and reverse DNS
In-Reply-To: <8695009A81378E48879980039EEDAD28876D443A@MAIL1.polartel.local> 
References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net>
	<4BA76279.9060809@umn.edu>
	<07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com>
	<k2h75cb24521004052242g4a4cdafy766dcdd1ee2a3b85@mail.gmail.com>
	<8695009A81378E48879980039EEDAD28876D4435@MAIL1.polartel.local>
	<o2y3c3e3fca1004060823n3df2085au5f992b20628c65de@mail.gmail.com>
	<8695009A81378E48879980039EEDAD28876D443A@MAIL1.polartel.local>
Message-ID: <20342.1270572013@marajade.sandelman.ca>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Kevin" == Kevin Kargel <kkargel at polartel.com> writes:
    >> Respectfully suggest you figure out how to make registered ULA
    >> work in the $20-$50 range and _then_ think about how to make GUA
    >> more like it.  GUA costs $1250, based more or less on the costs
    >> of running a registry according to the policies we've created for
    >> GUA. ULA isn't workable at $1250 a pop and while you guys talk
    >> fantasies of shaving two orders of magnitude off GUA's registry
    >> cost the ULA need continues to go unserved.

    Kevin> Hmmm..  what makes ULA cheaper to administer than GUA from an
    Kevin> RIR perspective?  One or the other is an artificial economy.

There is a needs test associated with GUA, and some human involvement in
determining if you've asked for the correct size, and the preservation
of the /44 (or whatever the bigger amount is), etc.

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS7tj7ICLcPvd0N1lAQLDuAf/SKpl1geNwRm6/bpoCBLEcA/3Xom8X0wp
aZwUR/kxEp/XHKIO3PKG4AK1RX2mISy162hIGOeuEl4PBCdsizYosl7KrZmNAR3a
kTDaggIl9jsLCMZOUWxGM1tGyyKctTasb1X3GcNN4pHSMaCNOrq3pPpHf8A+4Y10
R49fqnnLUxWNC8m6HJWFLXdLzw7vQiGg2OZS14keRTu29AvNDJfviPxDwGhf+lOU
WgVpzhQzuZBbur0G1R1Tvl2OcgZmcnyYZfVlO8YTFZlH/TNmbSpOu6MFe4v7l07+
4fu9ePoxwFALk1J9orv5zv+jUhgkLpxP5UwHCRpy4SY0D1js3UK/Kw==
=cmcA
-----END PGP SIGNATURE-----


From kkargel at polartel.com  Tue Apr  6 12:42:13 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 6 Apr 2010 11:42:13 -0500
Subject: [arin-ppml] FW:  ULA-C and reverse DNS
Message-ID: <8695009A81378E48879980039EEDAD28876D443D@MAIL1.polartel.local>



> ARIN PPML can not, I'm told, set prices, only policies.
> So, we can't make GUA cheap directly.
> 
> Further, since the AC acknowledges that they are using the allocation
> policies as a proxy for limiting DFZ table size, anything that makes GUA
> cheaper will cause the DFZ to grow.
> 
> Thus the reason to have ULA is a seperate space that mostly can not be
> used for global routing.
> 
> - --
> ]       He who is tired of Weird Al is tired of life!           |
> firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
> architect[

If any part - even one address - of ULA can be routed then it is not ULA, it is GUA.  If it is GUA then current policy and pricing apply.  Simple.


From owen at delong.com  Tue Apr  6 12:56:25 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 6 Apr 2010 09:56:25 -0700
Subject: [arin-ppml] ULA-C and reverse DNS
In-Reply-To: <20342.1270572013@marajade.sandelman.ca>
References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net>
	<4BA76279.9060809@umn.edu>
	<07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com>
	<k2h75cb24521004052242g4a4cdafy766dcdd1ee2a3b85@mail.gmail.com>
	<8695009A81378E48879980039EEDAD28876D4435@MAIL1.polartel.local>
	<o2y3c3e3fca1004060823n3df2085au5f992b20628c65de@mail.gmail.com>
	<8695009A81378E48879980039EEDAD28876D443A@MAIL1.polartel.local>
	<20342.1270572013@marajade.sandelman.ca>
Message-ID: <8F86B89C-78E8-4E18-8806-33753C107123@delong.com>

> 
>    Kevin> Hmmm..  what makes ULA cheaper to administer than GUA from an
>    Kevin> RIR perspective?  One or the other is an artificial economy.
> 
> There is a needs test associated with GUA, and some human involvement in
> determining if you've asked for the correct size, and the preservation
> of the /44 (or whatever the bigger amount is), etc.

There are may more /48s in a /3 than there are in a /8.
GUA can be expanded beyond the current /3.  ULA is limited to a /8.

I think that there should be a needs test and human involvement in the
sizing policies in both cases.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100406/23e45419/attachment.htm>

From jerry1upton at aol.com  Tue Apr  6 13:43:00 2010
From: jerry1upton at aol.com (jerry1upton at aol.com)
Date: Tue, 06 Apr 2010 13:43:00 -0400
Subject: [arin-ppml] MAAWG Comments on ARIN Draft Proposal  2010-3
Message-ID: <8CCA3C7BC2AEC69-FD8-E831@webmail-m099.sysops.aol.com>


 The attached are comments from the Messaging Anti-Abuse Working Group regarding ARIN's Draft Policy 2010-3. The MAAWG Board of Directors have approved these comments.
 Regards,
Jerry Upton
Executive Director

 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100406/96f4e034/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MAAWG Comments ARIN Draft Policy 2010-3.pdf
Type: application/pdf
Size: 121861 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100406/96f4e034/attachment.pdf>

From michael.dillon at bt.com  Tue Apr  6 13:52:28 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 6 Apr 2010 18:52:28 +0100
Subject: [arin-ppml] ULA-C and reverse DNS
In-Reply-To: <8695009A81378E48879980039EEDAD28876D443A@MAIL1.polartel.local>
Message-ID: <28E139F46D45AF49A31950F88C49745805AF0C4D@E03MVZ2-UKDY.domain1.systemhost.net>


> Hmmm..  what makes ULA cheaper to administer than GUA from an 
> RIR perspective?  One or the other is an artificial economy.

No analysis necessary. No rules to apply. No justifications needed.

It can be done with a web page that the customer must fill in 
completely, with help instructions embedded on the page. When
they click the final button with their credit card details, 
ARIN's system collects the money and queues up a request.
All that a human has to do is a simple check for complete 
info as requested, and that the payment has cleared. Then 
they push another button that causes ARIN's server to do 
a "create" transaction with the IANA ULA-C registry server.
The address block is allocated and added into IANA's registry.
The ARIN server does a quick lookup check to be sure that it
is properly recorded in the registry and then fires off an 
email to the registrant. Occasionally something will fail and
need a few minutes of human attention to sort out.

That is why ULA-C registration should be cheaper.

I would expect that the IETF instructs ICANN/IANA/NRO to collect
a fee of no more than USD 4.00 for each "create" transaction and
no more than USD 1.00 for each modify transaction. Then I would expect
that the RIRs would set their fees to the registrant to be compatible
with their local fee structure, and a lot cheaper than global unicast
addresses from 2000::/3

If you want to argue the IETF imposed fee structure then do it on
the 6MAN WG mailing list. As for ARIN fees, if you are a member,
ARIN operates a member mailing list where you could discuss this.
Since it is not open to influence by the policy development process
we shouldn't get into big discussions of it here.

--Michael Dillon


From michael.dillon at bt.com  Tue Apr  6 13:57:08 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 6 Apr 2010 18:57:08 +0100
Subject: [arin-ppml] FW:  ULA-C and reverse DNS
In-Reply-To: <8695009A81378E48879980039EEDAD28876D443D@MAIL1.polartel.local>
Message-ID: <28E139F46D45AF49A31950F88C49745805AF0C4F@E03MVZ2-UKDY.domain1.systemhost.net>

> If any part - even one address - of ULA can be routed then it 
> is not ULA, it is GUA.  If it is GUA then current policy and 
> pricing apply.  Simple.

GUA (Global Unicast Address) is defined by the IETF as an
address from the 2000::/3 block. ULA is defined by the IETF
as an address from the FC00::/7 block. Clearly ULA is not GUA.

Also quite clearly, ULA addresses can be routed. There is not
restriction on how ULA addresses are to be used, unlike, for
instance, multicast addresses.

On a policy level, routability is determined by network operators
not by ARIN. 

And as far as fees are concerned, this mailing list cannot influence
ARIN's fee structure, nor can it influence how the IETF sets up
the fee structure, nor can it influence the fees that ICANN might
set in the future for one reason or another.

--Michael Dillon


From kkargel at polartel.com  Tue Apr  6 14:34:07 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 6 Apr 2010 13:34:07 -0500
Subject: [arin-ppml] FW:  ULA-C and reverse DNS
In-Reply-To: <28E139F46D45AF49A31950F88C49745805AF0C4F@E03MVZ2-UKDY.domain1.systemhost.net>
References: <8695009A81378E48879980039EEDAD28876D443D@MAIL1.polartel.local>
	<28E139F46D45AF49A31950F88C49745805AF0C4F@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <8695009A81378E48879980039EEDAD28876D4442@MAIL1.polartel.local>

> 
> > If any part - even one address - of ULA can be routed then it
> > is not ULA, it is GUA.  If it is GUA then current policy and
> > pricing apply.  Simple.
> 
> GUA (Global Unicast Address) is defined by the IETF as an
> address from the 2000::/3 block. ULA is defined by the IETF
> as an address from the FC00::/7 block. Clearly ULA is not GUA.
> 
> Also quite clearly, ULA addresses can be routed. There is not
> restriction on how ULA addresses are to be used, unlike, for
> instance, multicast addresses.
> 
> On a policy level, routability is determined by network operators
> not by ARIN.
> 
> And as far as fees are concerned, this mailing list cannot influence
> ARIN's fee structure, nor can it influence how the IETF sets up
> the fee structure, nor can it influence the fees that ICANN might
> set in the future for one reason or another.
> 
> --Michael Dillon
> _______________________________________________

Thank you for explaining plainly and in detail exactly how ULA is designed as an end run around GUA policies.



From wes at ren-isac.net  Tue Apr  6 14:34:43 2010
From: wes at ren-isac.net (Wes Young)
Date: Tue, 6 Apr 2010 14:34:43 -0400
Subject: [arin-ppml] Comments on Draft Policy 2010-3: Customer
	Confidentiality
Message-ID: <474FEA3C-42FE-401D-A6CB-130973053094@ren-isac.net>

On behalf of the Research and Education Networking Information Sharing  
and Analysis Center (REN-ISAC), we submit these comments on ARIN Draft  
Policy 2010-3: Customer Confidentiality, herein referred to as "the  
Policy".

The mission of the REN-ISAC is to aid and promote cyber security  
operational protection and response within the higher education and  
research (R&E) communities. The mission is conducted within the  
context of a private community of trusted representatives at member  
institutions, and in service to the R&E community at-large. REN-ISAC  
serves as the R&E trusted partner for served networks, the formal U.S.  
ISAC community, and in other commercial, governmental, and private  
security information sharing relationships.

Among the activities conducted, REN-ISAC sends notifications to EDU  
abuse contacts regarding compromised or otherwise maliciously behaving  
machines. Hundreds of notifications are sent daily. Numerous  
commercial, non-commercial, and governmental organizations rely on REN- 
ISAC's performance in this role, in addition to the EDUs receiving the  
notifications.

Although the REN-ISAC develops and maintains its own contact database,  
unfettered access to contact information in the ARIN registry permits  
us to:

+ Identify new or existing institutions that have obtained or returned  
allocated IP space within our scope of concern.

+ Identify a technical contact at an institution.

Should the Policy be implemented and adopted, it would hamper our  
ability to execute the mission. Implications would include:

+ Significantly increase lead-times and human interrupts required to  
perform notifications regarding compromised and misbehaving machines.

+ Increase the difficulty of identifying a technical contact at the  
organization that is in the best position to deal with a cyber  
security incident.

+ Add a layer of process that would either prevent or inhibit timely  
event notification.

+ Add to the costs of performing notifications.

While we appreciate the need for a balance of privacy on the Internet,  
we don't believe that the Internet or its users would be well-served  
by confidential registrations at above a /x. The policy would prove to  
be a detriment to global cyber security. Ultimately it would equate to  
a reduced ability to deal with active criminal threat.

on behalf of the REN-ISAC,
--
Wes Young
Principal Security Engineer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100406/4fa9071e/attachment.sig>

From aaron at wholesaleinternet.net  Tue Apr  6 15:01:36 2010
From: aaron at wholesaleinternet.net (Aaron Wendel)
Date: Tue, 6 Apr 2010 14:01:36 -0500
Subject: [arin-ppml] Comments on Draft Policy 2010-3:
	Customer	Confidentiality
In-Reply-To: <474FEA3C-42FE-401D-A6CB-130973053094@ren-isac.net>
References: <474FEA3C-42FE-401D-A6CB-130973053094@ren-isac.net>
Message-ID: <018901cad5bb$95108950$bf319bf0$@net>

Hi Wes,

Thank you for contributing to the discussion on Draft Policy 2010-3.  

I've been contacted recently by several people who have expressed concerns
such as yours over this policy.  In all cases these people, such as
yourself, seem to be unaware of the ARIN whois structure or how this policy
changes it.  There are broad assumptions being made that this would do away
with the whois information or somehow "obscure" it and make life tough for
people like yourself.  Most respondents I've talked to have said that they
need to know who ARIN has allocated IP space to.  This proposal does nothing
to change the information that ARIN provides in a public format on who IPs
are allocated to.  It does not obscure any data currently available on who
has IPs from ARIN.

Since I will be presenting the proposal at the upcoming ARIN meeting I'd
like to get a better idea of what is perpetuating these misunderstandings so
I can present in a way that is understandable to all.  As it stands, the
policy is 2 sentences and does nothing to obscure any information that ARIN
currently reports on the allocations it makes.  If you could help me
understand what makes you think otherwise it would be a great help to me.
There is still time for me to change the wording of the policy before the
meeting in a week.

Any help is appreciated.  Thanks for your time.

Aaron



-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Wes Young
Sent: Tuesday, April 06, 2010 1:35 PM
To: arin-ppml at arin.net
Subject: [arin-ppml] Comments on Draft Policy 2010-3: Customer
Confidentiality

On behalf of the Research and Education Networking Information Sharing and
Analysis Center (REN-ISAC), we submit these comments on ARIN Draft Policy
2010-3: Customer Confidentiality, herein referred to as "the Policy".

The mission of the REN-ISAC is to aid and promote cyber security operational
protection and response within the higher education and research (R&E)
communities. The mission is conducted within the context of a private
community of trusted representatives at member institutions, and in service
to the R&E community at-large. REN-ISAC serves as the R&E trusted partner
for served networks, the formal U.S.  
ISAC community, and in other commercial, governmental, and private security
information sharing relationships.

Among the activities conducted, REN-ISAC sends notifications to EDU abuse
contacts regarding compromised or otherwise maliciously behaving machines.
Hundreds of notifications are sent daily. Numerous commercial,
non-commercial, and governmental organizations rely on REN- ISAC's
performance in this role, in addition to the EDUs receiving the
notifications.

Although the REN-ISAC develops and maintains its own contact database,
unfettered access to contact information in the ARIN registry permits us to:

+ Identify new or existing institutions that have obtained or returned
allocated IP space within our scope of concern.

+ Identify a technical contact at an institution.

Should the Policy be implemented and adopted, it would hamper our ability to
execute the mission. Implications would include:

+ Significantly increase lead-times and human interrupts required to
perform notifications regarding compromised and misbehaving machines.

+ Increase the difficulty of identifying a technical contact at the
organization that is in the best position to deal with a cyber security
incident.

+ Add a layer of process that would either prevent or inhibit timely
event notification.

+ Add to the costs of performing notifications.

While we appreciate the need for a balance of privacy on the Internet, we
don't believe that the Internet or its users would be well-served by
confidential registrations at above a /x. The policy would prove to be a
detriment to global cyber security. Ultimately it would equate to a reduced
ability to deal with active criminal threat.

on behalf of the REN-ISAC,
--
Wes Young
Principal Security Engineer


No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.800 / Virus Database: 271.1.1/2792 - Release Date: 04/06/10
01:32:00



From wes at ren-isac.net  Tue Apr  6 15:51:41 2010
From: wes at ren-isac.net (Wes Young)
Date: Tue, 6 Apr 2010 15:51:41 -0400
Subject: [arin-ppml] Comments on Draft Policy 2010-3:
	Customer	Confidentiality
In-Reply-To: <018901cad5bb$95108950$bf319bf0$@net>
References: <474FEA3C-42FE-401D-A6CB-130973053094@ren-isac.net>
	<018901cad5bb$95108950$bf319bf0$@net>
Message-ID: <6D251AF0-1FE5-4184-9032-014EBCB9E6CB@ren-isac.net>


On Apr 6, 2010, at 3:01 PM, Aaron Wendel wrote:

> Hi Wes,
>
> Thank you for contributing to the discussion on Draft Policy 2010-3.
>
> I've been contacted recently by several people who have expressed  
> concerns
> such as yours over this policy.  In all cases these people, such as
> yourself, seem to be unaware of the ARIN whois structure or how this  
> policy
> changes it.  There are broad assumptions being made that this would  
> do away
> with the whois information or somehow "obscure" it and make life  
> tough for
> people like yourself.  Most respondents I've talked to have said  
> that they
> need to know who ARIN has allocated IP space to.  This proposal does  
> nothing
> to change the information that ARIN provides in a public format on  
> who IPs
> are allocated to.  It does not obscure any data currently available  
> on who
> has IPs from ARIN.

"ISPs may choose to enter the customer's name along with the ISP's
address and phone number in reassignments and reallocations in lieu of
the customer's address and phone number. The customer's actual
information must be provided to ARIN on request and will be held in the
strictest confidence."

Those "two lines" (at-least to me), represent sort of the "domains by  
proxy feature".

When dealing with security incidents, if the contact information is  
virtually proxy'd, then thats more time/money spent trying to get a- 
hold of someone close enough to the problem to do away with it. A  
single domain can't wipe out half of the internet, a single address  
(or set of addresses, or /29--) could. When we can't keep track of  
those closest to the situation (who care about the situation), the  
threat potential increases.

I understand what you say about the change in allocations, maybe that  
shouldn't have been listed as a primary reason (more so than the  
obfuscation of "last mile" contact information). However, the very  
thing you're trying to protect against (eg: customer lists), is one of  
the very things security ops handlers are trying to build up and keep  
current. The public information in an unstructured and federated  
environment helps us do that. It is only two sentences, and that's  
dangerous when you're setting a standard for the backbone of the  
federated environment that is the internet.

We are enumerating those customer lists on a daily basis to help make  
the internet a safer place. By design, this policy appears to be aimed  
at taking that functionality away. What appears to do (if executed by  
the isp), is force us to call upstream' ISP's first, and assuming we  
get a response, try to enumerate to them that we aren't looking to  
cherry-pick their customers, but have legit security concerns we need  
to discuss with them (assuming they're even willing to share that  
information with us anymore, in an effort to protect their customer  
lists). Not to mention if "address" is interpreted as "e-mail address"  
too, meaning "now we must go through abuse at upstream to get at  
abuse at downstream" ? In many cases we need those addresses and phone  
numbers to reach out to the down-streams. If the upstream IPS's do  
make it easy to get in touch with the downstream, then it's easy to  
enumerate those contact lists anyway, so then what's the point?

I don't want to rat-hole this (since it is policy after all). Just  
voicing an opinion that there are some ramifications for implementing  
a two-sentence policy that shifts accountability of a resource  
virtually "upstream".

Although there are somewhat legitimate business drivers behind it, the  
costs of re-routing notifications will ultimately be placed on the  
security handlers and whoever's phone/"address" is listed on that  
allocations page. The question is, are those costs worth it or not. My  
opinion is that they aren't ("to us", generally speaking as an  
incident handler).

> Since I will be presenting the proposal at the upcoming ARIN meeting  
> I'd
> like to get a better idea of what is perpetuating these  
> misunderstandings so
> I can present in a way that is understandable to all.  As it stands,  
> the
> policy is 2 sentences and does nothing to obscure any information  
> that ARIN
> currently reports on the allocations it makes.  If you could help me
> understand what makes you think otherwise it would be a great help  
> to me.
> There is still time for me to change the wording of the policy  
> before the
> meeting in a week.


on behalf of my own opinions, =)
--
Wes
http://claimid.com/wesyoung

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100406/99f196aa/attachment.sig>

From bill at herrin.us  Tue Apr  6 16:02:49 2010
From: bill at herrin.us (William Herrin)
Date: Tue, 6 Apr 2010 16:02:49 -0400
Subject: [arin-ppml] ULA-C and reverse DNS
In-Reply-To: <8695009A81378E48879980039EEDAD28876D443A@MAIL1.polartel.local>
References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net>
	<4BA76279.9060809@umn.edu>
	<07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com> 
	<k2h75cb24521004052242g4a4cdafy766dcdd1ee2a3b85@mail.gmail.com> 
	<8695009A81378E48879980039EEDAD28876D4435@MAIL1.polartel.local> 
	<o2y3c3e3fca1004060823n3df2085au5f992b20628c65de@mail.gmail.com> 
	<8695009A81378E48879980039EEDAD28876D443A@MAIL1.polartel.local>
Message-ID: <p2s3c3e3fca1004061302t9ae20cedma1dba6fdcd880fe7@mail.gmail.com>

On Tue, Apr 6, 2010 at 12:24 PM, Kevin Kargel <kkargel at polartel.com> wrote:
> Hmmm.. ?what makes ULA cheaper to administer than GUA from
> an RIR perspective? ?One or the other is an artificial economy.

There are no public-interest requirements to be analyzed with ULA save
that you pay the bill.  Thus it can be fully automated and even farmed
out to the likes of Godaddy. We're not likely to get the same economy
of scale, so it's going to still be more expensive than than a $10
dot-com, but sub-$100 is entirely achievable.

That isn't true of GUA. Who qualifies for how much GUA has major
public policy compliance concerns tied to it. Artificial or not,
managing that compliance process costs money. Perhaps GUA can be
reformatted so that the remaining public interest requirements lend
themselves to automation but while we're arguing about how to do that
it would be irresponsible to ask the folks who need ULA space to
suffer.


> If any part - even one address - of ULA can be routed [on the
> public Internet] then it is not ULA, it is GUA.  If it is GUA then
> current policy and pricing apply.  Simple.

IFYP. ULA can be routed between private systems. That's the whole
point of making them unique instead of repeating RFC 1918. The
restriction is that ULA space isn't to be introduced into the public
Internet's DFZ and if introduced, it should fail to propagate. That's
the IETF's direction for ULA and no one appears to be challenging it.

I note that subroutes of 2002::/16 are also successfully blocked from
the IPv6 DFZ even though the address space is registered. For example,
2002:c721:e000::/39 is registered to me:

{lily:herrin:/home/herrin:!} whois 2002:c721:e000::/39

Querying for the IPv4 endpoint 199.33.224.0 of a 6to4 IPv6 address.


OrgName:    Why? InterNetworking
OrgID:      WHYINT
Address:    3005 Crane Drive
City:       Falls Church
StateProv:  VA
PostalCode: 22042
Country:    US

NetRange:   199.33.224.0 - 199.33.225.255
CIDR:       199.33.224.0/23
NetName:    WHY
NetHandle:  NET-199-33-224-0-1
Parent:     NET-199-0-0-0-0
NetType:    Direct Assignment
NameServer: MINOC.DIRTSIDE.NET
NameServer: LILY.DIRTSIDE.COM
Comment:
RegDate:    1994-01-20
Updated:    2005-05-02

RTechHandle: WH23-ARIN
RTechName:   Herrin, William Dennis
RTechPhone:  +1-703-534-2652
RTechEmail:  arin-contact at herrin.us

OrgTechHandle: WH23-ARIN
OrgTechName:   Herrin, William Dennis
OrgTechPhone:  +1-703-534-2652
OrgTechEmail:  arin-contact at herrin.us

# ARIN WHOIS database, last updated 2010-04-05 20:00
# Enter ? for additional hints on searching ARIN's WHOIS database.
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at https://www.arin.net/whois_tou.html

But any route I announce for 2002:c721:e000::/39 dies hard. I fail to
see what compelling reason would cause the DFZ operators to open
routing to fc00::/7 when they haven't opened it to 2002::/16. This
fear is not well grounded.

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 wes at ren-isac.net  Tue Apr  6 16:10:53 2010
From: wes at ren-isac.net (Wes Young)
Date: Tue, 6 Apr 2010 16:10:53 -0400
Subject: [arin-ppml] Comments on Draft Policy 2010-3: Customer
	Confidentiality
In-Reply-To: <C43F8F3AB0C0E64795715C179C1E86802104050248@WILMA.dmu.edu>
References: <474FEA3C-42FE-401D-A6CB-130973053094@ren-isac.net>
	<C43F8F3AB0C0E64795715C179C1E86802104050248@WILMA.dmu.edu>
Message-ID: <EB02C68E-8379-4789-AE9B-33F99C11671B@ren-isac.net>

Yes. But if it's all obfuscated by the upstream isp, we still have to  
go through the upstream to get to the downstream (unfettered access to  
"last mile" contact information is how we meant it).

example: i have an address, I whois it and it comes back the ISP name,  
but Verizon's contact phone number (as an example) and address. I have  
to now jump through hoops with verizon to "get access" to their  
customer. I may be able to share that information with verizon, I may  
not. Either way, it add's a significant cost.

Or at-least that was my interpretation.

It is my understanding that the "database can be obtained" is valid,  
my question is "will that data contain the last-mile information, or  
whatever the up-stream throws in there"?

My perception was "no, it will not" given the clause:

"The customer's actual information must be provided to ARIN on request  
and will be held in the strictest confidence."

given that ARIN will no longer warehouse this data (again, this is how  
*I* read it anyway). Please correct me if i'm missing something  
obvious though...

On Apr 6, 2010, at 3:58 PM, Davey, George wrote:

> I am concerned about this policy and would like further information:
>
> "unfettered access to contact information in the ARIN registry"
>
> It is my understanding the ARIN database can be obtained on a  
> periodic basis in its entirety so long as the reason can be  
> justified, the user can be verified  and the usage does not allow  
> bulk queries of the data.
> Has this policy changed?
>
> I was able to obtain a copy a few years back for my spam reporting  
> software by signing several documents and proving my identity.
>
>
>
>
>
>
>
>
> George Davey, B.S. MCSE
> Network Administrator
> 3200 Grand Avenue
> Des Moines, IA  50312
> DESK 515.271.1544
> FAX 515.271.7063
> CELL 515.221.2500
> George.Davey at dmu.edu
> www.dmu.edu
>
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]  
> On Behalf Of Wes Young
> Sent: Tuesday, April 06, 2010 1:35 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Comments on Draft Policy 2010-3: Customer  
> Confidentiality
>
> On behalf of the Research and Education Networking Information  
> Sharing and Analysis Center (REN-ISAC), we submit these comments on  
> ARIN Draft Policy 2010-3: Customer Confidentiality, herein referred  
> to as "the Policy".
>
> The mission of the REN-ISAC is to aid and promote cyber security  
> operational protection and response within the higher education and  
> research (R&E) communities. The mission is conducted within the  
> context of a private community of trusted representatives at member  
> institutions, and in service to the R&E community at-large. REN-ISAC  
> serves as the R&E trusted partner for served networks, the formal U.S.
> ISAC community, and in other commercial, governmental, and private  
> security information sharing relationships.
>
> Among the activities conducted, REN-ISAC sends notifications to EDU  
> abuse contacts regarding compromised or otherwise maliciously  
> behaving machines. Hundreds of notifications are sent daily.  
> Numerous commercial, non-commercial, and governmental organizations  
> rely on REN- ISAC's performance in this role, in addition to the  
> EDUs receiving the notifications.
>
> Although the REN-ISAC develops and maintains its own contact  
> database, unfettered access to contact information in the ARIN  
> registry permits us to:
>
> + Identify new or existing institutions that have obtained or returned
> allocated IP space within our scope of concern.
>
> + Identify a technical contact at an institution.
>
> Should the Policy be implemented and adopted, it would hamper our  
> ability to execute the mission. Implications would include:
>
> + Significantly increase lead-times and human interrupts required to
> perform notifications regarding compromised and misbehaving machines.
>
> + Increase the difficulty of identifying a technical contact at the
> organization that is in the best position to deal with a cyber  
> security incident.
>
> + Add a layer of process that would either prevent or inhibit timely
> event notification.
>
> + Add to the costs of performing notifications.
>
> While we appreciate the need for a balance of privacy on the  
> Internet, we don't believe that the Internet or its users would be  
> well-served by confidential registrations at above a /x. The policy  
> would prove to be a detriment to global cyber security. Ultimately  
> it would equate to a reduced ability to deal with active criminal  
> threat.
>
> on behalf of the REN-ISAC,
> --
> Wes Young
> Principal Security Engineer
>

--
Wes
http://claimid.com/wesyoung

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100406/e13be2d2/attachment.sig>

From george at dmu.edu  Tue Apr  6 15:58:07 2010
From: george at dmu.edu (Davey, George)
Date: Tue, 6 Apr 2010 14:58:07 -0500
Subject: [arin-ppml] Comments on Draft Policy 2010-3:
	Customer	Confidentiality
In-Reply-To: <474FEA3C-42FE-401D-A6CB-130973053094@ren-isac.net>
References: <474FEA3C-42FE-401D-A6CB-130973053094@ren-isac.net>
Message-ID: <C43F8F3AB0C0E64795715C179C1E86802104050248@WILMA.dmu.edu>

I am concerned about this policy and would like further information:

"unfettered access to contact information in the ARIN registry"

It is my understanding the ARIN database can be obtained on a periodic basis in its entirety so long as the reason can be justified, the user can be verified  and the usage does not allow bulk queries of the data.
Has this policy changed?

I was able to obtain a copy a few years back for my spam reporting software by signing several documents and proving my identity.







?
George Davey, B.S. MCSE
Network Administrator
3200 Grand Avenue
Des Moines, IA? 50312
DESK 515.271.1544
FAX 515.271.7063
CELL 515.221.2500
George.Davey at dmu.edu
www.dmu.edu



-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Wes Young
Sent: Tuesday, April 06, 2010 1:35 PM
To: arin-ppml at arin.net
Subject: [arin-ppml] Comments on Draft Policy 2010-3: Customer Confidentiality

On behalf of the Research and Education Networking Information Sharing and Analysis Center (REN-ISAC), we submit these comments on ARIN Draft Policy 2010-3: Customer Confidentiality, herein referred to as "the Policy".

The mission of the REN-ISAC is to aid and promote cyber security operational protection and response within the higher education and research (R&E) communities. The mission is conducted within the context of a private community of trusted representatives at member institutions, and in service to the R&E community at-large. REN-ISAC serves as the R&E trusted partner for served networks, the formal U.S.  
ISAC community, and in other commercial, governmental, and private security information sharing relationships.

Among the activities conducted, REN-ISAC sends notifications to EDU abuse contacts regarding compromised or otherwise maliciously behaving machines. Hundreds of notifications are sent daily. Numerous commercial, non-commercial, and governmental organizations rely on REN- ISAC's performance in this role, in addition to the EDUs receiving the notifications.

Although the REN-ISAC develops and maintains its own contact database, unfettered access to contact information in the ARIN registry permits us to:

+ Identify new or existing institutions that have obtained or returned
allocated IP space within our scope of concern.

+ Identify a technical contact at an institution.

Should the Policy be implemented and adopted, it would hamper our ability to execute the mission. Implications would include:

+ Significantly increase lead-times and human interrupts required to
perform notifications regarding compromised and misbehaving machines.

+ Increase the difficulty of identifying a technical contact at the
organization that is in the best position to deal with a cyber security incident.

+ Add a layer of process that would either prevent or inhibit timely
event notification.

+ Add to the costs of performing notifications.

While we appreciate the need for a balance of privacy on the Internet, we don't believe that the Internet or its users would be well-served by confidential registrations at above a /x. The policy would prove to be a detriment to global cyber security. Ultimately it would equate to a reduced ability to deal with active criminal threat.

on behalf of the REN-ISAC,
--
Wes Young
Principal Security Engineer



From Bill.Smith at paypal.com  Tue Apr  6 16:10:41 2010
From: Bill.Smith at paypal.com (Smith, Bill)
Date: Tue, 6 Apr 2010 14:10:41 -0600
Subject: [arin-ppml] Comments on Draft Policy
	2010-3:	Customer	Confidentiality
In-Reply-To: <018901cad5bb$95108950$bf319bf0$@net>
References: <474FEA3C-42FE-401D-A6CB-130973053094@ren-isac.net>
	<018901cad5bb$95108950$bf319bf0$@net>
Message-ID: <39BF0C2785E4044E81A4D55B333D5106611D2ADB14@DEN-MEXMS-001.corp.ebay.com>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Aaron Wendel
> Sent: Tuesday, April 06, 2010 12:02 PM
> To: 'Wes Young'
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] Comments on Draft Policy 2010-3: Customer
> Confidentiality
> 
> Hi Wes,
> 
> Thank you for contributing to the discussion on Draft Policy 2010-3.
> 
> I've been contacted recently by several people who have expressed
> concerns
> such as yours over this policy.  In all cases these people, such as
> yourself, seem to be unaware of the ARIN whois structure or how this
> policy
> changes it.  There are broad assumptions being made that this would do
> away
> with the whois information or somehow "obscure" it and make life tough
> for
> people like yourself.  Most respondents I've talked to have said that
> they
> need to know who ARIN has allocated IP space to.  This proposal does
> nothing
> to change the information that ARIN provides in a public format on who
> IPs
> are allocated to.  It does not obscure any data currently available on
> who
> has IPs from ARIN.

If I understand this argument correctly, Policy Proposal 2010-3 is a request for a policy change that will result in no actual, operational change. If that's the case, why do we need the policy change?

> 
> Since I will be presenting the proposal at the upcoming ARIN meeting
> I'd
> like to get a better idea of what is perpetuating these
> misunderstandings so
> I can present in a way that is understandable to all.  As it stands,
> the
> policy is 2 sentences and does nothing to obscure any information that
> ARIN
> currently reports on the allocations it makes.  If you could help me
> understand what makes you think otherwise it would be a great help to
> me.
> There is still time for me to change the wording of the policy before
> the
> meeting in a week.
> 
> Any help is appreciated.  Thanks for your time.
> 
> Aaron
> 
> 
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Wes Young
> Sent: Tuesday, April 06, 2010 1:35 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Comments on Draft Policy 2010-3: Customer
> Confidentiality
> 
> On behalf of the Research and Education Networking Information Sharing
> and
> Analysis Center (REN-ISAC), we submit these comments on ARIN Draft
> Policy
> 2010-3: Customer Confidentiality, herein referred to as "the Policy".
> 
> The mission of the REN-ISAC is to aid and promote cyber security
> operational
> protection and response within the higher education and research (R&E)
> communities. The mission is conducted within the context of a private
> community of trusted representatives at member institutions, and in
> service
> to the R&E community at-large. REN-ISAC serves as the R&E trusted
> partner
> for served networks, the formal U.S.
> ISAC community, and in other commercial, governmental, and private
> security
> information sharing relationships.
> 
> Among the activities conducted, REN-ISAC sends notifications to EDU
> abuse
> contacts regarding compromised or otherwise maliciously behaving
> machines.
> Hundreds of notifications are sent daily. Numerous commercial,
> non-commercial, and governmental organizations rely on REN- ISAC's
> performance in this role, in addition to the EDUs receiving the
> notifications.
> 
> Although the REN-ISAC develops and maintains its own contact database,
> unfettered access to contact information in the ARIN registry permits
> us to:
> 
> + Identify new or existing institutions that have obtained or returned
> allocated IP space within our scope of concern.
> 
> + Identify a technical contact at an institution.
> 
> Should the Policy be implemented and adopted, it would hamper our
> ability to
> execute the mission. Implications would include:
> 
> + Significantly increase lead-times and human interrupts required to
> perform notifications regarding compromised and misbehaving machines.
> 
> + Increase the difficulty of identifying a technical contact at the
> organization that is in the best position to deal with a cyber security
> incident.
> 
> + Add a layer of process that would either prevent or inhibit timely
> event notification.
> 
> + Add to the costs of performing notifications.
> 
> While we appreciate the need for a balance of privacy on the Internet,
> we
> don't believe that the Internet or its users would be well-served by
> confidential registrations at above a /x. The policy would prove to be
> a
> detriment to global cyber security. Ultimately it would equate to a
> reduced
> ability to deal with active criminal threat.
> 
> on behalf of the REN-ISAC,
> --
> Wes Young
> Principal Security Engineer
> 
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.800 / Virus Database: 271.1.1/2792 - Release Date:
> 04/06/10
> 01:32:00
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From cgrundemann at gmail.com  Tue Apr  6 16:36:33 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 6 Apr 2010 14:36:33 -0600
Subject: [arin-ppml] Comments on Draft Policy 2010-3: Customer
	Confidentiality
In-Reply-To: <EB02C68E-8379-4789-AE9B-33F99C11671B@ren-isac.net>
References: <474FEA3C-42FE-401D-A6CB-130973053094@ren-isac.net>
	<C43F8F3AB0C0E64795715C179C1E86802104050248@WILMA.dmu.edu>
	<EB02C68E-8379-4789-AE9B-33F99C11671B@ren-isac.net>
Message-ID: <p2l443de7ad1004061336j8b600010s67b0666ab19c1864@mail.gmail.com>

On Tue, Apr 6, 2010 at 14:10, Wes Young <wes at ren-isac.net> wrote:
> Yes. But if it's all obfuscated by the upstream isp, we still have to go
> through the upstream to get to the downstream (unfettered access to "last
> mile" contact information is how we meant it).
>
> example: i have an address, I whois it and it comes back the ISP name, but
> Verizon's contact phone number (as an example) and address. I have to now
> jump through hoops with verizon to "get access" to their customer. I may be
> able to share that information with verizon, I may not. Either way, it add's
> a significant cost.
>
> Or at-least that was my interpretation.
>
> It is my understanding that the "database can be obtained" is valid, my
> question is "will that data contain the last-mile information, or whatever
> the up-stream throws in there"?
>
> My perception was "no, it will not" given the clause:
>
> "The customer's actual information must be provided to ARIN on request and
> will be held in the strictest confidence."
>
> given that ARIN will no longer warehouse this data (again, this is how *I*
> read it anyway). Please correct me if i'm missing something obvious
> though...

You are not wrong Wes.  If this policy were to pass, every ISP with an
ARIN allocation could obfuscate the SWIPs for all space allocated to
them. This would cause exactly the disaster you have described.
~Chris

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




-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From owen at delong.com  Tue Apr  6 16:40:05 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 6 Apr 2010 13:40:05 -0700
Subject: [arin-ppml] Comments on Draft Policy 2010-3:
	Customer	Confidentiality
In-Reply-To: <018901cad5bb$95108950$bf319bf0$@net>
References: <474FEA3C-42FE-401D-A6CB-130973053094@ren-isac.net>
	<018901cad5bb$95108950$bf319bf0$@net>
Message-ID: <E0698F5D-4DD4-4310-8317-E174E7524217@delong.com>


On Apr 6, 2010, at 12:01 PM, Aaron Wendel wrote:

> Hi Wes,
> 
> Thank you for contributing to the discussion on Draft Policy 2010-3.  
> 
> I've been contacted recently by several people who have expressed concerns
> such as yours over this policy.  In all cases these people, such as
> yourself, seem to be unaware of the ARIN whois structure or how this policy
> changes it.  There are broad assumptions being made that this would do away
> with the whois information or somehow "obscure" it and make life tough for
> people like yourself.  Most respondents I've talked to have said that they
> need to know who ARIN has allocated IP space to.  This proposal does nothing
> to change the information that ARIN provides in a public format on who IPs
> are allocated to.  It does not obscure any data currently available on who
> has IPs from ARIN.
> 
While this is technically true, I do not believe it is an accurate reflection of
the net effects of the policy proposal. The proposal would allow ISPs to
anonymize and/or remove significant information from records currently
published in whois as well as allowing them to not submit much of that
information to publication in the future.

I think that the issue is you are making a distinction between who has IP
addresses DIRECTLY from ARIN vs. who has IP addresses from an
upstream which received them either directly or indirectly from ARIN.

I believe that Wes and others who have commented actually care about
who the end-user of an IP address block is rather than merely who it was
issued to by ARIN.

Wes, could you please clarify your intent here?

Thanks,

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100406/aa0ede31/attachment.htm>

From cgrundemann at gmail.com  Tue Apr  6 17:07:00 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 6 Apr 2010 15:07:00 -0600
Subject: [arin-ppml] Policy Proposal 109: Standardize IP Reassignment
	Registration Requirements - Revised
In-Reply-To: <4B8FAD94.2040509@arin.net>
References: <4B8FAD94.2040509@arin.net>
Message-ID: <w2l443de7ad1004061407m5021999v90a1f21057386780@mail.gmail.com>

With the renewed conversations regarding draft policy 2010-3 I thought
it may be appropriate to remind everyone of the proposal that I wrote
in response to earlier debate surrounding this issue: policy proposal
109.

Unfortunately my proposal will not be up for adoption in Toronto,
however I will be presenting it along side the open policy hour on
Sunday afternoon (come throw tomatoes).

The reason I bring it up now is that I believe it strikes a fair
balance between the need for complete whois data, residential customer
privacy, and protecting corporate customer lists.

Specific to the third point: Under pp109, the legal name, city, state,
zip code equivalent and one POC is required for every SWIP'd block
(/29 or larger IPv4, /56 or larger IPv6). Street name and number are
optional as is POC telephone number (email address is required).

This means that the specific contact information most valuable to
competing sales teams (street address and phone number) is optional,
allowing you to protect your customer list if needed while still
allowing security and abuse personnel to understand who is (whois)
actually using any particular block of IPs.

There are other factors at play in this policy of course (as it is a
complete re-write of both IPv4 and IPv6 registration policy) and the
full text and rational is included below.
~Chris


On Thu, Mar 4, 2010 at 06:54, Member Services <info at arin.net> wrote:
> The proposal originator submitted a revised version of the proposal.
>
> The AC will review this proposal at their next regularly scheduled
> meeting and decide how to utilize the proposal. Their decision will be
> announced to the PPML.
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
> ## * ##
>
> Policy Proposal Name: Standardize IP Reassignment Registration Requirements
>
> Proposal Originator: Chris Grundemann
>
> Proposal Version: 3.0
>
> Date: 03-MAR-2010
>
> Proposal type: New
>
> Policy term: Permanent
>
> Policy statement:
>
> ## Definitions ##
>
> - Add:
>
> 2.3. Organizational Information
>
> When required, organization Information must include at a minimum: Legal
> name, city, state, zip code equivalent and at least one valid technical or
> abuse POC; inclusion of street address is highly encouraged. The POC shall
> be designated by the organization and must include at least one verifiable
> email address, inclusion of a phone number is highly encouraged.
>
> 2.12. Residential Customer
>
> End-users who are individual persons and not organizations and who recieve
> service at a place of residence are considered residential customers.
>
> ## IPv4 ##
>
> - Rename 4.2.3.7. "Reassignment information" to "Registration" and add text:
>
> ISPs are required to demonstrate efficient use of IP address space
> allocations by providing appropriate documentation, including assignment
> histories, showing their efficient use.
>
> - Rename 4.2.3.7.1. "Customer organization information" to "Reassignment
> Information" and replace text with:
>
> Each IPv4 assignment containing a /29 or more addresses shall be registered
> in the WHOIS directory via SWIP or a distributed service which meets the
> standards set forth in section 3.2. Reassignment registrations shall include
> each client's organizational information, except where specifically exempted
> by this policy.
>
> - Strike sections 4.2.3.7.2., 4.2.3.7.4. and 4.2.3.7.5.
>
> - Renumber section 4.2.3.7.3. to 4.2.3.7.2., rename to "Assignments visible
> within 7 days" and replace text with:
>
> All assignments shall be made visible as required in section 4.2.3.7.1
> within seven calendar days of assignment.
>
> - Renumber and replace 4.2.3.7.6. Residential Customer Privacy with:
>
> 4.2.3.7.3. Residential Subscribers
>
> 4.2.3.7.3.1. Residential Market Area
>
> ISPs that assign address space to the infrastructure to which their
> customers connect rather than to individual subscribers must register
> assignment information regarding each market area holding such an address
> block. Market area reassignments shall be registered with the network name
> used to identify each market area. Any assignment to specific end-users
> holding /29 and larger blocks still requires registration. A >50%
> utilization rate shall be considered efficient for market area reassignments
> from the ISPs most recent allocation.
>
> 4.2.3.7.3.2. Residential Customer Privacy
>
> To maintain the privacy of their residential customers, an organization with
> downstream residential customers holding /29 and larger blocks may
>
> substitute that organization's name for the customer's name, e.g. 'Private
> Customer - XYZ Network', and the customer's street address may read 'Private
> Residence'. Each private downstream residential reassignment must have
> accurate upstream Abuse and Technical POCs visible on the WHOIS directory
> record for that block.
>
> - Strike section 4.2.6. "Cable Address Space Policy"
>
> ## IPv6 ##
>
> - Replace Section 6.5.5. with:
>
> 6.5.5. Registration
>
> ISPs are required to demonstrate efficient use of IP address space
> allocations by providing appropriate documentation, including assignment
> histories, showing their efficient use.
>
> 6.5.5.1. Reassignment information
>
> Each IPv6 assignment containing a /56 or more addresses shall be registered
> in the WHOIS directory via SWIP or a distributed service which meets the
> standards set forth in section 3.2. Reassignment registrations shall include
> each client's organizational information, except where specifically exempted
> by this policy.
>
> 6.5.5.2. Assignments visible within 7 days
>
> All assignments shall be made visible as required in section 4.2.3.7.1
> within seven calendar days of assignment.
>
> 6.5.5.3. Residential Subscribers
>
> 6.5.5.3.1. Residential Market Area
>
> ISPs that assign address space to the infrastructure to which their
> customers connect rather than to individual subscribers must register
> assignment information regarding each market area holding such an address
> block. Market area reassignments shall be registered with the network name
> used to identify each market area. Any assignment to specific end-users
> holding /56 and larger blocks still requires registration. A >50%
> utilization rate shall be considered efficient for market area reassignments
> from the ISPs most recent allocation.
>
>
> 6.5.5.3.2. Residential Customer Privacy
>
> To maintain the privacy of their residential customers, an organization with
> downstream residential customers holding /56 and larger blocks may
> substitute that organization's name for the customer's name, e.g. 'Private
> Customer - XYZ Network', and the customer's street address may read 'Private
> Residence'. Each private downstream residential reassignment must have
> accurate upstream Abuse and Technical POCs visible on the WHOIS record for
> that block.
>
>
> Rationale:
>
> #New and Improved! Specific changes in this version (based on Staff and PPML
> comments):
> 1) Added section 2.12. to define residential customers. There is no current
> definition of residential customers and this has reportedly been an on-going
> problem for ARIN and it?s customers.
> 2) 4.2.3.7. and 6.5.5. were re-written to include current text in order to
> aid ARIN staff when requesting detailed utilization information as part of
> the normal request process.
> 3) 4.2.3.7.1. and 6.5.5.1. were re-written to simplify policy by combining
> the /29 and /56 rules as well as the WHOIS directory visibility requirements
> directly in a single statement (thanks to Owen DeLong for the suggestion).
> 3) Several sections were struck do to the clarity and detail gained in
> revision 3, above.
> 4) The "7-day" provision was renamed and rewritten for clarity (thanks again
> to Owen DeLong for the wording).
> 5) 4.2.3.7.3.1 & 6.5.5.3.1 were re-written for clarity based on many
> comments on and off list.
>
> #Short Rational:
> This proposal intends to do several things:
> 1) Bring IPv4 and IPv6 policy more in line with each other to make the NRPM
> easier to understand and comply with - at least as it relates to
> reassignment information.
> 2) Specifically define what organizational information is required to be
> added to WHOIS when reassignments are made to client organizations.
> 3) To specifically state that a client organization may designate the POC of
> their choice for any/all WHOIS entries in policy. This includes designating
> an upstream POC as their own prefered POC (which allows for simple
> reassignments).
> 4) Expands the priviledges previously reserved solely for IPv4 cable ISPs to
> all ISPs/LIRs with residential/dhcp-type subscribers.
> 5) Specifically define the term "residential customer."
>
> #Expanded Rational:
> 1) This policy restructures the reassignment and registration sections
> of the IPv4 and IPv6 policies.
> a) The IPv4 section is renamed "registration."
> b) The IPv4 policy is shortened and rewritten for clarity.
> c) The IPv6 policy is totally rewritten in a format that matches the IPv4
> policy.
> * These structural changes are meant to make it easier to compare the two
> sections. I believe that having the IPv6 and IPv4 policies written in
> completely different formats and structures (as they are in many cases now)
> confuses the issues and makes it very hard to understand what is different
> and what is the same across the two sections. Bringing them into a similar
> format should help ease the migration to IPv6 as folks can quickly and
> easily understand the differences and the similarities.
>
> 2) This policy adds a definition of "organizational information" which is
> used in the existing policy but not currently defined anywhere in the NRPM.
> a) The definition states that specific addresses are not required for client
> organizations but asks that they be included when possible.
> b) The definition states that a POC is required but can be designated by the
> client organization - it spells out that the client org can choose to use
> their upstream as a POC.
> c) The definition requires that the POC have a valid email address but only
> suggests that it include a phone number.
> * This definition is meant to address the customer confidentiality concerns
> that have been brought up recently (by specifically removing the requirement
> to publish client addresses and telephone numbers), with the smallest
> negative impact to whois usefulness (retains a valid POC w/ email contact).
>
> 3) This policy takes the privileges granted specifically to IPv4 cable
> operators in section 4.2.6. "Cable Address Space Policy" and grants them to
> all ISPs who serve residential areas.
> a) It allows all ISPs with residential coverage to register/swip/rwhois an
> entire market area.
> b) It retains the existing residential customer privacy policy for all
> customers with larger IP blocks.
> * This change removes the need for any ISP to enter residential customers
> into whois at all.
>
> 4) This policy also extends the >50% utilization rate, currently granted
> only to IPv4 cable operators, to all ISPs with a residential footprint.
> * This change will make it easier for ISPs serving residential areas to get
> the addresses they need - this is key for FTTH operators as well as
> fixed-wireless and other residential ISPs.
> *The 50% mark on the most recent allocation is because you can quickly
> distribute most of your address space across your provisioning footprint,
> leaving nothing left for growth while the lease count of the provisioned
> customers catches up to the blocks allocated. (Dan Alexander's words)
>
> 5) Current policy references "residential customers" but there is no current
> definition of residential customers in the NRPM. This has reportedly been an
> on-going problem for ARIN and it?s customers.
>
>
> Timetable for implementation: Immediate
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From jay at impulse.net  Tue Apr  6 17:27:51 2010
From: jay at impulse.net (Jay Hennigan)
Date: Tue, 06 Apr 2010 14:27:51 -0700
Subject: [arin-ppml] Comments on Draft Policy
	2010-3:	Customer	Confidentiality
In-Reply-To: <6D251AF0-1FE5-4184-9032-014EBCB9E6CB@ren-isac.net>
References: <474FEA3C-42FE-401D-A6CB-130973053094@ren-isac.net>	<018901cad5bb$95108950$bf319bf0$@net>
	<6D251AF0-1FE5-4184-9032-014EBCB9E6CB@ren-isac.net>
Message-ID: <4BBBA757.2020500@impulse.net>

On 4/6/10 12:51 PM, Wes Young wrote:

> "ISPs may choose to enter the customer's name along with the ISP's
> address and phone number in reassignments and reallocations in lieu of
> the customer's address and phone number. The customer's actual
> information must be provided to ARIN on request and will be held in the
> strictest confidence."
> 
> Those "two lines" (at-least to me), represent sort of the "domains by
> proxy feature".
> 
> When dealing with security incidents, if the contact information is
> virtually proxy'd, then thats more time/money spent trying to get a-hold
> of someone close enough to the problem to do away with it. A single
> domain can't wipe out half of the internet, a single address (or set of
> addresses, or /29--) could. When we can't keep track of those closest to
> the situation (who care about the situation), the threat potential
> increases.

I have to respectfully disagree.  The vast majority of our customers are
small to medium sized businesses who have very little operational clue.
 Law firms, insurance agents, warehouse firms, etc.  The contacts at the
phone number or physical address of these operations can barely spell
BGP, let alone describe it.

As their ISP, we are much more likely to able to do away with any
problems that they may create than their on-premise staff.

Listing their phone number and address instead of ours results in total
confusion as their receptionist is likely to want to have someone call
you back.  And that someone is likely to be "Geek Squad" or equivalent
LAN vendor after a lengthy delay if at all.  Good luck reaching anything
other than voice mail evenings and weekends.  Considering the number of
scams going on, that receptionist is likely to be highly suspicious of a
phone call from some stranger speaking what will seem to be gibberish
about some computer security issue and asking them to disconnect
themselves from the Internet or shut off an offending host.

Calling a clueful ISP and being able to reach a NOC person with the
ability to deal with the problem when a customer gets pwn3d at 02:00
local time on a Sunday morning is going to be much more useful than
leaving a voice mail for the receptionist at the wholesale carpet
distributor whose server got hacked.

> I understand what you say about the change in allocations, maybe that
> shouldn't have been listed as a primary reason (more so than the
> obfuscation of "last mile" contact information). However, the very thing
> you're trying to protect against (eg: customer lists), is one of the
> very things security ops handlers are trying to build up and keep
> current. The public information in an unstructured and federated
> environment helps us do that. It is only two sentences, and that's
> dangerous when you're setting a standard for the backbone of the
> federated environment that is the internet.

The change is the *ability* to list the ISP's contact number and
address, not a *requirement* to do so.  For cases where the end user
customer has a security and technical staff that is willing able to deal
with these issues when they come up, said staff will probably want to
have their own contact number listed in WHOIS.  Indeed it should be.

If anything, I view this proposal as facilitating, not hindering, rapid
response to security incidents by those with the knowledge and ability
to deal with them.

Note that this proposal in my opinion is better for *technical* reasons,
without regard to any business and privacy concerns driving it.

-- 
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV


From marty at akamai.com  Tue Apr  6 17:46:35 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Tue, 06 Apr 2010 17:46:35 -0400
Subject: [arin-ppml] Policy Proposal 109: Standardize IP Reassignment
 Registration Requirements - Revised
In-Reply-To: <w2l443de7ad1004061407m5021999v90a1f21057386780@mail.gmail.com>
Message-ID: <C7E123FB.2BC4F%marty@akamai.com>



> From: Chris Grundemann <cgrundemann at gmail.com>
> Date: Tue, 6 Apr 2010 15:07:00 -0600
> To: arin ppml <ppml at arin.net>
> Subject: Re: [arin-ppml] Policy Proposal 109: Standardize IP Reassignment
> Registration Requirements - Revised
> 
> With the renewed conversations regarding draft policy 2010-3 I thought
> it may be appropriate to remind everyone of the proposal that I wrote
> in response to earlier debate surrounding this issue: policy proposal
> 109.
> 

Honestly? I don't think that it's helpful at all and I mean that in a
"helpful" way. :-) We lose focus _a lot_ on the proposals at hand, both on
the list and through other "mechanisms". That has happened with this
proposal. I think that the spate of recent comments has helped to regain
that focus; this proposal is not truly addressing what it was intended to.
For that matter, I think that the ARIN should not get dragged into this
scrum and let competition be competition. Whois is inaccurate, you can
accomplish exactly the same thing using other, similarly easy, cheap and
perhaps even more accurate, means

Also, who will reach ARIN in an exigent circumstance, at 0500, on Sunday
morning to ask them to ask someone else for something that we should be able
to ask for related to internet security, personal safety or other valid
reason? I don't think that we should have to pay for that or any other
"service" to provide competition protection.

To be clear; not in favor.


Best Regards,

-M<




From cgrundemann at gmail.com  Tue Apr  6 18:26:48 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 6 Apr 2010 16:26:48 -0600
Subject: [arin-ppml] Policy Proposal 109: Standardize IP Reassignment
	Registration Requirements - Revised
In-Reply-To: <C7E123FB.2BC4F%marty@akamai.com>
References: <w2l443de7ad1004061407m5021999v90a1f21057386780@mail.gmail.com>
	<C7E123FB.2BC4F%marty@akamai.com>
Message-ID: <t2r443de7ad1004061526yfa85527due42c568c95b3bf01@mail.gmail.com>

On Tue, Apr 6, 2010 at 15:46, Hannigan, Martin <marty at akamai.com> wrote:
>
>
>> From: Chris Grundemann <cgrundemann at gmail.com>
>> Date: Tue, 6 Apr 2010 15:07:00 -0600
>> To: arin ppml <ppml at arin.net>
>> Subject: Re: [arin-ppml] Policy Proposal 109: Standardize IP Reassignment
>> Registration Requirements - Revised
>>
>> With the renewed conversations regarding draft policy 2010-3 I thought
>> it may be appropriate to remind everyone of the proposal that I wrote
>> in response to earlier debate surrounding this issue: policy proposal
>> 109.
>>
>
> Honestly? I don't think that it's helpful at all and I mean that in a
> "helpful" way. :-) We lose focus _a lot_ on the proposals at hand, both on
> the list and through other "mechanisms". That has happened with this
> proposal. I think that the spate of recent comments has helped to regain
> that focus; this proposal is not truly addressing what it was intended to.

Point taken. I do not wish to muddy the water. I still think that
understanding the currently offered policy options and seeing another
take on the issue may be helpful to some.

> For that matter, I think that the ARIN should not get dragged into this
> scrum and let competition be competition. Whois is inaccurate, you can
> accomplish exactly the same thing using other, similarly easy, cheap and
> perhaps even more accurate, means

To dissect this a bit:
1) "Whois is inaccurate" - Agreed but with hopes that we can (even if
slowly) fix that.
2) "you can accomplish the same thing..." - Do you mean gathering
customer lists or gathering abuse and technical POCs? I agree with the
former but not as much the latter. Whois with all it's flaws is still
the best first choice for making those contacts.

> Also, who will reach ARIN in an exigent circumstance, at 0500, on Sunday
> morning to ask them to ask someone else for something that we should be able
> to ask for related to internet security, personal safety or other valid
> reason? I don't think that we should have to pay for that or any other
> "service" to provide competition protection.

My policy intends to avoid this. I agree that 2010-3 could very well
cause this problem.

> To be clear; not in favor.

Fair enough, but based on your last paragraph I have a suspicion that
you may misunderstand this proposal (or I may just misunderstand you
;)).

Cheers,
~Chris

> Best Regards,
>
> -M<
>
>

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From steve at ibctech.ca  Tue Apr  6 19:17:10 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Tue, 06 Apr 2010 19:17:10 -0400
Subject: [arin-ppml] Comments on Draft
	Policy	2010-3:	Customer	Confidentiality
In-Reply-To: <4BBBA757.2020500@impulse.net>
References: <474FEA3C-42FE-401D-A6CB-130973053094@ren-isac.net>	<018901cad5bb$95108950$bf319bf0$@net>	<6D251AF0-1FE5-4184-9032-014EBCB9E6CB@ren-isac.net>
	<4BBBA757.2020500@impulse.net>
Message-ID: <4BBBC0F6.8050007@ibctech.ca>

On 2010.04.06 17:27, Jay Hennigan wrote:
> On 4/6/10 12:51 PM, Wes Young wrote:
> 
>> "ISPs may choose to enter the customer's name along with the ISP's
>> address and phone number in reassignments and reallocations in lieu of
>> the customer's address and phone number. The customer's actual
>> information must be provided to ARIN on request and will be held in the
>> strictest confidence."
>>
>> Those "two lines" (at-least to me), represent sort of the "domains by
>> proxy feature".
>>
>> When dealing with security incidents, if the contact information is
>> virtually proxy'd, then thats more time/money spent trying to get a-hold
>> of someone close enough to the problem to do away with it. A single
>> domain can't wipe out half of the internet, a single address (or set of
>> addresses, or /29--) could. When we can't keep track of those closest to
>> the situation (who care about the situation), the threat potential
>> increases.
> 
> I have to respectfully disagree. The vast majority of our customers are
> small to medium sized businesses who have very little operational clue.
>  Law firms, insurance agents, warehouse firms, etc.  The contacts at the
> phone number or physical address of these operations can barely spell
> BGP, let alone describe it.

The vast majority of my customers are exactly the same.

> As their ISP, we are much more likely to able to do away with any
> problems that they may create than their on-premise staff.

Agreed.

> Listing their phone number and address instead of ours results in total
> confusion as their receptionist is likely to want to have someone call
> you back.  

Even if an operator is half-baked, they still should know that it's
trivial to look up the POCs for the encompassing block in the event that
a receptionist responds with "no" when one asks "do you have a computer
technician that looks after your stuff?".

Better yet, I throw it right into the SWIP 'Comments' section, just to
be safe:

Comment:    For other issues, or if the above contacts
Comment:    are non-responsive, contact the ARIN POC registered
Comment:    to the encompassing IP block.

Any person who values WHOIS for operational purposes will be able to
glean the info they need, and will be able to identify whether the
person on the other end of the phone is 'unresponsive' (such as a
receptionist).

What happens if a scrupulous LIR was getting paid for a client that was
abusing my network, but had their personal information hidden? I
couldn't create a baseline or filtering strategy based on IP, because
they could just move them to another block. I can't monitor based on
customer name, because it's 'protected'. Hence, I may be dealing with a
moving target, with absolutely no classification ability to provide my
upstreams with for aid.

Personally, I don't care about the privacy of my clients. They are on
the global Internet, and with that goes your privacy (as far as IP
addressing is concerned). I can't cross the Canada/US border anymore
without identifying exactly who I am and what my address is, and I see
no difference in this. I just like to know that if someone calls my
client or myself, they'd be able to inform me immediately who is
originating an issue so I can fix it.

> Calling a clueful ISP and being able to reach a NOC person with the
> ability to deal with the problem when a customer gets pwn3d at 02:00
> local time on a Sunday morning is going to be much more useful than
> leaving a voice mail for the receptionist at the wholesale carpet
> distributor whose server got hacked.

Fixed in the 'comments' section, or by gleaning the POCs of the parent
block.

>> I understand what you say about the change in allocations, maybe that
>> shouldn't have been listed as a primary reason (more so than the
>> obfuscation of "last mile" contact information). However, the very thing
>> you're trying to protect against (eg: customer lists), is one of the
>> very things security ops handlers are trying to build up and keep
>> current. The public information in an unstructured and federated
>> environment helps us do that. It is only two sentences, and that's
>> dangerous when you're setting a standard for the backbone of the
>> federated environment that is the internet.
> 
> The change is the *ability* to list the ISP's contact number and
> address, not a *requirement* to do so.  For cases where the end user
> customer has a security and technical staff that is willing able to deal
> with these issues when they come up, said staff will probably want to
> have their own contact number listed in WHOIS.  Indeed it should be.
> 
> If anything, I view this proposal as facilitating, not hindering, rapid
> response to security incidents by those with the knowledge and ability
> to deal with them.

How do we know that you are not going to 'fix' the problem by rendering
the client a new block? When they attack next week, and we call you
again, how can we identify whether it is another one of your clients, or
the same one?

> Note that this proposal in my opinion is better for *technical* reasons,
> without regard to any business and privacy concerns driving it.

I completely understand what your stance is on this and why you feel
this way, as seemingly we have a similar type of client base. However,
you, like I, are the ones who *will* properly fix a problem when
required. I'm concerned about the ones who will use this as a loophole
to avoid that.

Respectfully,

Steve


From jay at impulse.net  Tue Apr  6 20:11:02 2010
From: jay at impulse.net (Jay Hennigan)
Date: Tue, 06 Apr 2010 17:11:02 -0700
Subject: [arin-ppml] Comments on Draft
	Policy	2010-3:	Customer	Confidentiality
In-Reply-To: <4BBBC0F6.8050007@ibctech.ca>
References: <474FEA3C-42FE-401D-A6CB-130973053094@ren-isac.net>	<018901cad5bb$95108950$bf319bf0$@net>	<6D251AF0-1FE5-4184-9032-014EBCB9E6CB@ren-isac.net>
	<4BBBA757.2020500@impulse.net> <4BBBC0F6.8050007@ibctech.ca>
Message-ID: <4BBBCD96.9090801@impulse.net>

On 4/6/10 4:17 PM, Steve Bertrand wrote:

> Even if an operator is half-baked, they still should know that it's
> trivial to look up the POCs for the encompassing block in the event that
> a receptionist responds with "no" when one asks "do you have a computer
> technician that looks after your stuff?".

The receptionist is likely to respond with a LAN vendor that may or may
not be in a position to fix the issue.  It may be trivial to look up the
POC for the encompassing block but it is another step, another phone
call or conversation, more delay, etc.

The ISP of a non-technical customer is likely to be more knowledgeable
regarding his customer's network than the receptionist and probably in a
better position to work directly with any other local vendors and
consultants.  Also the ISP is in a position to down an interface or add
an ACL *right now* in serious cases.

The end customer isn't going to want to spend money on a consultant to
fix something that isn't a problem (to them), and hasn't heard of some
remote network operator calling with a complaint.  And if the customer's
phone number is published in WHOIS, they'll likely dismiss any such
calls as just another  telemarketer.  (Telemarketers are the only ones
that ever call that number we were forced to publish, that's why we
never check that voice mail...)

> Better yet, I throw it right into the SWIP 'Comments' section, just to
> be safe:
> 
> Comment:    For other issues, or if the above contacts
> Comment:    are non-responsive, contact the ARIN POC registered
> Comment:    to the encompassing IP block.
> 
> Any person who values WHOIS for operational purposes will be able to
> glean the info they need, and will be able to identify whether the
> person on the other end of the phone is 'unresponsive' (such as a
> receptionist).

More work, more clutter, and more steps.

> What happens if a scrupulous LIR was getting paid for a client that was
> abusing my network, but had their personal information hidden? I
> couldn't create a baseline or filtering strategy based on IP, because
> they could just move them to another block. I can't monitor based on
> customer name, because it's 'protected'. Hence, I may be dealing with a
> moving target, with absolutely no classification ability to provide my
> upstreams with for aid.

I think you mean UNscrupulous LIR.

The customer name is not "protected" from what I read in the proposal.
The phone number and street address are.  If the customer is a
deliberate abuser, the phone number and contact information of said
abuser are going to be worthless.  Usually it's a virus/bot/smurf
amplifier type of issue where the customer is either unaware of the
problem or just notices that things are slow.

If the LIR is unscrupulous and deliberately supporting abusers, they
wouldn't have a problem with entering completely bogus SWIPs anyway.
This change isn't going to change the behavior of dishonest and
unscrupulous LIRs.  It is going to result in valid POCs of those in a
position to fix problems without having to deal with non-technical people.

Dishonest and abusive people will continue to be dishonest and abusive
regardless of the rules.

> Personally, I don't care about the privacy of my clients. They are on
> the global Internet, and with that goes your privacy (as far as IP
> addressing is concerned). I can't cross the Canada/US border anymore
> without identifying exactly who I am and what my address is, and I see
> no difference in this. I just like to know that if someone calls my
> client or myself, they'd be able to inform me immediately who is
> originating an issue so I can fix it.

Agreed, but in the majority of cases when they call your client they are
going to get little in the way of fixing.  They will wind up calling you
eventually anyway.  Why not have that be the first call they make?

> How do we know that you are not going to 'fix' the problem by rendering
> the client a new block? When they attack next week, and we call you
> again, how can we identify whether it is another one of your clients, or
> the same one?

See above.  And does it matter?  If you're an unscrupulous ISP that
deliberately harbors abusers, does the rest of the Internet care which
particular IP maps to which particular abuser today or next week or are
they likely to just refuse all of your packets?

>> Note that this proposal in my opinion is better for *technical* reasons,
>> without regard to any business and privacy concerns driving it.
> 
> I completely understand what your stance is on this and why you feel
> this way, as seemingly we have a similar type of client base. However,
> you, like I, are the ones who *will* properly fix a problem when
> required. I'm concerned about the ones who will use this as a loophole
> to avoid that.

I don't think this proposal will make a difference one way or another to
criminals and deliberate abusers.  It will result in faster resolution
of those cases where the actual user of the IP space is non-technical or
not staffed 24/7 by providing an immediate lookup of a contact more
likely to have the ability to resolve problems quickly and competently.

-- 
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV


From aaron at wholesaleinternet.net  Tue Apr  6 21:39:15 2010
From: aaron at wholesaleinternet.net (Aaron Wendel)
Date: Tue, 6 Apr 2010 20:39:15 -0500
Subject: [arin-ppml] Comments on
	Draft	Policy	2010-3:	Customer	Confidentiality
In-Reply-To: <4BBBC0F6.8050007@ibctech.ca>
References: <474FEA3C-42FE-401D-A6CB-130973053094@ren-isac.net>	<018901cad5bb$95108950$bf319bf0$@net>	<6D251AF0-1FE5-4184-9032-014EBCB9E6CB@ren-isac.net>	<4BBBA757.2020500@impulse.net>
	<4BBBC0F6.8050007@ibctech.ca>
Message-ID: <029401cad5f3$21ef4aa0$65cddfe0$@net>

What would people think if the policy was altered to distinguish between an
"end user" class and a "reseller" class of customer where the requirements
would be to disclose full information on the reseller, which would be
someone reselling network services such as web hosting, VPS' or even another
ISP, and someone hosting their corporate e-mail and web site?

The former should have a clue and be able to deal with network abuse issues
while the latter is more likely to just be confused and ignore complaints.
It would also protect those customers who are more likely to be "poached"
as, at least in my case, the resellers have more interaction with me or my
staff and therefore have a stronger relationship.

Right now my count has the yays and nays running just about dead even.  This
suggestion was offered as a possible compromise by one of the nays.

Aaron




From steve at ibctech.ca  Tue Apr  6 21:40:13 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Tue, 06 Apr 2010 21:40:13 -0400
Subject: [arin-ppml] Comments on
	Draft	Policy	2010-3:	Customer	Confidentiality
In-Reply-To: <4BBBCD96.9090801@impulse.net>
References: <474FEA3C-42FE-401D-A6CB-130973053094@ren-isac.net>	<018901cad5bb$95108950$bf319bf0$@net>	<6D251AF0-1FE5-4184-9032-014EBCB9E6CB@ren-isac.net>	<4BBBA757.2020500@impulse.net>
	<4BBBC0F6.8050007@ibctech.ca> <4BBBCD96.9090801@impulse.net>
Message-ID: <4BBBE27D.1010601@ibctech.ca>

On 2010.04.06 20:11, Jay Hennigan wrote:
> On 4/6/10 4:17 PM, Steve Bertrand wrote:
> 
>> Even if an operator is half-baked, they still should know that it's
>> trivial to look up the POCs for the encompassing block in the event that
>> a receptionist responds with "no" when one asks "do you have a computer
>> technician that looks after your stuff?".
> 
> The receptionist is likely to respond with a LAN vendor that may or may
> not be in a position to fix the issue.  It may be trivial to look up the
> POC for the encompassing block but it is another step, another phone
> call or conversation, more delay, etc.

Understood. However, I would rather have to take one extra one-minute
step to validate via a phone call that the person I'm calling is who
they are reported to be before I need to do a one second lookup to find
out who you are and how to contact you.

At least I'll know they are who you say they are, and will know for the
future that they have clueless monkeys on call for 'network
maintenance'. In the long run, I believe a potential extra step is worth it.

> The ISP of a non-technical customer is likely to be more knowledgeable
> regarding his customer's network than the receptionist and probably in a
> better position to work directly with any other local vendors and
> consultants.  Also the ISP is in a position to down an interface or add
> an ACL *right now* in serious cases.
> 
> The end customer isn't going to want to spend money on a consultant to
> fix something that isn't a problem (to them), and hasn't heard of some
> remote network operator calling with a complaint.  

Even if I'm more knowledgeable in an emergency and I have to shut a
client interface, then it is clear that the client is in need of
spending money to fix a problem anyways.

This potentially results in wasted time for you up front, or extra time
for me later when we're questioned about why they are down without any
prior engagement. Someone will always lose something in a situation like
this... I'm just trying to look at it from the perspective of what can
be gained.

> And if the customer's
> phone number is published in WHOIS, they'll likely dismiss any such
> calls as just another  telemarketer.  (Telemarketers are the only ones
> that ever call that number we were forced to publish, that's why we
> never check that voice mail...)

Fair enough. However, that is attempting to evade anyways, so it doesn't
matter. Every company has a published number for business. You, having
them as a client surely know it somehow.

> I think you mean UNscrupulous LIR.

Thanks ;)

> The customer name is not "protected" from what I read in the proposal.
> The phone number and street address are.  If the customer is a
> deliberate abuser, the phone number and contact information of said
> abuser are going to be worthless. 

I don't believe that. Even though I'm afraid of retribution for saying
this, I feel that re-assignment information of a client is the
responsibility of the re-assigning party.

If people want ARIN to validate the POCs of it's re-alloc/assignments,
then we, as peers, should have the ability to randomly call each other
up and say "hey, does this client still `own' this block?".

I'm likely way off-base here, and perhaps I'm completely missing
something, but:

"If the customer is a
deliberate abuser, the phone number and contact information of said
abuser are going to be worthless. "

...then the re-assigning party should be flamed and noted for not doing
its due diligence in the first place.

>  Usually it's a virus/bot/smurf
> amplifier type of issue where the customer is either unaware of the
> problem or just notices that things are slow.

Usually, yes. However, ignorance is in no way allowed as an excuse.

> If the LIR is unscrupulous and deliberately supporting abusers, they
> wouldn't have a problem with entering completely bogus SWIPs anyway.
> This change isn't going to change the behavior of dishonest and
> unscrupulous LIRs.  It is going to result in valid POCs of those in a
> position to fix problems without having to deal with non-technical people.

A rogue LIR is always going to try to circumvent the legal/policy anyways.

For those LIRs who aren't unscrupulous, it allows for finer grain
monitoring, better statistical gathering, easier documentation, better
peer-to-peer communication. iow, I believe that having the client info
in the db (even if your phone number is beside the clients) will serve
the entire community better in the long run.

> Dishonest and abusive people will continue to be dishonest and abusive
> regardless of the rules.

Yup, but they'd be easier to filter out.

>> Personally, I don't care about the privacy of my clients. They are on
>> the global Internet, and with that goes your privacy (as far as IP
>> addressing is concerned). I can't cross the Canada/US border anymore
>> without identifying exactly who I am and what my address is, and I see
>> no difference in this. I just like to know that if someone calls my
>> client or myself, they'd be able to inform me immediately who is
>> originating an issue so I can fix it.
> 
> Agreed, but in the majority of cases when they call your client they are
> going to get little in the way of fixing.  They will wind up calling you
> eventually anyway.  Why not have that be the first call they make?

Well, one reason, I'd like my client know that the situation is being
initiated externally. A serious person is calling to investigate a
potentially serious problem.

To further, it allows the caller to identify that they are speaking
directly to the people who are listed in WHOIS. It provides confidence
to them to know that they are headed in the proper direction.

$receptionist at the counter could say via phone at 1400 that "yes, this
is X company". Even if (s)he couldn't identify her ISP or her tech, the
caller would (imho) merrily take that extra step to see who the next
contact in the hierarchy is given the confidence (s)he has gained.

>> How do we know that you are not going to 'fix' the problem by rendering
>> the client a new block? When they attack next week, and we call you
>> again, how can we identify whether it is another one of your clients, or
>> the same one?
> 
> See above.  And does it matter?  If you're an unscrupulous ISP that
> deliberately harbors abusers, does the rest of the Internet care which
> particular IP maps to which particular abuser today or next week or are
> they likely to just refuse all of your packets?

I'm not the rest of the Internet, but if I know that you have an abuser
that you admit to having intermittent problems with, I'd rather throw a
/28 into my infrastructure than have my users calling because I've had
to blackhole your /16.

...and yes. I do believe that there are some who still care which block
maps to which user. I personally believe that this research is important
for historical purposes.

>>> Note that this proposal in my opinion is better for *technical* reasons,
>>> without regard to any business and privacy concerns driving it.
>>
>> I completely understand what your stance is on this and why you feel
>> this way, as seemingly we have a similar type of client base. However,
>> you, like I, are the ones who *will* properly fix a problem when
>> required. I'm concerned about the ones who will use this as a loophole
>> to avoid that.
> 
> I don't think this proposal will make a difference one way or another to
> criminals and deliberate abusers.  It will result in faster resolution
> of those cases where the actual user of the IP space is non-technical or
> not staffed 24/7 by providing an immediate lookup of a contact more
> likely to have the ability to resolve problems quickly and competently.

Again, I understand why you feel this way, but I'm torn from it.

I think, and I *feel*, that by ensuring proper block-holder information
in each re-assignment, it will be easier to weed out the 'unscrupulous'.

Perhaps client churn is a concerning factor here, but I see more
importance on being able to know who has what, than someone trying to
steal clients.

Also, I don't imagine there are many here who don't utilize the security
community for some services. Providing policy allowances such as this
may hinder them in what they can potentially provide... and at the same
time load more responsibility upon ARIN to collect information when
necessary, slowing the investigative process down exponentially (due to
following any new policy that would have to be created for them to
acquire the info).

Respectfully, and very inquisitive,

Steve


From farmer at umn.edu  Wed Apr  7 00:43:09 2010
From: farmer at umn.edu (David Farmer)
Date: Tue, 06 Apr 2010 23:43:09 -0500
Subject: [arin-ppml]  ULA-C
In-Reply-To: <p2s3c3e3fca1004061302t9ae20cedma1dba6fdcd880fe7@mail.gmail.com>
References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net>	<4BA76279.9060809@umn.edu>	<07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com>
	<k2h75cb24521004052242g4a4cdafy766dcdd1ee2a3b85@mail.gmail.com>
	<8695009A81378E48879980039EEDAD28876D4435@MAIL1.polartel.local>
	<o2y3c3e3fca1004060823n3df2085au5f992b20628c65de@mail.gmail.com>
	<8695009A81378E48879980039EEDAD28876D443A@MAIL1.polartel.local>
	<p2s3c3e3fca1004061302t9ae20cedma1dba6fdcd880fe7@mail.gmail.com>
Message-ID: <4BBC0D5D.2060903@umn.edu>

First, I want to apologies to everyone, I'm starting to believe I've 
been wasting all of your time on this. I thought we could find a 
consensus allowing the implementation of ULA-C while providing assurance 
to those worried about ULA-C becoming a policy abuse path.  Somehow I 
even convinced myself there was the start of a consensus developing in 
the past couple weeks.

Today it has become clear to me that I was deluding myself, and I'm 
starting to think the whole thing was a futile effort.  There seems to 
be two diametrically opposed camps, neither of which are willing to 
budge out of their entrenched positions.

So, I will make one final appeal for both sides to find a way to 
compromise. Without both groups being willing to compromises, I fear all 
that is going to happen is a continued shouting match.

I believe a globally defined prefix for non-routed addressing, that has 
both registered uniqueness and reverse DNS, A.K.A ULA-C, would be of 
value to both the enterprise and services provider worlds.

1. With a single global well-known prefix, Service providers and other 
globally reachable Internet (DFZ) network operators could easily filter 
this prefix and the associated packets, without an excessive burden on 
their operations.

2. If packets or routes leak inappropriately, then tracking down the 
source, if necessary, becomes much easier.  As the assignment is 
registered to an organization with contact information. This is not 
currently possible with RFC 1918 or RFC 4193.

3. Providing these assignments from a single global well-known prefix 
helps ensure these assignments are not misappropriated or hijacked, this 
helps protect both service providers and enterprise that received the 
assignment. This is not possible with an unannounced PI assignment, 
maybe with RPKI in the future, but not as things stand today.

4. The availability of ULA-C for internal addressing will likely make PA 
addressing facing the Internet more palatable at least for some classes 
of enterprise users.  This might be implemented with NAT66, multiple 
RAs, or any number of possible future solutions.  Like maybe some 
variation of LISP, or some other GSE type solutions.  But, the details 
are irrelevant that is an operational issue not a policy one.

5. ULA-C with at least an option for authoritative reverse DNS, provides 
other options than just split DNS for enterprise internal naming.  Also, 
  Internet based VPNs can create many DNS challenges.  Leaking forward 
and reverse DNS lookups for RFC 1918 and RFC 4193 addresses are a 
nuisance for both service providers and enterprises alike.

6. ULA-C, currently proposed as FC00::/8, is a much more limited 
resource than GUA 2000::/3, and since resource are being globally 
dedicated to individual organizations, some mechanism to ensure the 
long-term stewardship of those resource is necessary. The RIRs seem well 
suited to provide the necessary stewardship, as they already do this at 
a global scale for many other number resources, why build something new. 


7. ULA-C, even with a global well-known prefix, is just another 128bit 
integer, there is nothing fundamentally different about it, than PA or 
PI.  In fact, with registered uniqueness, reverse DNS, and maybe even 
RPKI in the future, the only practical difference between ULA-C and PI 
is the non-routed property, applied realistically only by convention. 
There is one possible other difference, random prefix selection.  While 
this could help prevent some kinds of abuse, I'm not sure this would 
provide much practical deterrence in using ULA-C as a substitute for PI. 
  Which I believe is the primary abuse path of concern.

Therefore, I believe the concerns about ULA-C becoming a path for policy 
abuse cannot be completely discounted.  However, in reality the risk is 
no where near as large as some are claiming.  Further, I believe this 
risk can be easily managed via the RIRs' number resource policy 
processes, if the RIRs were to be given full policy control of ULA-C 
registrations.

I believe the crux of the issues are these last two points (#6 & #7). 
Some members of the community seem to want ULA-C to bypass the 
stewardship and policy control of the RIRs, to justify a low cost for an 
assignment of ULA-C.  And, some others seem to be over blowing the risk 
of abuse that ULA-C represents and seem to claim there is no way to 
manage that risk.

I believe, the stewardship the RIRs provide is necessary, and the RIRs' 
policy processes can properly manage the risk.  As for cost, while not a 
policy matter, in the shorter-term ULA-C is not going to be as cost 
effective as some would hope.  However, if in the longer-term the risks 
can be managed, then I have to believe that the RIRs will do the right 
thing.

So, is some kind of compromise between the opposing camps possible? 
Otherwise, I fear this is going to continue to be a pointless shouting 
match.

Finally, I want to be clear the opinions I have expressed in this whole 
set of threads have been my personal opinion.  The AC has not reached 
any consensus on these issues.  And, without compromise from both camps 
as noted, I honestly don't see the AC coming to any consensus either.

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


From michael.dillon at bt.com  Wed Apr  7 05:05:22 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 7 Apr 2010 10:05:22 +0100
Subject: [arin-ppml] Comments on Draft Policy
	2010-3:Customer	Confidentiality
In-Reply-To: <6D251AF0-1FE5-4184-9032-014EBCB9E6CB@ren-isac.net>
Message-ID: <28E139F46D45AF49A31950F88C49745805AF0DFD@E03MVZ2-UKDY.domain1.systemhost.net>

> "ISPs may choose to enter the customer's name along with the 
> ISP's address and phone number in reassignments and 
> reallocations in lieu of the customer's address and phone 
> number. The customer's actual information must be provided to 
> ARIN on request and will be held in the strictest confidence."
> 
> Those "two lines" (at-least to me), represent sort of the 
> "domains by proxy feature".

This is much stricter than today where an ISP can just leave out
customer information, and not give ARIN anything.

> When dealing with security incidents, if the contact 
> information is virtually proxy'd, then thats more time/money 
> spent trying to get a- hold of someone close enough to the 
> problem to do away with it. 

You clearly do not have front-line experience with this kind
of contact scenario. If you contact the ISP, they can disconnect
the customer, then contact them and help them sort out the problem.
If you contact the customer, they will say something like, "I don't
know what you are talking about, I was cooking supper and I'm not
using my computer at all, just reading the recipe off the screen".

Filling the whois directory with contact info for people who have
little understanding of technology and networks *WILL* cost you
more money and wasted time trying to get a hold of someone who
can understand your issue and act upon it.

> However, the very thing you're trying to 
> protect against (eg: customer lists), is one of the very 
> things security ops handlers are trying to build up and keep 
> current. The public information in an unstructured and 
> federated environment helps us do that. It is only two 
> sentences, and that's dangerous when you're setting a 
> standard for the backbone of the federated environment that 
> is the internet.

Yes, it is true that in the Wild West, private police forces 
and armies were free to form and to take action. But the Wild
West has ended, and it is time for the Internet to also become
more civilized. If this bothers you, then join the police force
or the FBI, and you will be a real cop, not just a pretend one.

> We are enumerating those customer lists on a daily basis to 
> help make the internet a safer place. 

On second thought, maybe you should go into politics. That way
you could pass a law mandating ISPs to share their databases
of customer identity and IP address with the legal authorities.

The fact is that by removing junk info from the whois directory
ARIN would be helping to make the Internet a safer place.

> By design, this policy 
> appears to be aimed at taking that functionality away. 

Yes, and in my opinion it should be simplified to remove this
sentence:

  The customer's actual information must be provided
  to ARIN on request and will be held in the strictest
  confidence.

That doesn't belong in policy and is already part of ARIN's
current operational practice. When ARIN needs the info, they
ask for it, and they will sign an NDA with the registrant.

--Michael Dillon


From michael.dillon at bt.com  Wed Apr  7 05:14:14 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 7 Apr 2010 10:14:14 +0100
Subject: [arin-ppml] Comments
	onDraft	Policy	2010-3:	Customer	Confidentiality
In-Reply-To: <029401cad5f3$21ef4aa0$65cddfe0$@net>
Message-ID: <28E139F46D45AF49A31950F88C49745805AF0E16@E03MVZ2-UKDY.domain1.systemhost.net>


> What would people think if the policy was altered to 
> distinguish between an "end user" class and a "reseller" 
> class of customer where the requirements would be to disclose 
> full information on the reseller, which would be someone 
> reselling network services such as web hosting, VPS' or even 
> another ISP, and someone hosting their corporate e-mail and web site?

What makes you think that the average reseller has
more technical clue than the average citizen?

--Michael Dillon


From cengel at sponsordirect.com  Wed Apr  7 11:29:10 2010
From: cengel at sponsordirect.com (Chris Engel)
Date: Wed, 7 Apr 2010 11:29:10 -0400
Subject: [arin-ppml] Comments on Draft Policy 2010-3: Customer
	Confidentiality
In-Reply-To: <mailman.951.1270589775.28982.arin-ppml@arin.net>
Message-ID: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA623@Skyhawk>

Jay Hennigan wrote:

> The change is the *ability* to list the ISP's contact number
> and address, not a *requirement* to do so.  For cases where
> the end user customer has a security and technical staff that
> is willing able to deal with these issues when they come up,
> said staff will probably want to have their own contact
> number listed in WHOIS.  Indeed it should be.
>
> If anything, I view this proposal as facilitating, not
> hindering, rapid response to security incidents by those with
> the knowledge and ability to deal with them.
>
> Note that this proposal in my opinion is better for
> *technical* reasons, without regard to any business and
> privacy concerns driving it.
>


I agree with Jay 100% here. For people that WANT to anonymize thier information (whether for fair reasons or foul) thier going to be able to put in bogus information here regardless of policy. Unless you want to start investing about $10,000 per registration to actualy investigate whether the information that they provide is accurate, then anything you write as policy isn't going to help here.

For anyone else, it really should be between the ISP and the customer as to who gets listed. Totaly ignoring the privacy issue...a policy like this would actualy allow for faster response to problems in many cases. As Jay pointed out, many companies may not even have some-one technical on staff that can deal with these issues. If you call up a receptionist on the phone, they aren't likely to be able to help you....and if they are even mildly tech saavy they aren't going to be able to tell the difference between you and some-one making a social engineering attempt on them.

Even for organizations that DO have technical people on staff....very few maintain 24/7 NOC's like ISP's do. I know for our organization if you try to contact any of our publicaly listed numbers outside of regular business hours, you won't get a response. However, our hosting providers and customers do have call sheets with after hours emergency contact numbers on them.... and I'd certainly be willing to provide something similar to an ISP's NOC or other trusted agent that can act as a gateway function between some-one with a legitimate issue...and some-one trying to sell me hosting space in Hong Kong. Tell me, which would yeild a faster response?


Respectfully to the security research organizations, why should you not have to justify your legitimate need for such information? Aside from technical considerations and on to ethical/public policy issues. Information access should be a 2 way street. If you want access to some-one elses information then you should be prepared to surrender your own in order to get it. You should be able to justify your access to that information and there should be some method of transparency/tracking/accountability as to what you do with that information. Right now, WHOIS is about as far away from a 2-way street as you can get. The information contained in WHOIS may not be particularly sensitive... but the principle remains the same.



Christopher Engel



From stephen at sprunk.org  Wed Apr  7 11:31:14 2010
From: stephen at sprunk.org (Stephen Sprunk)
Date: Wed, 07 Apr 2010 10:31:14 -0500
Subject: [arin-ppml] Comments on
	Draft	Policy	2010-3:	Customer	Confidentiality
In-Reply-To: <4BBBC0F6.8050007@ibctech.ca>
References: <474FEA3C-42FE-401D-A6CB-130973053094@ren-isac.net>	<018901cad5bb$95108950$bf319bf0$@net>	<6D251AF0-1FE5-4184-9032-014EBCB9E6CB@ren-isac.net>	<4BBBA757.2020500@impulse.net>
	<4BBBC0F6.8050007@ibctech.ca>
Message-ID: <4BBCA542.8020103@sprunk.org>

On 06 Apr 2010 18:17, Steve Bertrand wrote:
> On 2010.04.06 17:27, Jay Hennigan wrote:
>   
>> I have to respectfully disagree. The vast majority of our customers
>> are small to medium sized businesses who have very little operational
>> clue.  Law firms, insurance agents, warehouse firms, etc. The
>> contacts at the phone number or physical address of these operations
>> can barely spell BGP, let alone describe it.
> The vast majority of my customers are exactly the same.
>   

I suspect that the vast majority of _everyone's_ customers are the
same.  Heck, most of the folks _working for ISPs_ I've dealt with can't
describe BGP.  The average customer can't even spell _IP_.

>> As their ISP, we are much more likely to able to do away with any problems that they may create than their on-premise staff.
>>     
> Agreed.
>   

True.

>> Listing their phone number and address instead of ours results in total confusion as their receptionist is likely to want to have someone call you back.  
>>     
> Even if an operator is half-baked, they still should know that it's trivial to look up the POCs for the encompassing block in the event that a receptionist responds with "no" when one asks "do you have a computer technician that looks after your stuff?".
>   

True.  It's trivially easy to format your WHOIS request to get the
parent block(s) of the address you're looking up.  I normally bypass the
end user altogether when I have a need to contact someone because the
odds of them having anyone technical enough to be useful are so small.

> Better yet, I throw it right into the SWIP 'Comments' section, just to
> be safe:
>
> Comment:    For other issues, or if the above contacts
> Comment:    are non-responsive, contact the ARIN POC registered
> Comment:    to the encompassing IP block.
>   

This is a decent idea, but IMHO it would be better to set a "technical"
and/or "abuse" POC on the SWIP itself (available with the "detailed"
template).

> Note that this proposal in my opinion is better for *technical* reasons, without regard to any business and privacy concerns driving it.
>   
> I completely understand what your stance is on this and why you feel
> this way, as seemingly we have a similar type of client base. However,
> you, like I, are the ones who *will* properly fix a problem when
> required. I'm concerned about the ones who will use this as a loophole
> to avoid that.
>   

Indeed.  IMHO, most of those who will take advantage of this policy will
do so for business reasons (e.g. hiding their customer lists from
competitors) rather than technical ones.

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3646 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100407/1dca6f20/attachment.p7s>

From kkargel at polartel.com  Wed Apr  7 11:47:21 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 7 Apr 2010 10:47:21 -0500
Subject: [arin-ppml] Comments on Draft
	Policy	2010-3:Customer	Confidentiality
In-Reply-To: <28E139F46D45AF49A31950F88C49745805AF0DFD@E03MVZ2-UKDY.domain1.systemhost.net>
References: <6D251AF0-1FE5-4184-9032-014EBCB9E6CB@ren-isac.net>
	<28E139F46D45AF49A31950F88C49745805AF0DFD@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <8695009A81378E48879980039EEDAD28876D4457@MAIL1.polartel.local>



 > "ISPs may choose to enter the customer's name along with the ISP's 
> address and phone number in reassignments and reallocations in lieu of 
> the customer's address and phone number. The customer's actual 
> information must be provided to ARIN on request and will be held in 
> the strictest confidence."

I still think a better wording would be :

> "^The customer^ may choose to enter the customer's name along with the ISP's 
> address and phone number in reassignments and reallocations in lieu of 
> the customer's address and phone number. The customer's actual 
> information must be provided to ARIN ^^ and will be held in 
> the strictest confidence."

This decision should be the asignee's decision, not the ISP's decision.  I believe in many if not most cases the customer's decision will be to tell the ISP "Do whatever is right.", but it is still the customers prerogative.




From kkargel at polartel.com  Wed Apr  7 11:56:33 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 7 Apr 2010 10:56:33 -0500
Subject: [arin-ppml] Comments
	on	Draft	Policy	2010-3:	Customer	Confidentiality
In-Reply-To: <4BBCA542.8020103@sprunk.org>
References: <474FEA3C-42FE-401D-A6CB-130973053094@ren-isac.net>
	<018901cad5bb$95108950$bf319bf0$@net>
	<6D251AF0-1FE5-4184-9032-014EBCB9E6CB@ren-isac.net>
	<4BBBA757.2020500@impulse.net>	<4BBBC0F6.8050007@ibctech.ca>
	<4BBCA542.8020103@sprunk.org>
Message-ID: <8695009A81378E48879980039EEDAD28876D4458@MAIL1.polartel.local>

Can't the customer *already* list whoever their agent is as technical or abuse PoC?  I have always suggested to non-technical customers that they list either their ISP (me) or their contracted network maintainer as the technical and abuse PoC as appropriate.  That just makes common sense.  Whoever is contracted to provide and maintain network services for the customer *is* an agent of the customer and IMHO qualifies for inclusion in PoC contacts according to current policy.

I do strongly feel though that this is the prerogative of the customer, not the ISP.  The ISP can obviously advise the customer, and in most cases a non-technical customers response to the ISP will be "Whatever you say.", but in the end it is the customers decision.

Kevin Kargel



From kkargel at polartel.com  Wed Apr  7 12:05:51 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 7 Apr 2010 11:05:51 -0500
Subject: [arin-ppml] Comments
	on	Draft	Policy	2010-3:	Customer	Confidentiality
In-Reply-To: <20100407160235.GB28901@vacation.karoshi.com.>
References: <474FEA3C-42FE-401D-A6CB-130973053094@ren-isac.net>
	<018901cad5bb$95108950$bf319bf0$@net>
	<6D251AF0-1FE5-4184-9032-014EBCB9E6CB@ren-isac.net>
	<4BBBA757.2020500@impulse.net> <4BBBC0F6.8050007@ibctech.ca>
	<4BBCA542.8020103@sprunk.org>
	<8695009A81378E48879980039EEDAD28876D4458@MAIL1.polartel.local>
	<20100407160235.GB28901@vacation.karoshi.com.>
Message-ID: <8695009A81378E48879980039EEDAD28876D4459@MAIL1.polartel.local>

> 
> kind of begs the question, who is the "customer" here doesn't it?
> if I am getting numbering resources from my RIR, then I am their
> customer and I should have final say in what is entered into their
> DB.  If, on the other hand, I am the customer of, say CSnet (using
> a long-dead company for reference) then CSnet is the customer of
> the RIR, not me and I have zero say in what CSnet, as the RIR
> customer, places in its registration entries/database.
> 
> SWIPS and LEOs (CALEA) sort of want to insist that someone, in this
> case the RIR, maintain accurate, public records of folks who are
> not the RIR customers/clients.
> 
> --bill 


So maybe "end user" would be a better descriptor than customer?


From cgrundemann at gmail.com  Wed Apr  7 12:13:05 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 7 Apr 2010 10:13:05 -0600
Subject: [arin-ppml] Comments on Draft Policy 2010-3: Customer
	Confidentiality
In-Reply-To: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA623@Skyhawk>
References: <mailman.951.1270589775.28982.arin-ppml@arin.net>
	<F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA623@Skyhawk>
Message-ID: <p2y443de7ad1004070913j5d15c764ifb9b6225ce594fc2@mail.gmail.com>

On Wed, Apr 7, 2010 at 09:29, Chris Engel <cengel at sponsordirect.com> wrote:
> I agree with Jay 100% here. For people that WANT to anonymize thier information (whether for fair reasons or foul) thier going to be able to put in bogus information here regardless of policy. Unless you want to start investing about $10,000 per registration to actualy investigate whether the information that they provide is accurate, then anything you write as policy isn't going to help here.
>

You are right, this policy will not help. What might is an opt-in type
email once a year to all (technical and abuse) POCs.  See the
adopted-but-not-yet-implemented policy 2008-7 for an idea of what this
looks like.

> For anyone else, it really should be between the ISP and the customer as to who gets listed. Totaly ignoring the privacy issue...a policy like this would actualy allow for faster response to problems in many cases. As Jay pointed out, many companies may not even have some-one technical on staff that can deal with these issues. If you call up a receptionist on the phone, they aren't likely to be able to help you....and if they are even mildly tech saavy they aren't going to be able to tell the difference between you and some-one making a social engineering attempt on them.
>

Even if you are right, this policy (2010-3) is _not_ needed to
accomplish this. ARIN already allows simple reassignments which use
the upstream POC information. Quoting from
https://www.arin.net/resources/request/reassignments.html:

"
    * IPv4 Reassign-Simple

 Used to sub-delegate IP addresses to a customer that does not need to:

    * sub-delegate the addresses to their own customers
    * maintain their own in-addr.arpa delegation
    * display their own point of contact (POC) information.

 Can also be used to change the customer name and address information
(but not  the range) on an existing simple reassignment and to remove
simple reassignments. It is submitted by the parent organization's
Administrative or Technical POC, or the Technical POC for the
resource.

 POCs are not associated with simple reassignments. The customer
receiving the reassignment will have the assigning ISP's POCs and name
servers.
"

> Even for organizations that DO have technical people on staff....very few maintain 24/7 NOC's like ISP's do. I know for our organization if you try to contact any of our publicaly listed numbers outside of regular business hours, you won't get a response. However, our hosting providers and customers do have call sheets with after hours emergency contact numbers on them.... and I'd certainly be willing to provide something similar to an ISP's NOC or other trusted agent that can act as a gateway function between some-one with a legitimate issue...and some-one trying to sell me hosting space in Hong Kong. Tell me, which would yeild a faster response?
>

The question here should not be "what happens in this one corner case"
or "what happens in my one example" but rather "what does the best
good for the entire community - in all cases?"

The answer is that the most complete, comprehensive and valid whois
directory possible provides the best possible resource for *all*.

>
> Respectfully to the security research organizations, why should you not have to justify your legitimate need for such information? Aside from technical considerations and on to ethical/public policy issues. Information access should be a 2 way street. If you want access to some-one elses information then you should be prepared to surrender your own in order to get it. You should be able to justify your access to that information and there should be some method of transparency/tracking/accountability as to what you do with that information. Right now, WHOIS is about as far away from a 2-way street as you can get. The information contained in WHOIS may not be particularly sensitive... but the principle remains the same.
>

I believe in an Open Internet. Walling off whois data is not conducive
to openness. OTOH, fully available whois data has very little
downside, quite a lot of upside and _is_ conducive to keeping the
Internet ecosystem Open.

To restate: I am opposed to dp 2010-3.

I again invite those in favor of this policy to review pp 109 which
just might meet your needs without creating the problems that this
policy will.

Respectfully,
~Chris

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

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From cengel at sponsordirect.com  Wed Apr  7 12:23:57 2010
From: cengel at sponsordirect.com (Chris Engel)
Date: Wed, 7 Apr 2010 12:23:57 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <mailman.961.1270654291.28982.arin-ppml@arin.net>
Message-ID: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA624@Skyhawk>

David Farmer wrote:

> I believe, the stewardship the RIRs provide is necessary, and
> the RIRs'
> policy processes can properly manage the risk.  As for cost,
> while not a
> policy matter, in the shorter-term ULA-C is not going to be as cost
> effective as some would hope.  However, if in the longer-term
> the risks
> can be managed, then I have to believe that the RIRs will do
> the right
> thing.

David,

Speaking only for myself, I don't think the fee's I've heard thrown around (I think it was something like $1200 per year?) would present much of a stumbling block for most of those on the Enterprise who's addressing needs would actually justify ULA-C. Realistically, that's less then the coffee budget. No significant Enterprise should even blink at that. As long as there is no fee or justification for ULA-R (which I'm assuming because there is no registration) then everything should be fine. If you can't justify $1200 per year, then the burden imposed by using something which is not guarantied unique but still statistically alot bigger then RFC1918 is not that significant. Frankly I would think that most smaller Enterprises/startups will probably opt for ULA-R anyway. That would be our plan right now (assuming we can find NAT support in IPv6).

However, I can see the value in ULA-C for some Enterprises...and you'll definitely get some buy in there..even with significant fee's. I wouldn't have any problem fee/justification wise if ULA-C was treated identically to PI. The only caveat should be that justification for ULA-C shouldn't count against justification for PA/PI... you should be able to get both types of addresses for the same device. The real value of ULA-C (IMO) is the understanding that it's not supposed to be globally routed. Yes, that's enforced by convention only...but that's no different then pretty much anything else on the internet.


Christopher Engel



From cengel at sponsordirect.com  Wed Apr  7 12:43:47 2010
From: cengel at sponsordirect.com (Chris Engel)
Date: Wed, 7 Apr 2010 12:43:47 -0400
Subject: [arin-ppml] Comments on Draft Policy 2010-3: Customer
	Confidentiality
In-Reply-To: <p2y443de7ad1004070913j5d15c764ifb9b6225ce594fc2@mail.gmail.com>
Message-ID: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA625@Skyhawk>

Chris Grundemann wrote:

> You are right, this policy will not help. What might is an
> opt-in type email once a year to all (technical and abuse)
> POCs.  See the adopted-but-not-yet-implemented policy 2008-7
> for an idea of what this looks like.

Chris,

I don't see how sending out an e-mail to slipperysam at gmail.com which has an auto-responder setup on it to reply to such ARIN e-mails is going to help much to provide information on who that address holder really is. If some-one really wants to hide thier identity....pretty much the only way you are going to find it is tracing the form of payment they use when paying thier ISP's bills. Doing that probably means going to the courts.

The place a policy like that may help is when a block holder isn't purposefully trying to hide who they are....but may have had some internal changes (moved offices, new e-mail address, new network admin, etc) and forgotten to update thier contact info accordingly. I don't neccesarly object to the policy...I just don't think it's going to achieve all that much outside of issues like that.


Christopher Engel



From owen at delong.com  Wed Apr  7 12:51:33 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 7 Apr 2010 09:51:33 -0700
Subject: [arin-ppml] ULA-C
In-Reply-To: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA624@Skyhawk>
References: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA624@Skyhawk>
Message-ID: <B52A6E81-C40E-4996-8613-5B3745DA5A1D@delong.com>


On Apr 7, 2010, at 9:23 AM, Chris Engel wrote:

> David Farmer wrote:
> 
>> I believe, the stewardship the RIRs provide is necessary, and
>> the RIRs'
>> policy processes can properly manage the risk.  As for cost,
>> while not a
>> policy matter, in the shorter-term ULA-C is not going to be as cost
>> effective as some would hope.  However, if in the longer-term
>> the risks
>> can be managed, then I have to believe that the RIRs will do
>> the right
>> thing.
> 
> David,
> 
> Speaking only for myself, I don't think the fee's I've heard thrown around (I think it was something like $1200 per year?) would present much of a stumbling block for most of those on the Enterprise who's addressing needs would actually justify ULA-C. Realistically, that's less then the coffee budget. No significant Enterprise should even blink at that. As long as there is no fee or justification for ULA-R (which I'm assuming because there is no registration) then everything should be fine. If you can't justify $1200 per year, then the burden imposed by using something which is not guarantied unique but still statistically alot bigger then RFC1918 is not that significant. Frankly I would think that most smaller Enterprises/startups will probably opt for ULA-R anyway. That would be our plan right now (assuming we can find NAT support in IPv6).
> 
The fee most likely (the current GUA fees) would be $1250 ONE TIME initial and it would then be part of
your end-user $100/year fee.  If you were an ISP, it would likely be zero cost all around as it is unlikely to
change your usage tier.

> However, I can see the value in ULA-C for some Enterprises...and you'll definitely get some buy in there..even with significant fee's. I wouldn't have any problem fee/justification wise if ULA-C was treated identically to PI. The only caveat should be that justification for ULA-C shouldn't count against justification for PA/PI... you should be able to get both types of addresses for the same device. The real value of ULA-C (IMO) is the understanding that it's not supposed to be globally routed. Yes, that's enforced by convention only...but that's no different then pretty much anything else on the internet.
> 
I completely agree.

Owen




From owen at delong.com  Wed Apr  7 14:04:26 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 7 Apr 2010 11:04:26 -0700
Subject: [arin-ppml] ULA-C
In-Reply-To: <20100407173104.GA30448@vacation.karoshi.com.>
References: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA624@Skyhawk>
	<B52A6E81-C40E-4996-8613-5B3745DA5A1D@delong.com>
	<20100407173104.GA30448@vacation.karoshi.com.>
Message-ID: <9F343107-619F-4C8E-9A5E-581CCBB2754D@delong.com>


On Apr 7, 2010, at 10:31 AM, bmanning at vacation.karoshi.com wrote:

> On Wed, Apr 07, 2010 at 09:51:33AM -0700, Owen DeLong wrote:
>> 
>> The fee most likely (the current GUA fees) would be $1250 ONE TIME initial and it would then be part of
>> your end-user $100/year fee.  If you were an ISP, it would likely be zero cost all around as it is unlikely to
>> change your usage tier.
> 
> 
> 	Nope ... its 1250/year.  and likely to rise once the fee waiver expires.
> 	the 100/year fee remains for the resources covered under the LRSA.
> 
> --bill

I'm not seeing where you get that impression...

From https://www.arin.net/fees/fee_schedule.html

END USERS / ASSIGNMENTS

End users receive IP addresses for use only in their internal networks, and not for distribution to users of their Internet services.  End users are assessed an initial fee for each new IPv4 and IPv6 address assignment, AS number registration, resource transfer, and experimental resource registration. IPv4 and IPv6 address assignments, ASN's and transfers are subject to a $100 USD annual maintenance fee. This fee is per Organization ID (OrgID).
After a resource request has been approved, ARIN will invoice for payment. Payment must be received and a Registration Services Agreement (RSA) must be executed before resources are released.
ARIN will send an invoice for the maintenance fee approximately 60 days before it is due.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100407/a16715d9/attachment.htm>

From cgrundemann at gmail.com  Wed Apr  7 14:47:11 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 7 Apr 2010 12:47:11 -0600
Subject: [arin-ppml] Comments on Draft Policy 2010-3: Customer
	Confidentiality
In-Reply-To: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA625@Skyhawk>
References: <p2y443de7ad1004070913j5d15c764ifb9b6225ce594fc2@mail.gmail.com>
	<F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA625@Skyhawk>
Message-ID: <g2r443de7ad1004071147ia3f984c6m523ed4deda992b71@mail.gmail.com>

On Wed, Apr 7, 2010 at 10:43, Chris Engel <cengel at sponsordirect.com> wrote:
>
> Chris,
>
> I don't see how sending out an e-mail to slipperysam at gmail.com which has an auto-responder setup on it to reply to such ARIN e-mails is going to help much to provide information on who that address holder really is. If some-one really wants to hide thier identity....pretty much the only way you are going to find it is tracing the form of payment they use when paying thier ISP's bills. Doing that probably means going to the courts.
>

True, it won't tell you *who* they are but the hope is to determine
*that* they are.

While the implementation of the policy is completely up to ARIN staff,
my vision was for something a bit better at rooting out fake or bad
addresses. Like including a URL that must be visited, or a certain
phrase that must be included in the reply. Something very lightweight
for a real person but hard (if not impossible) for an auto-responder.
Then you at least know that someone is receiving mail at that address,
which is quite a bit better than what we have now - but not perfect.

> The place a policy like that may help is when a block holder isn't purposefully trying to hide who they are....but may have had some internal changes (moved offices, new e-mail address, new network admin, etc) and forgotten to update thier contact info accordingly. I don't neccesarly object to the policy...I just don't think it's going to achieve all that much outside of issues like that.
>

I agree that the biggest win will be keeping honest folks honest, but
I think it will provide some help combating the bad guys too.  Again,
specific implementation is up to ARIN staff but the idea is that after
the emails go out they will end up with a list of unresponsive POCs
and that will give them somewhere to start.  Most of the unresponsive
POCs will be sorted out through a phone call or physical letter. The
others will likely often point to abandoned and abused resources. That
is the hope anyway.

~Chris

>
> Christopher Engel
>

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From marty at akamai.com  Wed Apr  7 15:07:54 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Wed, 07 Apr 2010 15:07:54 -0400
Subject: [arin-ppml] Comments on Draft Policy 2010-3: Customer
 Confidentiality
In-Reply-To: <4BBCA542.8020103@sprunk.org>
Message-ID: <C7E2504A.2BDA2%marty@akamai.com>

[ clip ]


>>   
>> I completely understand what your stance is on this and why you feel
>> this way, as seemingly we have a similar type of client base. However,
>> you, like I, are the ones who *will* properly fix a problem when
>> required. I'm concerned about the ones who will use this as a loophole
>> to avoid that.
>>   
> 
> Indeed.  IMHO, most of those who will take advantage of this policy will
> do so for business reasons (e.g. hiding their customer lists from
> competitors) rather than technical ones.
> 


Which technically isn't exactly going to work. It is 2010 after all.


    http://ws.arin.net/whois/?queryinput=!%3EWHOLE-125


This output is enough for geoLoc, something more reliable than WHOIS, to
provide an ip->domain name->contact information mapping at a cost that is
similar. There are a variety of companies involved in providing these
services and they are designed around electronic advertising, fraud
prevention, fraud detection and correlating consumer demographics. Fortune
500's and small business all have access to the tools necessary to do this
for short change.

IMHO, the only domain names that would _not_ be easily translated into a
reachable human being by geoLoc databases are the ones who deliberately
leave no trace and do not want to be reached. As others have noted, it is
likely that the majority are nefarious in nature.

Not in favor of 2010-3. Competition is supposed to be about improvement.
This is self-destructive as noted by many. The ROI is negative as a result,
the rationale isn't about privacy and the proposal doesn't take us even a
small step towards accomplishing any goal related to privacy.


Best Regards,

-M<


[cj, thanks for pointing out that I blurred [109 <<<o_0>>>> 2010-3]. I
didn't realize it as I was trying to figure out what was up with this issue
and the large volume of postings ]





From bill at herrin.us  Wed Apr  7 17:17:31 2010
From: bill at herrin.us (William Herrin)
Date: Wed, 7 Apr 2010 17:17:31 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA624@Skyhawk>
References: <mailman.961.1270654291.28982.arin-ppml@arin.net> 
	<F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA624@Skyhawk>
Message-ID: <j2z3c3e3fca1004071417p1f4655dfqb2af31133b793697@mail.gmail.com>

On Wed, Apr 7, 2010 at 12:23 PM, Chris Engel <cengel at sponsordirect.com> wrote:
> Speaking only for myself, I don't think the fee's I've heard thrown
> around (I think it was something like $1200 per year?) would
> present much of a stumbling block for most of those on the
> Enterprise who's addressing needs would actually justify ULA-C.

Needs? Justify? $1200? For ULA? Buddy, I don't think you quite get
what ULA is or what it's for.

All three of those are huge stumbling blocks to a ULA-C, and I do work
for a large enterprise which would have a use for registered ULA. ULA
is for everything from the coordinated enterprise WAN to the
independent 20-phone LAN installed by a particular office's vendor and
the VPNed "inside lan" for customer 4468's 3 servers. Like random ULA,
it's gotta be damn near grab and go... and $1200 is a non-starter.

-Bill

-- 
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 gtb at slac.stanford.edu  Wed Apr  7 18:24:06 2010
From: gtb at slac.stanford.edu (Buhrmaster, Gary)
Date: Wed, 7 Apr 2010 15:24:06 -0700
Subject: [arin-ppml] ULA-C
In-Reply-To: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA624@Skyhawk>
References: <mailman.961.1270654291.28982.arin-ppml@arin.net>
	<F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA624@Skyhawk>
Message-ID: <6F51B50ECF32084788B9B3A8469A71B5CFFC6F7177@EXCHCLUSTER1-02.win.slac.stanford.edu>



> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Engel
...
> 
> David Farmer wrote:
> 
> > I believe, the stewardship the RIRs provide is necessary, and
> > the RIRs'
> > policy processes can properly manage the risk.  As for cost,
> > while not a
> > policy matter, in the shorter-term ULA-C is not going to be as cost
> > effective as some would hope.  However, if in the longer-term
> > the risks
> > can be managed, then I have to believe that the RIRs will do
> > the right
> > thing.
> 
....
> However, I can see the value in ULA-C for some Enterprises...
> and you'll definitely get some buy in there..even with
> significant fee's. I wouldn't have any problem fee/justification
> wise if ULA-C was treated identically to PI. The only caveat
> should be that justification for ULA-C shouldn't count
> against justification for PA/PI... you should be able to get
> both types of addresses for the same device. The real value of
> ULA-C (IMO) is the understanding that it's not supposed to be globally
> routed. Yes, that's enforced by convention only...but that's no
> different then pretty much anything else on the internet.

I agree.

I can see an argument that if the price for ULA-C *is* the same as PI
there would be little advantage for an organization to try to get
ULA-C as an end-run for "cheap" GUA.  Only those that understand ULA-C
and want the current and future restrictions (not globally routed)
are likely to choose it.  There will be such organizations.  I would
like to see ARIN be able to serve them.

Gary


From michael.dillon at bt.com  Thu Apr  8 06:26:11 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 8 Apr 2010 11:26:11 +0100
Subject: [arin-ppml] ULA-C
In-Reply-To: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA624@Skyhawk>
Message-ID: <28E139F46D45AF49A31950F88C49745805B60BBA@E03MVZ2-UKDY.domain1.systemhost.net>


> The real value of ULA-C (IMO) 
> is the understanding that it's not supposed to be globally 
> routed. Yes, that's enforced by convention only...but that's 
> no different then pretty much anything else on the internet.

Actually, ULA-C *IS* designed to be globally routed. But only
on private internetworks, not on the public Internet. 

Remember that the Internet Protocol suite and the IETF are 
not there to service the public Internet. They are there to
allow everyone to internetwork computers and other devices
in any way that is useful to them. This includes private
internetworks and it includes semi-connected regions of
the public Internet, as well as the so-called "global Public
Internet".

I think that everyone understands what private internetworks
are whether they are COINs or just a company that connects
to a couple of key trading partners over some kind of VPN
service. But consider this possibility. A country like China
might choose to offer certain government services using
a few registered ULA-C ranges, and require all ISPs in China
to route those addresses, i.e. punch some /48 holes in their
FC00::/7 filters. The end result would be that within China,
those government sites are fully connected to the public Internet
but outside of China, those sites do not exist.

You might never want to do such a thing, but I can't think of
a good reason why you would want to prevent everybody on the
planet from doing such a thing. The IETF is there to create
possibilities, not to prescribe everything about how you 
must operate your networks.

Within ARIN we must remember that we are part of a larger picture,
and sometimes, public Internet operators need to step aside and
say, "this doesn't affect us because we filter FC00::/7" and let
other people do their thing. Other people includes enterprise 
network operators, Community Of Interest Network (COIN) operators,
and innovative thinkers who want to do something new.

This is a situation where even if the majority of PPML voices
are opposed to ULA-C addressing, the AC and Board of Trustees
should do the right thing and make it happen, in a reasonable
and orderly way. Remember that ULA-C addresses do exist today;
they just don't have any orderly processes surrounding them.
This is a vacuum that must be filled, before someone creates
a fait accompli type of solution.

--Michael Dillon


From cengel at sponsordirect.com  Thu Apr  8 10:43:16 2010
From: cengel at sponsordirect.com (Chris Engel)
Date: Thu, 8 Apr 2010 10:43:16 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <j2z3c3e3fca1004071417p1f4655dfqb2af31133b793697@mail.gmail.com>
Message-ID: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA627@Skyhawk>

Bill Herrin wrote:

> Needs? Justify? $1200? For ULA? Buddy, I don't think you
> quite get what ULA is or what it's for.
>
> All three of those are huge stumbling blocks to a ULA-C, and
> I do work for a large enterprise which would have a use for
> registered ULA. ULA is for everything from the coordinated
> enterprise WAN to the independent 20-phone LAN installed by a
> particular office's vendor and the VPNed "inside lan" for
> customer 4468's 3 servers. Like random ULA, it's gotta be
> damn near grab and go... and $1200 is a non-starter.
>
> -Bill

If I'm not mistaken the prime difference between ULA-C versus ULA-R is that of guarantied uniqueness as opposed to statistically probable uniqueness, correct? The discussion of fee's and justification and all that jazz is, I believe, contained to ULA-C. I don't believe anyone is proposing anything like that for ULA-R....wouldn't be enforceable even if they did, since there is no registration necessary for ULA-R.

I agree that $1200 and justification for private address space for 3 servers is a pretty bad deal. However, the difference between using ULA-C and ULA-R for that use case is that with ULA-R, IF you go through a merger or something of that nature there is a somewhat less then 1 percent chance that you will have to renumber - 3 SERVERS. That doesn't strike me as a particularly daunting burden to risk.

Where ULA-C really makes a difference over ULA-R (IMO) is for the folks who need address space for thousands of devices. For those guys even though the chance of running into a conflict with ULA-R is small, if it does hit...it's a huge burden. However, for those guys a $1200 fee isn't even worth blinking over. For everyone else, there is ULA-R.

I've got no pony in this race. I'm neither the big multi-national Enterprise or the guy with 3 servers in his closet. IF/WHEN we support IPv6 (still an open question) our plans would be to use ULA-R regardless, even if ULA-C was free. The big objection to ULA-C that seems to be getting raised by people here.... as David pointed out.... was that ULA-C could be abused as an end-run around PI/PA policy/fees. If you make the policy/fees for ULA-C identical to those, you remove any incentive for that and still retain what makes ULA-C valuable. Seems like a reasonable compromise to me.... and really the guys who most need ULA-C (as opposed to ULA-R) should easily be able to afford that kind of money. Just my 2 cents.





Christopher Engel



From info at arin.net  Fri Apr  9 10:04:59 2010
From: info at arin.net (Member Services)
Date: Fri, 09 Apr 2010 10:04:59 -0400
Subject: [arin-ppml] ARIN XXV Policy Discussions
Message-ID: <4BBF340B.9040600@arin.net>

The ARIN XXV Public Policy and Members Meeting will be held very soon in 
Toronto. Whether you?re attending in person or participating remotely, 
be sure to review the agenda so you don?t miss your chance to share your 
thoughts during the policy discussions:

Monday, 19 April

2010-3: Customer Confidentiality
2010-6: Simplified M&A transfer policy
2010-2: /24 End User Minimum Assignment Unit
2010-5: Reduce and Simplify IPv4 Initial Allocations

Tuesday, 20 April

2010-7: Simplified IPv6 policy
2010-8: Rework of IPv6 assignment criteria
2010-4: Rework of IPv6 allocation criteria
2010-1: Waiting List for Unmet IPv4 Requests

View the agenda for specific times at 
https://www.arin.net/ARIN-XXV/agenda.html.

The agenda is subject to change, but we will make every effort not to 
change the times for policy discussions. We will be sending daily agenda 
updates to all attendees and registered remote participants. You can 
also follow us on Twitter @TeamARIN for schedule updates. Be sure to use 
the #arin25 tag for your own tweets about the meeting.

Complete information on the text of the draft policies being discussed 
is available at https://www.arin.net/policy/proposals/.

If you?re not able to be there in person, you can still take advantage 
of remote participation features that will allow your voice to be heard 
during critical policy discussions. In addition to following the video 
or audio webcast, you can read along with the live transcript, submit 
questions and comments, and vote in straw polls via Jabber chat.

To register as a remote participant, learn more about the remote 
participation services, or access the meeting materials please go to 
https://www.arin.net/ARIN-XXV/remote.html.

We look forward to your participation.


Regards,

Member Services
American Registry for Internet Numbers (ARIN)





From gbonser at seven.com  Sun Apr 11 20:04:41 2010
From: gbonser at seven.com (George Bonser)
Date: Sun, 11 Apr 2010 17:04:41 -0700
Subject: [arin-ppml] ULA-C
References: <28E139F46D45AF49A31950F88C49745805B60BBA@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6E54@RWC-EX1.corp.seven.com>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of michael.dillon at bt.com
> Sent: Thursday, April 08, 2010 3:26 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] ULA-C
> 
> 
> > The real value of ULA-C (IMO)
> > is the understanding that it's not supposed to be globally
> > routed. Yes, that's enforced by convention only...but that's
> > no different then pretty much anything else on the internet.
> 
> Actually, ULA-C *IS* designed to be globally routed. But only
> on private internetworks, not on the public Internet.


We are an operation that has a lot of private interconnectivity with
other networks that does not go over the Internet.  RFC-1918 collision
has been a major issue and forces the use of GUA when connecting with
partner networks.  This causes a "burn" of address space that is not
even publically reachable.

The notion of having ULA that are allocated from some central registry
is appealing for purposes of private interconnections where one would
not have to worry about collisions in address space and would probably
be worth the expense for us provided it was for our partners as well.

George



From mcr at sandelman.ca  Sun Apr 11 20:47:55 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Sun, 11 Apr 2010 20:47:55 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE08FE6E54@RWC-EX1.corp.seven.com>
References: <28E139F46D45AF49A31950F88C49745805B60BBA@E03MVZ2-UKDY.domain1.systemhost.net>
	<5A6D953473350C4B9995546AFE9939EE08FE6E54@RWC-EX1.corp.seven.com>
Message-ID: <8889.1271033275@marajade.sandelman.ca>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "George" == George Bonser <gbonser at seven.com> writes:
    >> -----Original Message-----
    >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
    George> On
    >> Behalf Of michael.dillon at bt.com
    >> Sent: Thursday, April 08, 2010 3:26 AM
    >> To: arin-ppml at arin.net
    >> Subject: Re: [arin-ppml] ULA-C
    >> 
    >> 
    >> > The real value of ULA-C (IMO)
    >> > is the understanding that it's not supposed to be globally
    >> > routed. Yes, that's enforced by convention only...but that's
    >> > no different then pretty much anything else on the internet.
    >> 
    >> Actually, ULA-C *IS* designed to be globally routed. But only
    >> on private internetworks, not on the public Internet.


    George> We are an operation that has a lot of private
    George> interconnectivity with other networks that does not go over
    George> the Internet.  RFC-1918 collision has been a major issue and
    George> forces the use of GUA when connecting with partner networks.
    George> This causes a "burn" of address space that is not even
    George> publically reachable. 

A question: how many of your connections are with organizations that did
not, when they first numbered their network, even know that they were
going to connect with you?

I ask because, while you say:

    George> not have to worry about collisions in address space and
    George> would probably be worth the expense for us provided it was
    George> for our partners as well. 

that it's worth the money, that's only with the knowledge that you'd be
connecting.
What if you did not know, a-priori, that you were going to connect?
How cheap would ULA-C have to be to just "get some" regardless, vs how
much expense do you think renumbering is?

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS8JtuoCLcPvd0N1lAQK2tggAh/HQsoaeB3HkxFPaNK3BKIVMFqDArrga
BPiCZgWNO2BdxtrRm0iHf93skgGBxspNJfnr8jF7++NmwNKG173HvrUU4OrNnma8
twot4at0EkTwhxf1eqIuhWlP7GZUXq6yUx9pREizqL35JWIOIeJW7TeR2vMrIhK+
gREb4OlVQqfrj12ge7MI3m8grM816MYGzXLsp0zGm7SDxCO0HSA5B4yUMWTl1puZ
wzCRiHdl6tybLFrmCC6kT4InQJzK4ZUy7CYNcxVVrPh5H9OMrp0ktRYIVWTil3x6
fuz7P2q3nhMNzKXh2DX9S+bZcbRmqT2sG2Q4xhq9wE1hmmGqiYgN1A==
=lWCJ
-----END PGP SIGNATURE-----


From gbonser at seven.com  Sun Apr 11 21:01:57 2010
From: gbonser at seven.com (George Bonser)
Date: Sun, 11 Apr 2010 18:01:57 -0700
Subject: [arin-ppml] ULA-C
References: <28E139F46D45AF49A31950F88C49745805B60BBA@E03MVZ2-UKDY.domain1.systemhost.net>
	<5A6D953473350C4B9995546AFE9939EE08FE6E54@RWC-EX1.corp.seven.com>
	<8889.1271033275@marajade.sandelman.ca>
Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6E55@RWC-EX1.corp.seven.com>



> -----Original Message-----
> From: mcr at sandelman.ca [mailto:mcr at sandelman.ca]
> Sent: Sunday, April 11, 2010 5:48 PM
> To: George Bonser
> Cc: michael.dillon at bt.com; arin-ppml at arin.net
> Subject: Re: [arin-ppml] ULA-C
> 
> A question: how many of your connections are with organizations that
> did
> not, when they first numbered their network, even know that they were
> going to connect with you?

I don't think it is a matter of knowing if they are going to connect to
*us* specifically or our knowing if we will connect to them
specifically.  It is a matter of considering if you are going to make
connections and exchange traffic in general with partners that might be
between systems not generally available to the Internet and are in
private network space.  If you decide that the probability of such a
connection is high, then it would be prudent to obtain address space
that is not likely to collide with your potential partner.  Having space
allocated from some central registry would give reasonable assurance of
that.



> I ask because, while you say:
> 
>     George> not have to worry about collisions in address space and
>     George> would probably be worth the expense for us provided it was
>     George> for our partners as well.
> 
> that it's worth the money, that's only with the knowledge that you'd
be
> connecting.

Sometimes "peace of mind" is worth a bit of money.  If the network can
be rolled out with the reasonable expectation that there will not be a
collision, ever, with a potential partner, then it is well worth $1200.
How much time would be spent in engineering an alternative if there is a
collision?  Will it take more than 3 hours to figure out and implement?
If it does, then the money was well spent.  $1200 is practically free.

> What if you did not know, a-priori, that you were going to connect?
> How cheap would ULA-C have to be to just "get some" regardless, vs how
> much expense do you think renumbering is?

Again it is a matter of knowing that you are going to have connections
with people.  You don't know in advance what their address space is, you
don't know in advance even who exactly you are going to connect to.  To
absolutely ensure that you will never have that problem is a good
architectural decision.  Not doing so is probably fine for a "garage"
operation that lives by the notion that "it isn't a problem until it is
a problem" but that isn't the best way to do things, in my opinion.

I would rather do it so the problem will never occur in the first place.




From gbonser at seven.com  Sun Apr 11 21:15:31 2010
From: gbonser at seven.com (George Bonser)
Date: Sun, 11 Apr 2010 18:15:31 -0700
Subject: [arin-ppml] ULA-C
References: <28E139F46D45AF49A31950F88C49745805B60BBA@E03MVZ2-UKDY.domain1.systemhost.net>
	<5A6D953473350C4B9995546AFE9939EE08FE6E54@RWC-EX1.corp.seven.com>
	<8889.1271033275@marajade.sandelman.ca>
Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6E56@RWC-EX1.corp.seven.com>



> -----Original Message-----
> From: mcr at sandelman.ca [mailto:mcr at sandelman.ca]
> Sent: Sunday, April 11, 2010 5:48 PM
> To: George Bonser
> Cc: michael.dillon at bt.com; arin-ppml at arin.net
> Subject: Re: [arin-ppml] ULA-C
> 
> A question: how many of your connections are with organizations that
> did
> not, when they first numbered their network, even know that they were
> going to connect with you?
> 

Let me provide something of a plausible example.  You have Mondo
Megacorp who provides some service worldwide.  One aspect of their
service is actually provided by a third party (Littlefish, Inc.) but
branded as a service of Mondo Megacorp.  There is some integration of
the billing that needs to happen because Littlefish, Inc. needs to be
able to turn on and off service to Modo Megacorp's customers and to bill
Mondo for services rendered.

Neither company has their financial backend systems in publically routed
network space but they need to talk to each other.  Littlefish provides
service to a lot of bigger fish and has a lot of private connectivity to
specific systems it needs communications with at these partners that are
on private networks.

If they are all in "private" space that is also unique, they never have
to worry about address space collisions when they interface with each
other on the backend.

G


From joelja at bogus.com  Sun Apr 11 21:36:41 2010
From: joelja at bogus.com (joel jaeggli)
Date: Sun, 11 Apr 2010 18:36:41 -0700
Subject: [arin-ppml] ULA-C
Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6E56@RWC-EX1.corp.seven.com>

Mondo-megacorp will trivially have enough gua space to address it's extranet and the cost of aquiring space is negible compared to cost of deploying anything inside mondo-megacorp.

Joel

George Bonser <gbonser at seven.com> wrote:

>
>
>> -----Original Message-----
>> From: mcr at sandelman.ca [mailto:mcr at sandelman.ca]
>> Sent: Sunday, April 11, 2010 5:48 PM
>> To: George Bonser
>> Cc: michael.dillon at bt.com; arin-ppml at arin.net
>> Subject: Re: [arin-ppml] ULA-C
>> 
>> A question: how many of your connections are with organizations that
>> did
>> not, when they first numbered their network, even know that they were
>> going to connect with you?
>> 
>
>Let me provide something of a plausible example.  You have Mondo
>Megacorp who provides some service worldwide.  One aspect of their
>service is actually provided by a third party (Littlefish, Inc.) but
>branded as a service of Mondo Megacorp.  There is some integration of
>the billing that needs to happen because Littlefish, Inc. needs to be
>able to turn on and off service to Modo Megacorp's customers and to bill
>Mondo for services rendered.
>
>Neither company has their financial backend systems in publically routed
>network space but they need to talk to each other.  Littlefish provides
>service to a lot of bigger fish and has a lot of private connectivity to
>specific systems it needs communications with at these partners that are
>on private networks.
>
>If they are all in "private" space that is also unique, they never have
>to worry about address space collisions when they interface with each
>other on the backend.
>
>G
>_______________________________________________
>PPML
>You are receiving this message because you are subscribed to
>the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>Unsubscribe or manage your mailing list subscription at:
>http://lists.arin.net/mailman/listinfo/arin-ppml
>Please contact info at arin.net if you experience any issues.
>

From gbonser at seven.com  Sun Apr 11 21:40:53 2010
From: gbonser at seven.com (George Bonser)
Date: Sun, 11 Apr 2010 18:40:53 -0700
Subject: [arin-ppml] ULA-C
References: <5A6D953473350C4B9995546AFE9939EE08FE6E56@RWC-EX1.corp.seven.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com>



> -----Original Message-----
> From: joel jaeggli [mailto:joelja at bogus.com]
> Sent: Sunday, April 11, 2010 6:37 PM
> To: George Bonser; mcr at sandelman.ca
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] ULA-C
> 
> Mondo-megacorp will trivially have enough gua space to address it's
> extranet and the cost of aquiring space is negible compared to cost of
> deploying anything inside mondo-megacorp.
> 
> Joel
> 

Joel, you missed the point.  The do not want their financial backend systems on globally routable address space.

They do not want it to even be POSSIBLE that by some kind of misconfiguration, their systems could be reachable from the Internet.  So they put it in address space that is impossible to be reached across the public Internet.






From joelja at bogus.com  Sun Apr 11 22:14:23 2010
From: joelja at bogus.com (joel jaeggli)
Date: Sun, 11 Apr 2010 19:14:23 -0700
Subject: [arin-ppml] ULA-C
Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com>

Oddly, I work for mondo-megacorp and I find it interesting that you're speaking for all entities that fit that category collectively.  

From my vantage point ,the security posture associated with a particular prefix, service or network internal to our administrative domain is defined by requirements not by some intrinsic nature of the prefix.

George Bonser <gbonser at seven.com> wrote:

>
>
>> -----Original Message-----
>> From: joel jaeggli [mailto:joelja at bogus.com]
>> Sent: Sunday, April 11, 2010 6:37 PM
>> To: George Bonser; mcr at sandelman.ca
>> Cc: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] ULA-C
>> 
>> Mondo-megacorp will trivially have enough gua space to address it's
>> extranet and the cost of aquiring space is negible compared to cost of
>> deploying anything inside mondo-megacorp.
>> 
>> Joel
>> 
>
>Joel, you missed the point.  The do not want their financial backend systems on globally routable address space.
>
>They do not want it to even be POSSIBLE that by some kind of misconfiguration, their systems could be reachable from the Internet.  So they put it in address space that is impossible to be reached across the public Internet.
>
>
>
>
>

From owen at delong.com  Mon Apr 12 01:18:07 2010
From: owen at delong.com (Owen DeLong)
Date: Sun, 11 Apr 2010 22:18:07 -0700
Subject: [arin-ppml] ULA-C
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com>
References: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com>
Message-ID: <A7330B71-7FFE-43EC-97D2-597B91775C0E@delong.com>

Well said.  Even RFC-1918 space can be routed across the global internet due to misconfiguration, so, I fail to see how that can possibly provide the protection described.

Admittedly, the number of misconfigurations increases in inverse proportion to topological proximity, but, nonetheless, lots of routing tables see RFC-1918 space on the global internet due to misconfiguration.

Why would ULA-C or any other "special" prefix be any different?

Owen

On Apr 11, 2010, at 7:14 PM, joel jaeggli wrote:

> Oddly, I work for mondo-megacorp and I find it interesting that you're speaking for all entities that fit that category collectively.  
> 
> From my vantage point ,the security posture associated with a particular prefix, service or network internal to our administrative domain is defined by requirements not by some intrinsic nature of the prefix.
> 
> George Bonser <gbonser at seven.com> wrote:
> 
>> 
>> 
>>> -----Original Message-----
>>> From: joel jaeggli [mailto:joelja at bogus.com]
>>> Sent: Sunday, April 11, 2010 6:37 PM
>>> To: George Bonser; mcr at sandelman.ca
>>> Cc: arin-ppml at arin.net
>>> Subject: Re: [arin-ppml] ULA-C
>>> 
>>> Mondo-megacorp will trivially have enough gua space to address it's
>>> extranet and the cost of aquiring space is negible compared to cost of
>>> deploying anything inside mondo-megacorp.
>>> 
>>> Joel
>>> 
>> 
>> Joel, you missed the point.  The do not want their financial backend systems on globally routable address space.
>> 
>> They do not want it to even be POSSIBLE that by some kind of misconfiguration, their systems could be reachable from the Internet.  So they put it in address space that is impossible to be reached across the public Internet.
>> 
>> 
>> 
>> 
>> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From gbonser at seven.com  Mon Apr 12 01:24:02 2010
From: gbonser at seven.com (George Bonser)
Date: Sun, 11 Apr 2010 22:24:02 -0700
Subject: [arin-ppml] ULA-C
References: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com>
	<A7330B71-7FFE-43EC-97D2-597B91775C0E@delong.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6E63@RWC-EX1.corp.seven.com>

Can you tell me how RFC1918 space can be routed across the global
internet?

No transit provider in the world accepts those routes and assuming that
such traffic would have to traverse at least three networks
(originating, at least one transit and the destination), having all
three misconfigured is quite unlikely.

But I have never seen a transit network that will pass RFC1918 traffic.
Who would they send it to?  There must be a few hundred networks
attempting to announce that space to them.



> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com]
> Sent: Sunday, April 11, 2010 10:18 PM
> To: joel jaeggli
> Cc: George Bonser; mcr at sandelman.ca; arin-ppml at arin.net
> Subject: Re: [arin-ppml] ULA-C
> 
> Well said.  Even RFC-1918 space can be routed across the global
> internet due to misconfiguration, so, I fail to see how that can
> possibly provide the protection described.
> 
> Admittedly, the number of misconfigurations increases in inverse
> proportion to topological proximity, but, nonetheless, lots of routing
> tables see RFC-1918 space on the global internet due to
> misconfiguration.
> 
> Why would ULA-C or any other "special" prefix be any different?
> 
> Owen
> 
> On Apr 11, 2010, at 7:14 PM, joel jaeggli wrote:
> 
> > Oddly, I work for mondo-megacorp and I find it interesting that
> you're speaking for all entities that fit that category collectively.
> >
> > From my vantage point ,the security posture associated with a
> particular prefix, service or network internal to our administrative
> domain is defined by requirements not by some intrinsic nature of the
> prefix.
> >
> > George Bonser <gbonser at seven.com> wrote:
> >
> >>
> >>
> >>> -----Original Message-----
> >>> From: joel jaeggli [mailto:joelja at bogus.com]
> >>> Sent: Sunday, April 11, 2010 6:37 PM
> >>> To: George Bonser; mcr at sandelman.ca
> >>> Cc: arin-ppml at arin.net
> >>> Subject: Re: [arin-ppml] ULA-C
> >>>
> >>> Mondo-megacorp will trivially have enough gua space to address
it's
> >>> extranet and the cost of aquiring space is negible compared to
cost
> of
> >>> deploying anything inside mondo-megacorp.
> >>>
> >>> Joel
> >>>
> >>
> >> Joel, you missed the point.  The do not want their financial
backend
> systems on globally routable address space.
> >>
> >> They do not want it to even be POSSIBLE that by some kind of
> misconfiguration, their systems could be reachable from the Internet.
> So they put it in address space that is impossible to be reached
across
> the public Internet.
> >>
> >>
> >>
> >>
> >>
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.



From lear at cisco.com  Mon Apr 12 01:28:29 2010
From: lear at cisco.com (Eliot Lear)
Date: Mon, 12 Apr 2010 07:28:29 +0200
Subject: [arin-ppml] ULA-C
In-Reply-To: <A7330B71-7FFE-43EC-97D2-597B91775C0E@delong.com>
References: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com>
	<A7330B71-7FFE-43EC-97D2-597B91775C0E@delong.com>
Message-ID: <4BC2AF7D.4020702@cisco.com>

  As one of the authors of that document, much as I am no great fan, I 
have to say that no matter how hard we try, we have great difficulty 
convincing people that the prefix doesn't matter.  And there is some 
reason to believe that a well know prefix does matter, because it is 
easy for administrators (either side of the demarc) to install filters 
on well known prefixes, and at least some do.

My big issue with all of this is that by the time you're done with a 
registration service that might offer reverse DNS (is that what we're 
saying?), those filters are really the only difference between ULA-C and 
PI; and the actually necessity for them, as far as the SPs other 
customers are concerned, is considerably lessened since the spaces don't 
overlap.

Eliot

On 4/12/10 7:18 AM, Owen DeLong wrote:
> Well said.  Even RFC-1918 space can be routed across the global internet due to misconfiguration, so, I fail to see how that can possibly provide the protection described.
>
> Admittedly, the number of misconfigurations increases in inverse proportion to topological proximity, but, nonetheless, lots of routing tables see RFC-1918 space on the global internet due to misconfiguration.
>
> Why would ULA-C or any other "special" prefix be any different?
>
> Owen
>
> On Apr 11, 2010, at 7:14 PM, joel jaeggli wrote:
>
>> Oddly, I work for mondo-megacorp and I find it interesting that you're speaking for all entities that fit that category collectively.
>>
>>  From my vantage point ,the security posture associated with a particular prefix, service or network internal to our administrative domain is defined by requirements not by some intrinsic nature of the prefix.
>>
>> George Bonser<gbonser at seven.com>  wrote:
>>
>>>
>>>> -----Original Message-----
>>>> From: joel jaeggli [mailto:joelja at bogus.com]
>>>> Sent: Sunday, April 11, 2010 6:37 PM
>>>> To: George Bonser; mcr at sandelman.ca
>>>> Cc: arin-ppml at arin.net
>>>> Subject: Re: [arin-ppml] ULA-C
>>>>
>>>> Mondo-megacorp will trivially have enough gua space to address it's
>>>> extranet and the cost of aquiring space is negible compared to cost of
>>>> deploying anything inside mondo-megacorp.
>>>>
>>>> Joel
>>>>
>>> Joel, you missed the point.  The do not want their financial backend systems on globally routable address space.
>>>
>>> They do not want it to even be POSSIBLE that by some kind of misconfiguration, their systems could be reachable from the Internet.  So they put it in address space that is impossible to be reached across the public Internet.
>>>
>>>
>>>
>>>
>>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100412/c6ba9ab4/attachment.htm>

From gbonser at seven.com  Mon Apr 12 02:13:33 2010
From: gbonser at seven.com (George Bonser)
Date: Sun, 11 Apr 2010 23:13:33 -0700
Subject: [arin-ppml] ULA-C
References: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com>
	<A7330B71-7FFE-43EC-97D2-597B91775C0E@delong.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6E67@RWC-EX1.corp.seven.com>

To clarify, if you attempt to route RFC1918 across the internet, how do
you ensure it gets to the desired destination if thousands of potential
destinations are using that space and possibly hundreds of them are
announcing it (and being ignored) by their upstream.

Yes, it is "possible" to route rc1918 traffic across the internet but
there is no assurance that the rfc1918 network it is going to is your
desired "target".

It would require an incredible fluke of circumstances for that to
happen:

1. Source network announcing their RFC1918 space
2. Transit network accepting their RFC1918 space and nobody else's
except destination network.
3. Transit network announcing source network's RFC1918 space to
destination network.
4. Destination network accepting RFC1918 address space.
5. Destination network announcing RFC1918 address space and transit
provider accepting the announcement.
6. If multiple transit networks involved, they all accept both source
and destination RFC1918 space and no others becsuse that would "muddy
the water".
7. Not likely to happen on this planet but possible.



> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com]
> Sent: Sunday, April 11, 2010 10:18 PM
> To: joel jaeggli
> Cc: George Bonser; mcr at sandelman.ca; arin-ppml at arin.net
> Subject: Re: [arin-ppml] ULA-C
> 
> Well said.  Even RFC-1918 space can be routed across the global
> internet due to misconfiguration, so, I fail to see how that can
> possibly provide the protection described.
> 
> Admittedly, the number of misconfigurations increases in inverse
> proportion to topological proximity, but, nonetheless, lots of routing
> tables see RFC-1918 space on the global internet due to
> misconfiguration.
> 
> Why would ULA-C or any other "special" prefix be any different?
> 
> Owen
> 
> On Apr 11, 2010, at 7:14 PM, joel jaeggli wrote:
> 
> > Oddly, I work for mondo-megacorp and I find it interesting that
> you're speaking for all entities that fit that category collectively.
> >
> > From my vantage point ,the security posture associated with a
> particular prefix, service or network internal to our administrative
> domain is defined by requirements not by some intrinsic nature of the
> prefix.
> >
> > George Bonser <gbonser at seven.com> wrote:
> >
> >>
> >>
> >>> -----Original Message-----
> >>> From: joel jaeggli [mailto:joelja at bogus.com]
> >>> Sent: Sunday, April 11, 2010 6:37 PM
> >>> To: George Bonser; mcr at sandelman.ca
> >>> Cc: arin-ppml at arin.net
> >>> Subject: Re: [arin-ppml] ULA-C
> >>>
> >>> Mondo-megacorp will trivially have enough gua space to address
it's
> >>> extranet and the cost of aquiring space is negible compared to
cost
> of
> >>> deploying anything inside mondo-megacorp.
> >>>
> >>> Joel
> >>>
> >>
> >> Joel, you missed the point.  The do not want their financial
backend
> systems on globally routable address space.
> >>
> >> They do not want it to even be POSSIBLE that by some kind of
> misconfiguration, their systems could be reachable from the Internet.
> So they put it in address space that is impossible to be reached
across
> the public Internet.
> >>
> >>
> >>
> >>
> >>
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.



From gbonser at seven.com  Mon Apr 12 02:28:01 2010
From: gbonser at seven.com (George Bonser)
Date: Sun, 11 Apr 2010 23:28:01 -0700
Subject: [arin-ppml] ULA-C
References: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com><A7330B71-7FFE-43EC-97D2-597B91775C0E@delong.com>
	<4BC2AF7D.4020702@cisco.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6E6B@RWC-EX1.corp.seven.com>

I agree at a fundamental level that prefix doesn?t matter. And I will always add block for that space at my edge.  But it is just another tool in the box.

 

I wan?t meaning that anyone should ?rely? on the prefix for security, I meant that it was another added layer to help protect you.

 

 

 

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Eliot Lear
Sent: Sunday, April 11, 2010 10:28 PM
To: Owen DeLong
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] ULA-C

 

As one of the authors of that document, much as I am no great fan, I have to say that no matter how hard we try, we have great difficulty convincing people that the prefix doesn't matter.  And there is some reason to believe that a well know prefix does matter, because it is easy for administrators (either side of the demarc) to install filters on well known prefixes, and at least some do.

My big issue with all of this is that by the time you're done with a registration service that might offer reverse DNS (is that what we're saying?), those filters are really the only difference between ULA-C and PI; and the actually necessity for them, as far as the SPs other customers are concerned, is considerably lessened since the spaces don't overlap.

Eliot

On 4/12/10 7:18 AM, Owen DeLong wrote: 

Well said.  Even RFC-1918 space can be routed across the global internet due to misconfiguration, so, I fail to see how that can possibly provide the protection described.
 
Admittedly, the number of misconfigurations increases in inverse proportion to topological proximity, but, nonetheless, lots of routing tables see RFC-1918 space on the global internet due to misconfiguration.
 
Why would ULA-C or any other "special" prefix be any different?
 
Owen
 
On Apr 11, 2010, at 7:14 PM, joel jaeggli wrote:
 

	Oddly, I work for mondo-megacorp and I find it interesting that you're speaking for all entities that fit that category collectively.  
	 
	>From my vantage point ,the security posture associated with a particular prefix, service or network internal to our administrative domain is defined by requirements not by some intrinsic nature of the prefix.
	 
	George Bonser <gbonser at seven.com> <mailto:gbonser at seven.com>  wrote:
	 

		 
		 

			-----Original Message-----
			From: joel jaeggli [mailto:joelja at bogus.com]
			Sent: Sunday, April 11, 2010 6:37 PM
			To: George Bonser; mcr at sandelman.ca
			Cc: arin-ppml at arin.net
			Subject: Re: [arin-ppml] ULA-C
			 
			Mondo-megacorp will trivially have enough gua space to address it's
			extranet and the cost of aquiring space is negible compared to cost of
			deploying anything inside mondo-megacorp.
			 
			Joel
			 

		 
		Joel, you missed the point.  The do not want their financial backend systems on globally routable address space.
		 
		They do not want it to even be POSSIBLE that by some kind of misconfiguration, their systems could be reachable from the Internet.  So they put it in address space that is impossible to be reached across the public Internet.
		 
		 
		 
		 
		 

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

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100411/f366bd28/attachment.htm>

From owen at delong.com  Mon Apr 12 02:30:23 2010
From: owen at delong.com (Owen DeLong)
Date: Sun, 11 Apr 2010 23:30:23 -0700
Subject: [arin-ppml] ULA-C
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE08FE6E63@RWC-EX1.corp.seven.com>
References: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com>
	<A7330B71-7FFE-43EC-97D2-597B91775C0E@delong.com>
	<5A6D953473350C4B9995546AFE9939EE08FE6E63@RWC-EX1.corp.seven.com>
Message-ID: <D58B3834-C5EA-4D7D-8CE9-549CE05463E8@delong.com>


On Apr 11, 2010, at 10:24 PM, George Bonser wrote:

> Can you tell me how RFC1918 space can be routed across the global
> internet?
> 
I didn't say it could be done without misconfiguration.  I said that it doesn't
protect you as much as you think in the case of misconfiguration.

> No transit provider in the world accepts those routes and assuming that
> such traffic would have to traverse at least three networks
> (originating, at least one transit and the destination), having all
> three misconfigured is quite unlikely.
> 
And yet, time and time again, they show up in the routing tables.

> But I have never seen a transit network that will pass RFC1918 traffic.

Look harder, it has definitely happened.

> Who would they send it to?  There must be a few hundred networks
> attempting to announce that space to them.
> 
Presumably the person who they accepted the advertisement from.
IOW, the person who has obviously misconfigured things in the way
you say it will protect you.

Owen

> 
> 
>> -----Original Message-----
>> From: Owen DeLong [mailto:owen at delong.com]
>> Sent: Sunday, April 11, 2010 10:18 PM
>> To: joel jaeggli
>> Cc: George Bonser; mcr at sandelman.ca; arin-ppml at arin.net
>> Subject: Re: [arin-ppml] ULA-C
>> 
>> Well said.  Even RFC-1918 space can be routed across the global
>> internet due to misconfiguration, so, I fail to see how that can
>> possibly provide the protection described.
>> 
>> Admittedly, the number of misconfigurations increases in inverse
>> proportion to topological proximity, but, nonetheless, lots of routing
>> tables see RFC-1918 space on the global internet due to
>> misconfiguration.
>> 
>> Why would ULA-C or any other "special" prefix be any different?
>> 
>> Owen
>> 
>> On Apr 11, 2010, at 7:14 PM, joel jaeggli wrote:
>> 
>>> Oddly, I work for mondo-megacorp and I find it interesting that
>> you're speaking for all entities that fit that category collectively.
>>> 
>>> From my vantage point ,the security posture associated with a
>> particular prefix, service or network internal to our administrative
>> domain is defined by requirements not by some intrinsic nature of the
>> prefix.
>>> 
>>> George Bonser <gbonser at seven.com> wrote:
>>> 
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: joel jaeggli [mailto:joelja at bogus.com]
>>>>> Sent: Sunday, April 11, 2010 6:37 PM
>>>>> To: George Bonser; mcr at sandelman.ca
>>>>> Cc: arin-ppml at arin.net
>>>>> Subject: Re: [arin-ppml] ULA-C
>>>>> 
>>>>> Mondo-megacorp will trivially have enough gua space to address
> it's
>>>>> extranet and the cost of aquiring space is negible compared to
> cost
>> of
>>>>> deploying anything inside mondo-megacorp.
>>>>> 
>>>>> Joel
>>>>> 
>>>> 
>>>> Joel, you missed the point.  The do not want their financial
> backend
>> systems on globally routable address space.
>>>> 
>>>> They do not want it to even be POSSIBLE that by some kind of
>> misconfiguration, their systems could be reachable from the Internet.
>> So they put it in address space that is impossible to be reached
> across
>> the public Internet.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.



From gbonser at seven.com  Mon Apr 12 02:45:38 2010
From: gbonser at seven.com (George Bonser)
Date: Sun, 11 Apr 2010 23:45:38 -0700
Subject: [arin-ppml] ULA-C
References: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com>
	<A7330B71-7FFE-43EC-97D2-597B91775C0E@delong.com>
	<5A6D953473350C4B9995546AFE9939EE08FE6E63@RWC-EX1.corp.seven.com>
	<D58B3834-C5EA-4D7D-8CE9-549CE05463E8@delong.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6E6E@RWC-EX1.corp.seven.com>

Inline

> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com]
> Sent: Sunday, April 11, 2010 11:30 PM
> To: George Bonser
> Cc: joel jaeggli; mcr at sandelman.ca; arin-ppml at arin.net
> Subject: Re: [arin-ppml] ULA-C
> 
> 
> On Apr 11, 2010, at 10:24 PM, George Bonser wrote:
> 
> > Can you tell me how RFC1918 space can be routed across the global
> > internet?
> >
> I didn't say it could be done without misconfiguration.  I said that
it
> doesn't
> protect you as much as you think in the case of misconfiguration.
> 
> > No transit provider in the world accepts those routes and assuming
> that
> > such traffic would have to traverse at least three networks
> > (originating, at least one transit and the destination), having all
> > three misconfigured is quite unlikely.
> >
> And yet, time and time again, they show up in the routing tables.

Yes, but probably not to the destination network you are trying to get
to. You are missing my point.  RFC1918 being in the routing table does
not equate to that being the RFC1918 address of the network you would be
targeting.  In fact, they might have eleventy zillion paths to 10/8 for
all I know.  I suppose email is too difficult a forum for me to express
myself on this subject.  Just because RFC1918 addresses might be present
in the routing table doesn't mean you can access foo.com's RFC1918 space
from bar.com.  It just means that SOMEONE is announcing the same space
from someplace and that you are believing it.

For a purposeful end to end connection to be made from foo.com to
bar.com's RFC1918 space there would need to be an incredible number of
mistakes to be made along the path.  So imagine you are connecting from
192.168.1.1 to 192.168.2.2 ...whose 192.168.2.2 are you connecting to?  

In the case if unique private space, that problem goes away.  Anyone
with unique private space would potentially be reachable IF A: they
announced it  B: their transit provider believed it C: their peers
believed it D: destination network believes it.

I think the case of all four of those cases being true is less than if
one is using global space.  If one is using global space then everyone
will believe it as a matter of course.



> 
> > But I have never seen a transit network that will pass RFC1918
> traffic.
> 
> Look harder, it has definitely happened.

Granted, it possibly has.  I haven't noticed, basically because I block
such announcements at the front door.



From mcr at sandelman.ca  Mon Apr 12 08:42:51 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Mon, 12 Apr 2010 08:42:51 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <4BBC0D5D.2060903@umn.edu> 
References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net>
	<4BA76279.9060809@umn.edu>
	<07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com>
	<k2h75cb24521004052242g4a4cdafy766dcdd1ee2a3b85@mail.gmail.com>
	<8695009A81378E48879980039EEDAD28876D4435@MAIL1.polartel.local>
	<o2y3c3e3fca1004060823n3df2085au5f992b20628c65de@mail.gmail.com>
	<8695009A81378E48879980039EEDAD28876D443A@MAIL1.polartel.local>
	<p2s3c3e3fca1004061302t9ae20cedma1dba6fdcd880fe7@mail.gmail.com>
	<4BBC0D5D.2060903@umn.edu> 
Message-ID: <7357.1271076171@marajade.sandelman.ca>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


David, I want to thank you for the summary.
I have waited a few days to see the responses, before contributing.

You make 7 points.  It seems that the thread has gone astray again.
Your first 4 points address the issue of leakage, and why a unique
prefix is better than having NCN randomly in the PI space, yet there is
a long thread that misses those points completely.

I believe that point #4 is very important, so I repeat it:
  > 4. The availability of ULA-C for internal addressing will likely
  > make PA addressing facing the Internet more palatable at least for
  > some classes of enterprise users.  This might be implemented with
  > NAT66, multiple RAs, or any number of possible future solutions.
  > Like maybe some variation of LISP, or some other GSE type solutions.
  > But, the details are irrelevant that is an operational issue not a
  > policy one. 

I think it's important to remember how IPv4 came to occur.  FIRST,
Enterprises deployed it.  They did it because having IP services were
useful.  They did so without any expectation that they would "connect"
to the Internet --- they were already connected to themselves.
(Who remembers when Apple had to renumber?)

Responders to your email have not clearly said, "I disagree with point
1", yet they continue to argue it.  

I am glad that you understand point #5 -- about DNS and VPNs.
(Those who know what IETF work I've done, realize that most of my work
in the 2000s has been at intersection of DNS and IPsec...)

Contraversal points you list are #6 and #7. 

    David> 6. ULA-C, currently proposed as FC00::/8, is a much more
    David> limited resource than GUA 2000::/3, and since resource are
    David> being globally dedicated to individual organizations, some
    David> mechanism to ensure the long-term stewardship of those
    David> resource is necessary. The RIRs seem well suited to provide
    David> the necessary stewardship, as they already do this at a
    David> global scale for many other number resources, why build
    David> something new.

I completely agree.   I want the RIRs to do this. 


    David> 7. ULA-C, even with a global well-known prefix, is just
    David> another 128bit integer, there is nothing fundamentally
    David> different about it, than PA or PI.  In fact, with registered
    David> uniqueness, reverse DNS, and maybe even RPKI in the future,
    David> the only practical difference between ULA-C and PI is the
    David> non-routed property, applied realistically only by
    David> convention. There is one possible other difference, random
    David> prefix selection.  While this could help prevent some kinds
    David> of abuse, I'm not sure this would provide much practical
    David> deterrence in using ULA-C as a substitute for PI. Which I
    David> believe is the primary abuse path of concern.

I put no value on the randomness, but I do not object to it, but that's
not the crux of your point. (Scanning the lower /64 bits is sufficient
randomness for me)

RPKI) I don't see why RPKI certificates would be issued for ULA-C space.
      If they were, it would be for completeness, and would specify a
      non-existant/reserved/invalid ASN.  This itself would provide an
      additional hurdle against leakage.
      
      If RPKI was legitimately issued, it would be issued, in my
      opinion, from a different CA. Most likely anyone that needed RPKI
      for their ULA-C would be running their own CA.  My opinion (as a
      security geek), is that running your own CA exceeds the cost of
      getting PI space!!


    David> Therefore, I believe the concerns about ULA-C becoming a path
    David> for policy abuse cannot be completely discounted.  However,
    David> in reality the risk is no where near as large as some are
    David> claiming.  Further, I believe this risk can be easily managed
    David> via the RIRs' number resource policy processes, if the RIRs
    David> were to be given full policy control of ULA-C registrations.

I agree --- there could be abuse.
Rather than overconstrain ourselves in advance, is there nothing we can
do on a complaint basis?

    David> I believe, the stewardship the RIRs provide is necessary, and
    David> the RIRs' policy processes can properly manage the risk.  As
    David> for cost, while not a policy matter, in the shorter-term
    David> ULA-C is not going to be as cost effective as some would
    David> hope.  However, if in the longer-term the risks can be
    David> managed, then I have to believe that the RIRs will do the
    David> right thing.

    David> So, is some kind of compromise between the opposing camps
    David> possible? Otherwise, I fear this is going to continue to be a
    David> pointless shouting match.

I can deal with these statements. They *do* represent a compromise to
me.

Michael Dillon?
Bill Herrin?

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS8MVMoCLcPvd0N1lAQIjrwgAkUXbUxipqkSeKumCoRmF0tM94La4RJfB
Qdjj8nnuIaSxeAU9CHQBUobX6HB6nHTzpXjqrgPIuT9vd6LUbF2MEHn8ZfJDlceu
5+Cv89FEn9khtAKpQKnPrwA67nhAM/ukY/3XWTwlCJ052vK74dtTTsMk5RhT/5G2
oE1Zgvi6PG7snL2aAWlMZ5dgP2zcG7WEbqy+F2toVlRwIRxbid8eIj02VXKWNwZw
GVew5t3rPfbqdUM2Othf3XDdfik8z/2GajnQnSoz+WCwFzENvSPiT0HIpoVq4Kmo
UHwn1WG04n22ur4NVRBinRQv9PBQorrIN5nWdR1SXnImYPVQ6Psntw==
=fsXT
-----END PGP SIGNATURE-----


From kkargel at polartel.com  Mon Apr 12 10:50:17 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 12 Apr 2010 09:50:17 -0500
Subject: [arin-ppml] ULA-C
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE08FE6E63@RWC-EX1.corp.seven.com>
References: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com>
	<A7330B71-7FFE-43EC-97D2-597B91775C0E@delong.com>
	<5A6D953473350C4B9995546AFE9939EE08FE6E63@RWC-EX1.corp.seven.com>
Message-ID: <8695009A81378E48879980039EEDAD28876D4499@MAIL1.polartel.local>

> 
> Can you tell me how RFC1918 space can be routed across the global
> internet?
> 
For an experiment have your edge router log traffic to/from RFC1918 addresses.  I think you will be surprised to see that some *is* being routed over the internet but hopefully being stopped at your global edge.

A quick look at an incoming filter on one of my edges shows:
deny ip 10.0.0.0 0.255.255.255 any (262873 matches)
deny ip 172.16.0.0 0.0.255.255 any (18474 matches)
deny ip 192.168.0.0 0.0.255.255 any (127131 matches)

I realize it is not a overpowering amount of traffic but it does exist.

Kevin



From cgrundemann at gmail.com  Mon Apr 12 11:13:29 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Mon, 12 Apr 2010 09:13:29 -0600
Subject: [arin-ppml] ULA-C
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE08FE6E6E@RWC-EX1.corp.seven.com>
References: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com>
	<A7330B71-7FFE-43EC-97D2-597B91775C0E@delong.com>
	<5A6D953473350C4B9995546AFE9939EE08FE6E63@RWC-EX1.corp.seven.com>
	<D58B3834-C5EA-4D7D-8CE9-549CE05463E8@delong.com>
	<5A6D953473350C4B9995546AFE9939EE08FE6E6E@RWC-EX1.corp.seven.com>
Message-ID: <j2u443de7ad1004120813m412c97d7t7e1c7fca41a08e6e@mail.gmail.com>

Perhaps mostly for my own sanity I would like to summarize what I
believe has been said a number of times in these threads as simply as
possible so that we might move forward a bit:

1) "Private" address space (with or without NAT) is not a very good
security measure (if a measure at all).
2) Regardless of the validity of point number one (which I happen to
agree with) there are a large number of Orgs and folks who  believe
that they *need* "private" address space.

And my own take on what this means:
1) ARIN is responsible to the entire community.
2) The community contains people who want/need "private" address space.
3) Therefor, ARIN should work to provide "private" address space to
the community.

We should probably focus on the draft policies on the plate for
Toronto and put the whole ULA-C conversation on hold until after the
meeting, but at that more appropriate time someone should draft a
policy proposal that addresses the assigning of ULA-C to those who
believe they need it.  Then we can discuss the policy details and stop
debating the operational (read: not policy related) issues surrounding
"private" address space and NAT (maybe).

$0.02
~Chris

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




-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From cengel at sponsordirect.com  Mon Apr 12 11:42:33 2010
From: cengel at sponsordirect.com (Chris Engel)
Date: Mon, 12 Apr 2010 11:42:33 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <mailman.1032.1271049569.28982.arin-ppml@arin.net>
Message-ID: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA62C@Skyhawk>

Owen DeLong wrote:


> Well said.  Even RFC-1918 space can be routed across the
> global internet due to misconfiguration, so, I fail to see
> how that can possibly provide the protection described.
>
> Admittedly, the number of misconfigurations increases in
> inverse proportion to topological proximity, but,
> nonetheless, lots of routing tables see RFC-1918 space on the
> global internet due to misconfiguration.
>
> Why would ULA-C or any other "special" prefix be any different?
>
> Owen
>
> On Apr 11, 2010, at 7:14 PM, joel jaeggli wrote:
>
> > Oddly, I work for mondo-megacorp and I find it interesting
> that you're
> > speaking for all entities that fit that category collectively.
> >
> > From my vantage point ,the security posture associated with a
> > particular prefix, service or network internal to our
> administrative
> > domain is defined by requirements not by some intrinsic
> nature of the
> > prefix.


With RFC-1918 there are two things that HELP prevent it from being routed to you. Firstly it's understood by convention that it's not supposed to be routed across the global internet... meaning that a non-negligible number of admins are going to decline to route it. Secondly it's not unique, so even if an admin accepted routes for it, the chance that it would be YOUR particular route and nobody elses is also fairly small. Granted, the chances that it would be routed to you are still some number higher then 0 percent.... but we all know that in security there is no such thing as a 0 percent chance of exploit (perfect defense). Any measure that reduces the chance of exploit by ANY degree has some value as a protection.

With ULA-C, you do take away the non-unique factor but you still have the understood not to be globaly routed factor which does help. It's the same reason why people stop at red lights. There is nothing magical about the color red that makes car's apply thier breaks. It's simply well understood by most drivers that the color red means STOP. The color chosen doesn't really matter (just like the pre-fix), it could have been blue, orange or violet.... what matters is that it's a color easly distinguishable from the one which indicates GO (green) and that the convention of what you are SUPPOSED to do has been widely published and is well understood by most drivers who use the road.

That's why ULA-C has value. The actual pre-fix chosen doesn't matter... what matters is that it's WIDELY published and understood what the INTENT of an address within that range is... so that when people see it, they can at least easily recognize what they are SUPPOSED to do with it. No one can force them to follow that convention, but at least the information is available for them to do so, if they choose. By contrast, it's not particularly easy for an admin to know that some guy half-way across the world is using this particular portion of his GUA for his private network and doesn't want it routed and this other particular portion of his GUA should be routed, if you happen to get announcements for both.


Furthermore, I fail to see what the big hang-up is here. I don't think anyone is trying to speak for all domains and tell them that they MUST use ULA space for their private networks. By all means, if anyone that want's to use a portion of their GUA space for that... there is nothing in ULA that would hinder them from doing so. However, a certain percentage of the community clearly feels that there would be value in having ULA-C space. If there is no particular shortage of address space in IPv6, and the people who want it are willing to pay the costs to support ULA-C and we minimize the potential for abuse by treating it fee/policy wise identical to PI... where is the objection?

Do we really need to micro-manage everyone else's networks & addressing choices for them.... or can we accept that different people have different views/approaches/values and provide for a wide range of options so that as many folks as possible can pursue the approach that THEY feel works best for them?



Christopher Engel



From lear at cisco.com  Mon Apr 12 11:30:15 2010
From: lear at cisco.com (Eliot Lear)
Date: Mon, 12 Apr 2010 17:30:15 +0200
Subject: [arin-ppml] ULA-C
In-Reply-To: <4BBC0D5D.2060903@umn.edu>
References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net>	<4BA76279.9060809@umn.edu>	<07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com>	<k2h75cb24521004052242g4a4cdafy766dcdd1ee2a3b85@mail.gmail.com>	<8695009A81378E48879980039EEDAD28876D4435@MAIL1.polartel.local>	<o2y3c3e3fca1004060823n3df2085au5f992b20628c65de@mail.gmail.com>	<8695009A81378E48879980039EEDAD28876D443A@MAIL1.polartel.local>	<p2s3c3e3fca1004061302t9ae20cedma1dba6fdcd880fe7@mail.gmail.com>
	<4BBC0D5D.2060903@umn.edu>
Message-ID: <4BC33C87.8010304@cisco.com>

  David,

Thank you for that summary.  This has been an interesting discussion.

My own reading of the "room" is that people have come to understand that 
if you assign a price of 0 to something that has value without any 
bounds on acquisition of that resource, someone somewhere will arbitrage 
the difference.  The way the community has attempted to prevent that is 
through restrictions on "ownership", including a needs assessment and a 
limitation on transfers.  It would seem prudent to maintain the same 
sorts of restrictions for ULA-C that we have for any other IP address as 
you wrote, particularly if reverse DNS is offered.  At that point, even 
more so than you wrote, the difference between PI and ULA-C is strictly 
a matter of service provider policy, and nothing more, with even fewer 
externalities than that of RFC 1918 addresses .  Indeed under those 
circumstances, a single service provider could offer VPN services using 
ULA-C without MPLS, although let us agree that the edge configuration 
might be a bit more "interesting".

This leads to my own ultimate question: why doesn't Section 6.5.8 cover 
interior needs sufficiently?  And this goes to your point (4), which I 
quote:

> 4. The availability of ULA-C for internal addressing will likely make 
> PA addressing facing the Internet more palatable at least for some 
> classes of enterprise users.  This might be implemented with NAT66, 
> multiple RAs, or any number of possible future solutions.  Like maybe 
> some variation of LISP, or some other GSE type solutions.  But, the 
> details are irrelevant that is an operational issue not a policy one. 

Of the arguments in your message, it would seem to me that this one, 
combined with whatever security argument one would be the ones that 
should be further developed.  In addition, given that ARIN and the RIRs 
have demonstrated reasonable flexibility in terms of making changes to 
policies, one could reasonably ask the question as to whether this 
proposal is well timed.  The introduction of NAT66 into the discussion 
is one that would need to be carefully considered, and LISP and ILNP 
(GSE's successor) are still nascent technologies.

Regards,

Eliot

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100412/774bf895/attachment.htm>

From kkargel at polartel.com  Mon Apr 12 12:03:07 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 12 Apr 2010 11:03:07 -0500
Subject: [arin-ppml] ULA-C
In-Reply-To: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA62C@Skyhawk>
References: <mailman.1032.1271049569.28982.arin-ppml@arin.net>
	<F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA62C@Skyhawk>
Message-ID: <8695009A81378E48879980039EEDAD28876D44A3@MAIL1.polartel.local>

> > Well said.  Even RFC-1918 space can be routed across the
> > global internet due to misconfiguration, so, I fail to see
> > how that can possibly provide the protection described.
> >
> > Admittedly, the number of misconfigurations increases in
> > inverse proportion to topological proximity, but,
> > nonetheless, lots of routing tables see RFC-1918 space on the
> > global internet due to misconfiguration.
> >
> > Why would ULA-C or any other "special" prefix be any different?
> >
> > Owen
> >
> > On Apr 11, 2010, at 7:14 PM, joel jaeggli wrote:
> >
> > > Oddly, I work for mondo-megacorp and I find it interesting
> > that you're
> > > speaking for all entities that fit that category collectively.
> > >
> > > From my vantage point ,the security posture associated with a
> > > particular prefix, service or network internal to our
> > administrative
> > > domain is defined by requirements not by some intrinsic
> > nature of the
> > > prefix.
> 
> 
I am in the camp where I do not see any real added value to ULA, but at the same time it won't hurt to provide ULA so if people want it why not.

If we really wanted to swing to the other side of the pendulum, and there is plenty of good space, then perhaps what we should do is to just automatically include a corresponding ULA allocation with each and every GUA allocation..  

It would simplify recordkeeping if the ULA pool were the same size as the GUA pool, so a mirror allocation could be made.  Then there would only need be one registration and database entry for each GUA/ULA pair assigned.

An alternate idea would be to shift the GUA address right eight bits.  For example if I were allocated GUA of 2610:188::0/32 then I could be allocated ULA at fc00:2610:188::0/48 automatically.  Again it would be such a simple repeatable pattern there would only need be one registration and could be done at no additional cost.  

Kevin




From kkargel at polartel.com  Mon Apr 12 12:49:01 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 12 Apr 2010 11:49:01 -0500
Subject: [arin-ppml] FW:  ULA-C
Message-ID: <8695009A81378E48879980039EEDAD28876D44A6@MAIL1.polartel.local>

ERK!  Monday morning math correction..  Sorry all..  I meant sixteen bits but typed eight.




I am in the camp where I do not see any real added value to ULA, but at the same time it won't hurt to provide ULA so if people want it why not.

If we really wanted to swing to the other side of the pendulum, and there is plenty of good space, then perhaps what we should do is to just automatically include a corresponding ULA allocation with each and every GUA allocation..  

It would simplify recordkeeping if the ULA pool were the same size as the GUA pool, so a mirror allocation could be made.  Then there would only need be one registration and database entry for each GUA/ULA pair assigned.

An alternate idea would be to shift the GUA address right SIXTEEN (not eight) bits.  For example if I were allocated GUA of 2610:188::0/32 then I could be allocated ULA at fc00:2610:188::0/48 automatically.  Again it would be such a simple repeatable pattern there would only need be one registration and could be done at no additional cost.  

Kevin




From kkargel at polartel.com  Mon Apr 12 15:42:13 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 12 Apr 2010 14:42:13 -0500
Subject: [arin-ppml] FW:  ULA-C
In-Reply-To: <20100412191814.GB15291@vacation.karoshi.com.>
References: <8695009A81378E48879980039EEDAD28876D44A6@MAIL1.polartel.local>
	<20100412191814.GB15291@vacation.karoshi.com.>
Message-ID: <8695009A81378E48879980039EEDAD28876D44B1@MAIL1.polartel.local>

> > An alternate idea would be to shift the GUA address right SIXTEEN (not
> eight) bits.  For example if I were allocated GUA of 2610:188::0/32 then I
> could be allocated ULA at fc00:2610:188::0/48 automatically.  Again it
> would be such a simple repeatable pattern there would only need be one
> registration and could be done at no additional cost.
> >
> > Kevin
> 
> 	do you think that all five (and maybe six) RIRs would buy into this
> as a global
> 	addressing policy?
> 
> --bill

I have no idea, I was just throwing something out that might make ULA more facile..  but if people thought it was a good idea here it should be just as good an idea elsewhere.

Kevin



From farmer at umn.edu  Mon Apr 12 19:44:43 2010
From: farmer at umn.edu (David Farmer)
Date: Mon, 12 Apr 2010 18:44:43 -0500
Subject: [arin-ppml] ULA-C
In-Reply-To: <j2u443de7ad1004120813m412c97d7t7e1c7fca41a08e6e@mail.gmail.com>
References: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com>	<A7330B71-7FFE-43EC-97D2-597B91775C0E@delong.com>	<5A6D953473350C4B9995546AFE9939EE08FE6E63@RWC-EX1.corp.seven.com>	<D58B3834-C5EA-4D7D-8CE9-549CE05463E8@delong.com>	<5A6D953473350C4B9995546AFE9939EE08FE6E6E@RWC-EX1.corp.seven.com>
	<j2u443de7ad1004120813m412c97d7t7e1c7fca41a08e6e@mail.gmail.com>
Message-ID: <4BC3B06B.5050603@umn.edu>

Chris Grundemann wrote:
> Perhaps mostly for my own sanity I would like to summarize what I
> believe has been said a number of times in these threads as simply as
> possible so that we might move forward a bit:
> 
> 1) "Private" address space (with or without NAT) is not a very good
> security measure (if a measure at all).
> 2) Regardless of the validity of point number one (which I happen to
> agree with) there are a large number of Orgs and folks who  believe
> that they *need* "private" address space.
> 
> And my own take on what this means:
> 1) ARIN is responsible to the entire community.
> 2) The community contains people who want/need "private" address space.
> 3) Therefor, ARIN should work to provide "private" address space to
> the community.

I agree with all of those points.

> We should probably focus on the draft policies on the plate for
> Toronto and put the whole ULA-C conversation on hold until after the
> meeting, but at that more appropriate time someone should draft a
> policy proposal that addresses the assigning of ULA-C to those who
> believe they need it.  

I mostly agree except for one point, currently DP2010-8 includes 
assignments of PI address space for non-connected networks (NCN). This 
basically comes from the concept of NCN as it is in current IPv4 policy.

Personally, I believe there is a place for both NCN PI and for
ULA-C.  Further, I believe PI, NCN PI, and ULA-C, should have similar if 
not identical policies, but that is for a later discussion. Also, I 
believe NCN PI and ULA-C can be treated as separate policy questions.

However, I'm not sure everyone agrees with this.  So, the ULA-C question 
may inject itself into DP2010-8's discussion.  Additionally, for 
DP2010-7 a non-routed prefix is likely to be a point of discussion too. 
Therefore, at least some understanding of where to go with ULA-C may 
become necessary to move 2010-8 or 2010-7 forward, which ever direction 
we decide to go.

As you suggest if possible, it might be helpful if we could discuss 
these policies in isolation of the ULA-C question and then come back to 
the ULA-C question for the next round of policy discussions.  But, this 
will take everyones cooperation, I don't think it would be proper to 
dictate this from the podium.

Another possible tactic would be to eliminate both NCN PI or a 
non-routed prefix from these policies and include that as part of a 
ULA-C policy discussion.

Other ideas?

How would people prefer to proceed on this?  A little thought ahead of 
time on this might help focus the discussion and make for a more 
effective floor discussion in Toronto.

Thanks

> Then we can discuss the policy details and stop
> debating the operational (read: not policy related) issues surrounding
> "private" address space and NAT (maybe).

Yes, please.

> $0.02
> ~Chris

In my opinion it is worth way more than $0.02. :)

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



From farmer at umn.edu  Mon Apr 12 20:08:17 2010
From: farmer at umn.edu (David Farmer)
Date: Mon, 12 Apr 2010 19:08:17 -0500
Subject: [arin-ppml] ULA-C
In-Reply-To: <7357.1271076171@marajade.sandelman.ca>
References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net>
	<4BA76279.9060809@umn.edu>
	<07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com>
	<k2h75cb24521004052242g4a4cdafy766dcdd1ee2a3b85@mail.gmail.com>
	<8695009A81378E48879980039EEDAD28876D4435@MAIL1.polartel.local>
	<o2y3c3e3fca1004060823n3df2085au5f992b20628c65de@mail.gmail.com>
	<8695009A81378E48879980039EEDAD28876D443A@MAIL1.polartel.local>
	<p2s3c3e3fca1004061302t9ae20cedma1dba6fdcd880fe7@mail.gmail.com>
	<4BBC0D5D.2060903@umn.edu> <7357.1271076171@marajade.sandelman.ca>
Message-ID: <4BC3B5F1.4040204@umn.edu>

Michael Richardson wrote:

>     David> 7. ULA-C, even with a global well-known prefix, is just
>     David> another 128bit integer, there is nothing fundamentally
>     David> different about it, than PA or PI.  In fact, with registered
>     David> uniqueness, reverse DNS, and maybe even RPKI in the future,
>     David> the only practical difference between ULA-C and PI is the
>     David> non-routed property, applied realistically only by
>     David> convention. There is one possible other difference, random
>     David> prefix selection.  While this could help prevent some kinds
>     David> of abuse, I'm not sure this would provide much practical
>     David> deterrence in using ULA-C as a substitute for PI. Which I
>     David> believe is the primary abuse path of concern.
> 
> I put no value on the randomness, but I do not object to it, but that's
> not the crux of your point. (Scanning the lower /64 bits is sufficient
> randomness for me)

Yep, I don't care either way too. But there is one thing random 
assignment from the full ULA-C prefix would accomplish; it would prevent 
someone from easily accepting ARIN's ULA-C assignments and not the other 
RIR's ULA-C assignments.  And preventing it from becoming a regional PI 
substitute.  Is this worth the hassle?  I don't know.

> RPKI) I don't see why RPKI certificates would be issued for ULA-C space.
>       If they were, it would be for completeness, and would specify a
>       non-existant/reserved/invalid ASN.  This itself would provide an
>       additional hurdle against leakage.
>       
>       If RPKI was legitimately issued, it would be issued, in my
>       opinion, from a different CA. Most likely anyone that needed RPKI
>       for their ULA-C would be running their own CA.  My opinion (as a
>       security geek), is that running your own CA exceeds the cost of
>       getting PI space!!

I don't want to derail things with a discussion of RPKI for ULA-C, there 
are many different ways to deal with it I'm not sure what the right 
answers are.  But just like I think those that want Authoritative 
Reverse DNS for ULA-C should be able to get it, if someone wants an RPKI 
certificate from ARIN for their ULA-C assignment, why not?  And it is 
yet another reason to have the RIR's do ULA-C assignment.  ULA-C is just 
more of the same of what the RIRs do now.

>     David> Therefore, I believe the concerns about ULA-C becoming a path
>     David> for policy abuse cannot be completely discounted.  However,
>     David> in reality the risk is no where near as large as some are
>     David> claiming.  Further, I believe this risk can be easily managed
>     David> via the RIRs' number resource policy processes, if the RIRs
>     David> were to be given full policy control of ULA-C registrations.
> 
> I agree --- there could be abuse.
> Rather than overconstrain ourselves in advance, is there nothing we can
> do on a complaint basis?

Where do those complaints go? How do we resolve disputes? For PA and PI 
essentially that is dealt within the policy development processes for 
the RIRs. That is how we hash things out as a community, it seems 
logical to use the same processes for ULA-C.

But, I'm open to other ideas.

>     David> I believe, the stewardship the RIRs provide is necessary, and
>     David> the RIRs' policy processes can properly manage the risk.  As
>     David> for cost, while not a policy matter, in the shorter-term
>     David> ULA-C is not going to be as cost effective as some would
>     David> hope.  However, if in the longer-term the risks can be
>     David> managed, then I have to believe that the RIRs will do the
>     David> right thing.
> 
>     David> So, is some kind of compromise between the opposing camps
>     David> possible? Otherwise, I fear this is going to continue to be a
>     David> pointless shouting match.
> 
> I can deal with these statements. They *do* represent a compromise to
> me.
> 
> Michael Dillon?
> Bill Herrin?

I'm interested in what others think, is this a compromise we can all 
live with?

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


From bill at herrin.us  Mon Apr 12 20:41:56 2010
From: bill at herrin.us (William Herrin)
Date: Mon, 12 Apr 2010 20:41:56 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <D58B3834-C5EA-4D7D-8CE9-549CE05463E8@delong.com>
References: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com> 
	<A7330B71-7FFE-43EC-97D2-597B91775C0E@delong.com>
	<5A6D953473350C4B9995546AFE9939EE08FE6E63@RWC-EX1.corp.seven.com>
	<D58B3834-C5EA-4D7D-8CE9-549CE05463E8@delong.com>
Message-ID: <g2h3c3e3fca1004121741nd4d75285wdce9d55ad3495ec5@mail.gmail.com>

On Mon, Apr 12, 2010 at 2:30 AM, Owen DeLong <owen at delong.com> wrote:
>> No transit provider in the world accepts those routes and assuming that
>> such traffic would have to traverse at least three networks
>> (originating, at least one transit and the destination), having all
>> three misconfigured is quite unlikely.
>>
> And yet, time and time again, they show up in the routing tables.

Owen,

So what? You can kill them with three lines in your filter if they
bother you. As can I. As can anyone who cares. And a ULA-C will be
even easier: just one line to suppress the whole mess.

Are you so insecure about ARIN's ability to satisfy IPv6 GUA users
that you think those users will do what it takes to pressure the
network operators into reliably carrying ULA as if it was GUA? You
shouldn't be. ARIN does fine.

Hell, if it's a concern, why not offer ULA based on the registrant's
agreement not to announce it into the public Internet routing tables
and give ARIN the right to fine registrants and if necessary revoke
the registration for any uncorrected leak that someone complains
about?

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 mcr at sandelman.ca  Mon Apr 12 20:46:14 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Mon, 12 Apr 2010 20:46:14 -0400
Subject: [arin-ppml] ULA-C and RPKI
In-Reply-To: <4BC3B5F1.4040204@umn.edu> 
References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net>
	<4BA76279.9060809@umn.edu>
	<07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com>
	<k2h75cb24521004052242g4a4cdafy766dcdd1ee2a3b85@mail.gmail.com>
	<8695009A81378E48879980039EEDAD28876D4435@MAIL1.polartel.local>
	<o2y3c3e3fca1004060823n3df2085au5f992b20628c65de@mail.gmail.com>
	<8695009A81378E48879980039EEDAD28876D443A@MAIL1.polartel.local>
	<p2s3c3e3fca1004061302t9ae20cedma1dba6fdcd880fe7@mail.gmail.com>
	<4BBC0D5D.2060903@umn.edu> <7357.1271076171@marajade.sandelman.ca>
	<4BC3B5F1.4040204@umn.edu> 
Message-ID: <17252.1271119574@marajade.sandelman.ca>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "David" == David Farmer <farmer at umn.edu> writes:
    >> RPKI) I don't see why RPKI certificates would be issued for ULA-C space.
    >> If they were, it would be for completeness, and would specify a
    >> non-existant/reserved/invalid ASN.  This itself would provide an
    >> additional hurdle against leakage.
    >> If RPKI was legitimately issued, it would be issued, in my
    >> opinion, from a different CA. Most likely anyone that needed RPKI
    >> for their ULA-C would be running their own CA.  My opinion (as a
    >> security geek), is that running your own CA exceeds the cost of
    >> getting PI space!!

    David> I don't want to derail things with a discussion of RPKI for
    David> ULA-C, there are many different ways to deal with it I'm not
    David> sure what the right answers are. But just like I think those
    David> that want Authoritative Reverse DNS for ULA-C should be able
    David> to get it, if someone wants an RPKI certificate from ARIN for
    David> their ULA-C assignment, why not?  And it is yet another
    David> reason to have the RIR's do ULA-C assignment.  ULA-C is just
    David> more of the same of what the RIRs do now.

Why not?  Well because a full-validity, primary AA binding of ULA-C to
an ASN makes no operational sense.  

If we agree that the only routing of ULA-C is private small-i internets
(COINs), then those organizations that want to do this need to run their
own RPKI AA's. (AA = Authorization Authority)

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS8O+1YCLcPvd0N1lAQJwigf/au+zdCNs3/nIvtkYpwXuGKHr+amiMt6B
HeiITnhKfwkvyGMEj5CF9cqUseNUiYs8GM28PMhZt58MNoGl7WQLkBGgaUPDcJek
mbvS31+3uWjUpzrtqVC5LqmrDjN6EriRPt3zmgY5tMIdsIBpoN1yrejP8gXTvYUz
NOSBeN3GXKp0Sdv+I4DqAjTIBMlYWCMbByFAnLkXy5b6BKpN9qdbievb9PYX0g6w
CarcqElhyApN4nE7+VDuYafDM9SqcX0ershN7sn+E8APX52rj0hsBH7yNsviWQJi
jvYRvdSKmdC3+bqDBJir6Gw4Q2RZaLyhrq/QfTqNgJjnbQ+kBPFcHA==
=OAbF
-----END PGP SIGNATURE-----


From mcr at sandelman.ca  Mon Apr 12 21:00:04 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Mon, 12 Apr 2010 21:00:04 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <4BC3B5F1.4040204@umn.edu> 
References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net>
	<4BA76279.9060809@umn.edu>
	<07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com>
	<k2h75cb24521004052242g4a4cdafy766dcdd1ee2a3b85@mail.gmail.com>
	<8695009A81378E48879980039EEDAD28876D4435@MAIL1.polartel.local>
	<o2y3c3e3fca1004060823n3df2085au5f992b20628c65de@mail.gmail.com>
	<8695009A81378E48879980039EEDAD28876D443A@MAIL1.polartel.local>
	<p2s3c3e3fca1004061302t9ae20cedma1dba6fdcd880fe7@mail.gmail.com>
	<4BBC0D5D.2060903@umn.edu> <7357.1271076171@marajade.sandelman.ca>
	<4BC3B5F1.4040204@umn.edu> 
Message-ID: <18253.1271120404@marajade.sandelman.ca>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "David" == David Farmer <farmer at umn.edu> writes:
    David> Therefore, I believe the concerns about ULA-C becoming a path
    David> for policy abuse cannot be completely discounted.  However,
    David> in reality the risk is no where near as large as some are
    David> claiming.  Further, I believe this risk can be easily managed
    David> via the RIRs' number resource policy processes, if the RIRs
    David> were to be given full policy control of ULA-C registrations.

    mcr> I agree --- there could be abuse.
    mcr> Rather than overconstrain ourselves in advance, is there
    mcr> nothing we can do on a complaint basis?

    David> Where do those complaints go? How do we resolve disputes? For
    David> PA and PI essentially that is dealt within the policy
    David> development processes for the RIRs. That is how we hash
    David> things out as a community, it seems logical to use the same
    David> processes for ULA-C. 

Let's say that I start announcing 134.84.123.0/24 from my ASN.
What would you do?  Who would you complain to?

(yes, RPKI is a tool to prevent that, as is the RPDB, assume it happens)

But, assuming it gets through, how is that different than announcing
IANA's FC00::/7 on the public Internet?

What I'm asking is: why do we have to think through all possible actions
in advance, and write intricate policies... why do we have no mechanisms
to permit judgement?  There is a pathology where organizations try to
write policies for everything, as opposed to routine things+clear
exceptions, only I don't know what the word is.

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS8PCEYCLcPvd0N1lAQIxEwf/egQXX+DlSIA70YyuG+gTg7OL8eF8ya/f
y9PJj085yuwL9jSyfglDJxdDIKAXDz5Nmq/8qIcNW8Xqy++Kkn4BSlOk0+BGmGfs
IYX6RoZB6X0E6b5Baf0zwQ43zBmKoDy0W4aBnFBx4rTr4HTyt8aaoYspgFFr1Nuj
RQCBBqdeRb+V3Oa+tZFTRk9eh+gmrKKjzaVmweCm9HzVOgYUZOCVjAv2vMr00uk8
INLtf045IQKOqmkG1LWoCfibkpprgVTga2HC06Mfh617/ptc4blmkSnl+ibaJ8gT
sQP6PjDgtGICGW2lrTDOJWXOGEih6AI/SlAzbCLdHXIoYR8GeMcFGw==
=s/MA
-----END PGP SIGNATURE-----


From bill at herrin.us  Mon Apr 12 21:08:28 2010
From: bill at herrin.us (William Herrin)
Date: Mon, 12 Apr 2010 21:08:28 -0400
Subject: [arin-ppml] ULA-C and RPKI
In-Reply-To: <17252.1271119574@marajade.sandelman.ca>
References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net>
	<k2h75cb24521004052242g4a4cdafy766dcdd1ee2a3b85@mail.gmail.com> 
	<8695009A81378E48879980039EEDAD28876D4435@MAIL1.polartel.local> 
	<o2y3c3e3fca1004060823n3df2085au5f992b20628c65de@mail.gmail.com> 
	<8695009A81378E48879980039EEDAD28876D443A@MAIL1.polartel.local> 
	<p2s3c3e3fca1004061302t9ae20cedma1dba6fdcd880fe7@mail.gmail.com> 
	<4BBC0D5D.2060903@umn.edu> <7357.1271076171@marajade.sandelman.ca> 
	<4BC3B5F1.4040204@umn.edu> <17252.1271119574@marajade.sandelman.ca>
Message-ID: <k2q3c3e3fca1004121808m1885a919k72ff8b00407912bc@mail.gmail.com>

On Mon, Apr 12, 2010 at 8:46 PM, Michael Richardson <mcr at sandelman.ca> wrote:
>>>>>> "David" == David Farmer <farmer at umn.edu> writes:
> ? ?David> I don't want to derail things with a discussion of RPKI for
> ? ?David> ULA-C, there are many different ways to deal with it I'm not
> ? ?David> sure what the right answers are. But just like I think those
> ? ?David> that want Authoritative Reverse DNS for ULA-C should be able
> ? ?David> to get it, if someone wants an RPKI certificate from ARIN for
> ? ?David> their ULA-C assignment, why not? ?And it is yet another
> ? ?David> reason to have the RIR's do ULA-C assignment. ?ULA-C is just
> ? ?David> more of the same of what the RIRs do now.
>
> Why not? ?Well because a full-validity, primary AA binding of ULA-C to
> an ASN makes no operational sense.
>
> If we agree that the only routing of ULA-C is private small-i internets
> (COINs), then those organizations that want to do this need to run their
> own RPKI AA's. (AA = Authorization Authority)

Last I read anything about it, there wasn't enough information about
RPKI's final form to make a determination whether or not ULA could be
usefully signed.

At least one form I read is nothing more than an expression from the
space's registrant that, "this is the scope of what I announce;
anything else is false." ARIN is expected to sign any record the
legitimate registrant places before it, even if it claims
disaggregation down to /128. There's no reason ULA in this scenario
couldn't be signed by ARIN.

On the other hand, you could also use signing / refusing to sign
records as a disaggregation and entry control to try to suppress route
count in the Internet's routing tables. With justification criteria
for the record you want signed just like there was justification
criteria for getting the GUA space in the first place. Signing ULA
records in that scenario would obviously be problematic...


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 mcr at sandelman.ca  Mon Apr 12 21:14:36 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Mon, 12 Apr 2010 21:14:36 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <g2h3c3e3fca1004121741nd4d75285wdce9d55ad3495ec5@mail.gmail.com> 
References: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com>
	<A7330B71-7FFE-43EC-97D2-597B91775C0E@delong.com>
	<5A6D953473350C4B9995546AFE9939EE08FE6E63@RWC-EX1.corp.seven.com>
	<D58B3834-C5EA-4D7D-8CE9-549CE05463E8@delong.com>
	<g2h3c3e3fca1004121741nd4d75285wdce9d55ad3495ec5@mail.gmail.com>
Message-ID: <19412.1271121276@marajade.sandelman.ca>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "William" == William Herrin <bill at herrin.us> writes:
    William> So what? You can kill them with three lines in your filter if they
    William> bother you. As can I. As can anyone who cares. And a ULA-C will be
    William> even easier: just one line to suppress the whole mess.

So, if ULA is going leak, why hasn't ULA-R leaked already?

    William> Hell, if it's a concern, why not offer ULA based on the
    William> registrant's agreement not to announce it into the public
    William> Internet routing tables and give ARIN the right to fine
    William> registrants and if necessary revoke the registration for
    William> any uncorrected leak that someone complains about?

Of course, one can get around all of this by leaking ULA-R (at the cost
of whois and reverse DNS). 

If anything, offering ULA-C, and demanding this kind of agreement seems
to give ARIN more power over ULA space, rather than less.

If you give out whois and rDNS, then ARIN also winds up with the power
to insert shaming statements into those databases.

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS8PFe4CLcPvd0N1lAQIXDwf7Bq2r++ZQnGHmXeJaOjexhMIBfoETF+iv
JTPp7X9g/svh5P82lIiiKIKAu73D+7zM+oOFAS3cZUY+ynKgvGwK+8o2wjVuSXqy
20VF8alzP9MsygwxFYSQLnf3d/g0UieT3BMOCr53EBZfVXLVIyPql+A/j8UIyvXa
WDHZeo16zQM8VhD1b8kLaiIMKztKSnNAokIZkAckN+5A4awHFzLsaZfQQv0Nh3Vb
QuMQ9t/40l6V9v+LUKqVkQ90Yos8gqS4m/hcaGEaNqtI9SUwNAG2SnnB1SFI0YsN
hbpWP/nNIWuy3NBBcK4o4i3s2OEwe3CPq5OuJiBjV4VVSI7NacM8AA==
=bxU1
-----END PGP SIGNATURE-----


From owen at delong.com  Mon Apr 12 22:02:59 2010
From: owen at delong.com (Owen DeLong)
Date: Mon, 12 Apr 2010 19:02:59 -0700
Subject: [arin-ppml] ULA-C
In-Reply-To: <g2h3c3e3fca1004121741nd4d75285wdce9d55ad3495ec5@mail.gmail.com>
References: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com>
	<A7330B71-7FFE-43EC-97D2-597B91775C0E@delong.com>
	<5A6D953473350C4B9995546AFE9939EE08FE6E63@RWC-EX1.corp.seven.com>
	<D58B3834-C5EA-4D7D-8CE9-549CE05463E8@delong.com>
	<g2h3c3e3fca1004121741nd4d75285wdce9d55ad3495ec5@mail.gmail.com>
Message-ID: <3B16CEDE-291F-4AB6-AEF1-B36B92757A1B@delong.com>


On Apr 12, 2010, at 5:41 PM, William Herrin wrote:

> On Mon, Apr 12, 2010 at 2:30 AM, Owen DeLong <owen at delong.com> wrote:
>>> No transit provider in the world accepts those routes and assuming that
>>> such traffic would have to traverse at least three networks
>>> (originating, at least one transit and the destination), having all
>>> three misconfigured is quite unlikely.
>>> 
>> And yet, time and time again, they show up in the routing tables.
> 
> Owen,
> 
> So what? You can kill them with three lines in your filter if they
> bother you. As can I. As can anyone who cares. And a ULA-C will be
> even easier: just one line to suppress the whole mess.
> 
The discussion was about whether RFC-1918/ULA provide a security
benefit or could be accidentally advertised.

My point is that they can and are.

> Are you so insecure about ARIN's ability to satisfy IPv6 GUA users
> that you think those users will do what it takes to pressure the
> network operators into reliably carrying ULA as if it was GUA? You
> shouldn't be. ARIN does fine.
> 
Not at all.  I'm not opposed to ULA implemented in a non-harmful way.

I am opposed to perpetuating the myth that it somehow enhances
security.

Owen



From bill at herrin.us  Mon Apr 12 22:33:07 2010
From: bill at herrin.us (William Herrin)
Date: Mon, 12 Apr 2010 22:33:07 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <3B16CEDE-291F-4AB6-AEF1-B36B92757A1B@delong.com>
References: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com> 
	<A7330B71-7FFE-43EC-97D2-597B91775C0E@delong.com>
	<5A6D953473350C4B9995546AFE9939EE08FE6E63@RWC-EX1.corp.seven.com>
	<D58B3834-C5EA-4D7D-8CE9-549CE05463E8@delong.com>
	<g2h3c3e3fca1004121741nd4d75285wdce9d55ad3495ec5@mail.gmail.com>
	<3B16CEDE-291F-4AB6-AEF1-B36B92757A1B@delong.com>
Message-ID: <v2h3c3e3fca1004121933lc324680fif5c7462de005a4ea@mail.gmail.com>

On Mon, Apr 12, 2010 at 10:02 PM, Owen DeLong <owen at delong.com> wrote:
> The discussion was about whether RFC-1918/ULA provide a security
> benefit or could be accidentally advertised.

My mistake. I thought the discussion was about whether or not
accidental advertisements could pose a policy-level threat to Internet
operations, not whether readily cleaned negligible-impact accidents
were possible.


>?I'm not opposed to ULA implemented in a non-harmful way.
>
> I am opposed to perpetuating the myth that it somehow enhances
> security.

Then it's fortunate that no one has proposed an ARIN declaration that
ULA is good for Internet security. Fortunate indeed that the proposal
on the table is merely to allow folks to register the ULA space they
use so that no one accidentally uses the same space, without the
onerous hoops and costs justifiably needed for the assignment and
allocation of GUA space.

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 owen at delong.com  Mon Apr 12 22:36:41 2010
From: owen at delong.com (Owen DeLong)
Date: Mon, 12 Apr 2010 19:36:41 -0700
Subject: [arin-ppml] ULA-C
In-Reply-To: <v2h3c3e3fca1004121933lc324680fif5c7462de005a4ea@mail.gmail.com>
References: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com>
	<A7330B71-7FFE-43EC-97D2-597B91775C0E@delong.com>
	<5A6D953473350C4B9995546AFE9939EE08FE6E63@RWC-EX1.corp.seven.com>
	<D58B3834-C5EA-4D7D-8CE9-549CE05463E8@delong.com>
	<g2h3c3e3fca1004121741nd4d75285wdce9d55ad3495ec5@mail.gmail.com>
	<3B16CEDE-291F-4AB6-AEF1-B36B92757A1B@delong.com>
	<v2h3c3e3fca1004121933lc324680fif5c7462de005a4ea@mail.gmail.com>
Message-ID: <AE00BBD9-2AFF-44F6-BAA6-B4FEA10BA9C9@delong.com>

> 
> Then it's fortunate that no one has proposed an ARIN declaration that
> ULA is good for Internet security. Fortunate indeed that the proposal
> on the table is merely to allow folks to register the ULA space they
> use so that no one accidentally uses the same space, without the
> onerous hoops and costs justifiably needed for the assignment and
> allocation of GUA space.
> 
The latter part, the without the hops and justifiable need issue is a
policy problem, indeed.  If ARIN is to issue ULA, it should be on
substantially the same terms as GUA so that there is no incentive
to (mis)use ULA where GUA is required.

I am all for reducing the GUA barrier to non-onerous.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100412/415d824b/attachment.htm>

From bill at herrin.us  Mon Apr 12 23:08:48 2010
From: bill at herrin.us (William Herrin)
Date: Mon, 12 Apr 2010 23:08:48 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <AE00BBD9-2AFF-44F6-BAA6-B4FEA10BA9C9@delong.com>
References: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com> 
	<A7330B71-7FFE-43EC-97D2-597B91775C0E@delong.com>
	<5A6D953473350C4B9995546AFE9939EE08FE6E63@RWC-EX1.corp.seven.com>
	<D58B3834-C5EA-4D7D-8CE9-549CE05463E8@delong.com>
	<g2h3c3e3fca1004121741nd4d75285wdce9d55ad3495ec5@mail.gmail.com>
	<3B16CEDE-291F-4AB6-AEF1-B36B92757A1B@delong.com>
	<v2h3c3e3fca1004121933lc324680fif5c7462de005a4ea@mail.gmail.com>
	<AE00BBD9-2AFF-44F6-BAA6-B4FEA10BA9C9@delong.com>
Message-ID: <y2p3c3e3fca1004122008uc07a9a66m8fd0f5c224387302@mail.gmail.com>

On Mon, Apr 12, 2010 at 10:36 PM, Owen DeLong <owen at delong.com> wrote:
> The latter part, the without the hops and justifiable need issue is a
> policy problem, indeed. ?If ARIN is to issue ULA, it should be on
> substantially the same terms as GUA so that there is no incentive
> to (mis)use ULA where GUA is required.
> I am all for reducing the GUA barrier to non-onerous.

And so we're back full circle to the beginning where you're not
opposed to ULA as long as it's actually GUA and you're not opposed to
making GUA non-onerous as long as we retain all the barriers and costs
that make it onerous.



-- 
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 michel at arneill-py.sacramento.ca.us  Mon Apr 12 23:48:29 2010
From: michel at arneill-py.sacramento.ca.us (Michel Py)
Date: Mon, 12 Apr 2010 20:48:29 -0700
Subject: [arin-ppml] ULA-C
In-Reply-To: <3B16CEDE-291F-4AB6-AEF1-B36B92757A1B@delong.com>
References: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com><A7330B71-7FFE-43EC-97D2-597B91775C0E@delong.com><5A6D953473350C4B9995546AFE9939EE08FE6E63@RWC-EX1.corp.seven.com><D58B3834-C5EA-4D7D-8CE9-549CE05463E8@delong.com><g2h3c3e3fca1004121741nd4d75285wdce9d55ad3495ec5@mail.gmail.com>
	<3B16CEDE-291F-4AB6-AEF1-B36B92757A1B@delong.com>
Message-ID: <471D76419F9EF642962323D13DF1DF690118BA@newserver.arneill-py.local>

> Owen DeLong
> I am opposed to perpetuating the myth that it somehow enhances
security.

The reason RFC1918 addresses "enhance" security is because they are
ambiguous. The odds of your ISP announcing your RFC1918 prefix on the
GRT are small: it requires a screw-up both on your side and on your
ISP's side. Furthermore, even though this occasionally happens, chances
are that even if this happens, you won't be at much risk.

My router's IP address is 192.168.1.1. Come and attack it. Oh, you
successfully DDOSed a Linksys in Waikiki beach. Congratulations. 

Now, that being said, the IPv6 game is different. As long as the size of
any IPv6 pool is "large-enough-to-be-almost-unique", there will be
temptations to announce it and therefore make it vulnerable.

The so-called "security" does not come from the address being labeled as
"private".

Michel.



From owen at delong.com  Tue Apr 13 00:03:52 2010
From: owen at delong.com (Owen DeLong)
Date: Mon, 12 Apr 2010 21:03:52 -0700
Subject: [arin-ppml] ULA-C
In-Reply-To: <y2p3c3e3fca1004122008uc07a9a66m8fd0f5c224387302@mail.gmail.com>
References: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com>
	<A7330B71-7FFE-43EC-97D2-597B91775C0E@delong.com>
	<5A6D953473350C4B9995546AFE9939EE08FE6E63@RWC-EX1.corp.seven.com>
	<D58B3834-C5EA-4D7D-8CE9-549CE05463E8@delong.com>
	<g2h3c3e3fca1004121741nd4d75285wdce9d55ad3495ec5@mail.gmail.com>
	<3B16CEDE-291F-4AB6-AEF1-B36B92757A1B@delong.com>
	<v2h3c3e3fca1004121933lc324680fif5c7462de005a4ea@mail.gmail.com>
	<AE00BBD9-2AFF-44F6-BAA6-B4FEA10BA9C9@delong.com>
	<y2p3c3e3fca1004122008uc07a9a66m8fd0f5c224387302@mail.gmail.com>
Message-ID: <83193A72-D442-4312-B579-02BBD39DA065@delong.com>


On Apr 12, 2010, at 8:08 PM, William Herrin wrote:

> On Mon, Apr 12, 2010 at 10:36 PM, Owen DeLong <owen at delong.com> wrote:
>> The latter part, the without the hops and justifiable need issue is a
>> policy problem, indeed.  If ARIN is to issue ULA, it should be on
>> substantially the same terms as GUA so that there is no incentive
>> to (mis)use ULA where GUA is required.
>> I am all for reducing the GUA barrier to non-onerous.
> 
> And so we're back full circle to the beginning where you're not
> opposed to ULA as long as it's actually GUA and you're not opposed to
> making GUA non-onerous as long as we retain all the barriers and costs
> that make it onerous.
> 
Not at all... ULA as strictly address space that's theoretically unroutable
is fine with me.  I'm all for making GUA available for significantly lower
fees than the current pricing if it can be done practically. I am not for
any elimination of justified need, but, I'm actually willing to go pretty far
on lowering the level required for justified need.  Probably much further
than many other people.

Owen



From farmer at umn.edu  Tue Apr 13 00:12:53 2010
From: farmer at umn.edu (David Farmer)
Date: Mon, 12 Apr 2010 23:12:53 -0500
Subject: [arin-ppml] ULA-C
In-Reply-To: <4BC33C87.8010304@cisco.com>
References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net>	<4BA76279.9060809@umn.edu>	<07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com>	<k2h75cb24521004052242g4a4cdafy766dcdd1ee2a3b85@mail.gmail.com>	<8695009A81378E48879980039EEDAD28876D4435@MAIL1.polartel.local>	<o2y3c3e3fca1004060823n3df2085au5f992b20628c65de@mail.gmail.com>	<8695009A81378E48879980039EEDAD28876D443A@MAIL1.polartel.local>	<p2s3c3e3fca1004061302t9ae20cedma1dba6fdcd880fe7@mail.gmail.com>
	<4BBC0D5D.2060903@umn.edu> <4BC33C87.8010304@cisco.com>
Message-ID: <4BC3EF45.7050903@umn.edu>

Eliot Lear wrote:

> This leads to my own ultimate question: why doesn't Section 6.5.8 cover 
> interior needs sufficiently?  

At least right now, in the end for ARIN, I believe a common policy for 
PI, NCN PI, and ULA-C makes sense to me.  Or, if for some reason one 
policy isn't doable, then three different policies that are essentially 
identical.

However, I've been trying not to jump strait to a final conclusion, but 
to help facilitate the process of finding a consensus that allows ULA-C 
to move forward.  And I have to admit, I've waffled on and rethought the 
exact details a number of times in the past few months regarding ULA-C.

Further, until we can develop a consensus for how ULA-C should work, who 
should provide the registry services for it, and under what kind of 
terms, coming up with an ARIN policy for making ULA-C assignments, 
through 6.5.8 or what ever final process seems premature.

> And this goes to your point (4), which I 
> quote:
> 
>> 4. The availability of ULA-C for internal addressing will likely make 
>> PA addressing facing the Internet more palatable at least for some 
>> classes of enterprise users.  This might be implemented with NAT66, 
>> multiple RAs, or any number of possible future solutions.  Like maybe 
>> some variation of LISP, or some other GSE type solutions.  But, the 
>> details are irrelevant that is an operational issue not a policy one. 
> 
> Of the arguments in your message, it would seem to me that this one, 
> combined with whatever security argument one would be the ones that 
> should be further developed.  

Do you have suggestion how to further develop this argument?

> In addition, given that ARIN and the RIRs 
> have demonstrated reasonable flexibility in terms of making changes to 
> policies, one could reasonably ask the question as to whether this 
> proposal is well timed.  

Could you clarify what you mean here, are you suggesting this should 
wait?  If so, to an extent I agree, we realistically can't take this up 
until the Fall ARIN meeting, is that still to soon? However, as I 
discuss in my response to Chris, this issue is at least partially 
entwined in a couple policies that will be discussed next week in Toronto.

> The introduction of NAT66 into the discussion 
> is one that would need to be carefully considered, and LISP and ILNP 
> (GSE's successor) are still nascent technologies.

Are the considerations with regard to NAT66 and ILNP different for ULA-C 
than for ULA-L (RFC 4193)?

> Regards,
> 
> Eliot

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


From bill at herrin.us  Tue Apr 13 00:50:17 2010
From: bill at herrin.us (William Herrin)
Date: Tue, 13 Apr 2010 00:50:17 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <83193A72-D442-4312-B579-02BBD39DA065@delong.com>
References: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com> 
	<A7330B71-7FFE-43EC-97D2-597B91775C0E@delong.com>
	<5A6D953473350C4B9995546AFE9939EE08FE6E63@RWC-EX1.corp.seven.com>
	<D58B3834-C5EA-4D7D-8CE9-549CE05463E8@delong.com>
	<g2h3c3e3fca1004121741nd4d75285wdce9d55ad3495ec5@mail.gmail.com>
	<3B16CEDE-291F-4AB6-AEF1-B36B92757A1B@delong.com>
	<v2h3c3e3fca1004121933lc324680fif5c7462de005a4ea@mail.gmail.com>
	<AE00BBD9-2AFF-44F6-BAA6-B4FEA10BA9C9@delong.com>
	<y2p3c3e3fca1004122008uc07a9a66m8fd0f5c224387302@mail.gmail.com>
	<83193A72-D442-4312-B579-02BBD39DA065@delong.com>
Message-ID: <y2n3c3e3fca1004122150sd9a79b80y7d86dc1ae31caa1d@mail.gmail.com>

On Tue, Apr 13, 2010 at 12:03 AM, Owen DeLong <owen at delong.com> wrote:
>
> On Apr 12, 2010, at 8:08 PM, William Herrin wrote:
>
>> On Mon, Apr 12, 2010 at 10:36 PM, Owen DeLong <owen at delong.com> wrote:
>>> The latter part, the without the hops and justifiable need issue is a
>>> policy problem, indeed. ?If ARIN is to issue ULA, it should be on
>>> substantially the same terms as GUA so that there is no incentive
>>> to (mis)use ULA where GUA is required.
>>> I am all for reducing the GUA barrier to non-onerous.
>>
>> And so we're back full circle to the beginning where you're not
>> opposed to ULA as long as it's actually GUA and you're not opposed to
>> making GUA non-onerous as long as we retain all the barriers and costs
>> that make it onerous.
>>
> Not at all... ULA as strictly address space that's theoretically unroutable
> is fine with me. ?I'm all for making GUA available for significantly lower
> fees than the current pricing if it can be done practically. I am not for
> any elimination of justified need, but, I'm actually willing to go pretty far
> on lowering the level required for justified need. ?Probably much further
> than many other people.

Well, I will work with you tirelessly to identify practical ways to
improve the process for getting GUA space, but that doesn't help the
folks who intend to use ULA space. They have a need poorly served by
any GUA or GUA-pinned regime you've suggested: negligible cost grab
and go addresses for use with the barest hint of planning, consuming
only the most trivial of the registry services: entries in two
databases.

I don't think we want that for GUA. I think we *want* people to
carefully consider how they intend to use GUA addresses before
requesting them from the registry and throwing route announcements.
Don't you?


Of course if you'd rather, we can simply build up the ULA registry at
http://www.sixxs.net/tools/grh/ula/list/

It'll be done poorly versus what a strong operation like ARIN is
capable of but it'll meet the actual registered ULA need.

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 owen at delong.com  Tue Apr 13 01:14:57 2010
From: owen at delong.com (Owen DeLong)
Date: Mon, 12 Apr 2010 22:14:57 -0700
Subject: [arin-ppml] ULA-C
In-Reply-To: <y2n3c3e3fca1004122150sd9a79b80y7d86dc1ae31caa1d@mail.gmail.com>
References: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com>
	<A7330B71-7FFE-43EC-97D2-597B91775C0E@delong.com>
	<5A6D953473350C4B9995546AFE9939EE08FE6E63@RWC-EX1.corp.seven.com>
	<D58B3834-C5EA-4D7D-8CE9-549CE05463E8@delong.com>
	<g2h3c3e3fca1004121741nd4d75285wdce9d55ad3495ec5@mail.gmail.com>
	<3B16CEDE-291F-4AB6-AEF1-B36B92757A1B@delong.com>
	<v2h3c3e3fca1004121933lc324680fif5c7462de005a4ea@mail.gmail.com>
	<AE00BBD9-2AFF-44F6-BAA6-B4FEA10BA9C9@delong.com>
	<y2p3c3e3fca1004122008uc07a9a66m8fd0f5c224387302@mail.gmail.com>
	<83193A72-D442-4312-B579-02BBD39DA065@delong.com>
	<y2n3c3e3fca1004122150sd9a79b80y7d86dc1ae31caa1d@mail.gmail.com>
Message-ID: <F34DDCEC-B4E1-4C0B-BAB2-E92321038ED0@delong.com>


On Apr 12, 2010, at 9:50 PM, William Herrin wrote:

> On Tue, Apr 13, 2010 at 12:03 AM, Owen DeLong <owen at delong.com> wrote:
>> 
>> On Apr 12, 2010, at 8:08 PM, William Herrin wrote:
>> 
>>> On Mon, Apr 12, 2010 at 10:36 PM, Owen DeLong <owen at delong.com> wrote:
>>>> The latter part, the without the hops and justifiable need issue is a
>>>> policy problem, indeed.  If ARIN is to issue ULA, it should be on
>>>> substantially the same terms as GUA so that there is no incentive
>>>> to (mis)use ULA where GUA is required.
>>>> I am all for reducing the GUA barrier to non-onerous.
>>> 
>>> And so we're back full circle to the beginning where you're not
>>> opposed to ULA as long as it's actually GUA and you're not opposed to
>>> making GUA non-onerous as long as we retain all the barriers and costs
>>> that make it onerous.
>>> 
>> Not at all... ULA as strictly address space that's theoretically unroutable
>> is fine with me.  I'm all for making GUA available for significantly lower
>> fees than the current pricing if it can be done practically. I am not for
>> any elimination of justified need, but, I'm actually willing to go pretty far
>> on lowering the level required for justified need.  Probably much further
>> than many other people.
> 
> Well, I will work with you tirelessly to identify practical ways to
> improve the process for getting GUA space, but that doesn't help the
> folks who intend to use ULA space. They have a need poorly served by
> any GUA or GUA-pinned regime you've suggested: negligible cost grab
> and go addresses for use with the barest hint of planning, consuming
> only the most trivial of the registry services: entries in two
> databases.
> 
> I don't think we want that for GUA. I think we *want* people to
> carefully consider how they intend to use GUA addresses before
> requesting them from the registry and throwing route announcements.
> Don't you?
> 
This is where we differ most strongly.  I'm really tired of the <pick your
noun> that GUA == Route Announcement or that route announcements are
somehow evil or should be avoided by the RIR.

1.	Not all uses for GUA will end up in the DFZ.
2.	It's not ARIN's place to judge who is worthy or set the criteria by
	which others decide who is worthy of entries in the DFZ. That is
	best left for people who run actual routers.

So, having said that, I think that ULA should have a little bit stronger
criteria than grab-and-go without planning anything. I think that GUA
should also have a little bit stronger criteria than that.

I do not think either should be much stronger than that.

> 
> Of course if you'd rather, we can simply build up the ULA registry at
> http://www.sixxs.net/tools/grh/ula/list/
> 
Have fun with that.  Personally, I think that project is short-sighted and
harmful, but, as I've said, there's nothing ARIN can do about people who
want to run competing registries... Even if they chose to issue from 2000::/3.

> It'll be done poorly versus what a strong operation like ARIN is
> capable of but it'll meet the actual registered ULA need.
> 
Maybe it will, maybe it won't.  I'm not particularly concerned with it one way
or another because I don't think it will gain as much traction as something
done by the RIR system. I choose to try and work in the ARIN framework
to make the best policies possible for the community in that framework.
I participate to much lesser extents in APNIC, RIPE, LACNIC, and AfriNIC.
I simply do not have the time to put significant effort into policies in other
registries.  If I did, I'd probably be more focused on domain name registry/
registrar messes before I'd spend time on the sixxs ULA registry.

Owen



From lear at cisco.com  Tue Apr 13 04:34:05 2010
From: lear at cisco.com (Eliot Lear)
Date: Tue, 13 Apr 2010 10:34:05 +0200
Subject: [arin-ppml] ULA-C
In-Reply-To: <4BC3EF45.7050903@umn.edu>
References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net>	<4BA76279.9060809@umn.edu>	<07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com>	<k2h75cb24521004052242g4a4cdafy766dcdd1ee2a3b85@mail.gmail.com>	<8695009A81378E48879980039EEDAD28876D4435@MAIL1.polartel.local>	<o2y3c3e3fca1004060823n3df2085au5f992b20628c65de@mail.gmail.com>	<8695009A81378E48879980039EEDAD28876D443A@MAIL1.polartel.local>	<p2s3c3e3fca1004061302t9ae20cedma1dba6fdcd880fe7@mail.gmail.com>
	<4BBC0D5D.2060903@umn.edu> <4BC33C87.8010304@cisco.com>
	<4BC3EF45.7050903@umn.edu>
Message-ID: <4BC42C7D.3050004@cisco.com>

  David,

> Further, until we can develop a consensus for how ULA-C should work, 
> who should provide the registry services for it, and under what kind 
> of terms, coming up with an ARIN policy for making ULA-C assignments, 
> through 6.5.8 or what ever final process seems premature.

My point was that absent additional information (see below), ARIN is 
already there for PI.

>
>> And this goes to your point (4), which I quote:
>>
>>> 4. The availability of ULA-C for internal addressing will likely 
>>> make PA addressing facing the Internet more palatable at least for 
>>> some classes of enterprise users.  This might be implemented with 
>>> NAT66, multiple RAs, or any number of possible future solutions.  
>>> Like maybe some variation of LISP, or some other GSE type 
>>> solutions.  But, the details are irrelevant that is an operational 
>>> issue not a policy one. 
>>
>> Of the arguments in your message, it would seem to me that this one, 
>> combined with whatever security argument one would be the ones that 
>> should be further developed. 
>
> Do you have suggestion how to further develop this argument?

I wrote the above because I don't understand how (4) is a driver, and so 
I presume others don't either.

>
>> In addition, given that ARIN and the RIRs have demonstrated 
>> reasonable flexibility in terms of making changes to policies, one 
>> could reasonably ask the question as to whether this proposal is well 
>> timed. 
>
> Could you clarify what you mean here, are you suggesting this should 
> wait?  If so, to an extent I agree, we realistically can't take this 
> up until the Fall ARIN meeting, is that still to soon? However, as I 
> discuss in my response to Chris, this issue is at least partially 
> entwined in a couple policies that will be discussed next week in 
> Toronto.

I'll put it another way: is there substantial customer demand for a 
service such as ULA-C?  I don't see it.  Until such time as others see 
it, why would we execute so soon?  With regard to NCNs, I can see them 
being related; but again, the policy process is pretty flexible.  In as 
much as demand is there, I would let that be the determining factor for 
timing, so long as we don't make decisions that would foreclose options 
or do not properly steward the space.  Do you see that happening here?
>
>> The introduction of NAT66 into the discussion is one that would need 
>> to be carefully considered, and LISP and ILNP (GSE's successor) are 
>> still nascent technologies.
>
> Are the considerations with regard to NAT66 and ILNP different for 
> ULA-C than for ULA-L (RFC 4193)?

Only modestly so.  Were I an SP, I probably would probably be more 
reticent to route RFC 4193 addresses, given the eventuality that a 
collision will occur in those cases.  That means that NAT66 is actually 
more of an interest for ULA-L.  If I'm an enterprise, once I'm spending 
money for addresses, I might as well get something that offers me the 
most flexibility from a routing perspective.  That might as well be PI.  
The same argument applies to ILNP/LISP.

Eliot


From owen at delong.com  Tue Apr 13 09:02:31 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 13 Apr 2010 06:02:31 -0700
Subject: [arin-ppml] ULA-C
In-Reply-To: <4BC42C7D.3050004@cisco.com>
References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net>	<4BA76279.9060809@umn.edu>	<07B89580-34D1-4F02-BFD0-A7ADE6490B69@delong.com>	<k2h75cb24521004052242g4a4cdafy766dcdd1ee2a3b85@mail.gmail.com>	<8695009A81378E48879980039EEDAD28876D4435@MAIL1.polartel.local>	<o2y3c3e3fca1004060823n3df2085au5f992b20628c65de@mail.gmail.com>	<8695009A81378E48879980039EEDAD28876D443A@MAIL1.polartel.local>	<p2s3c3e3fca1004061302t9ae20cedma1dba6fdcd880fe7@mail.gmail.com>
	<4BBC0D5D.2060903@umn.edu> <4BC33C87.8010304@cisco.com>
	<4BC3EF45.7050903@umn.edu> <4BC42C7D.3050004@cisco.com>
Message-ID: <7F219DCC-B4C3-4089-8387-40C1EE916AF1@delong.com>

>> 
>>> And this goes to your point (4), which I quote:
>>> 
>>>> 4. The availability of ULA-C for internal addressing will likely make PA addressing facing the Internet more palatable at least for some classes of enterprise users.  This might be implemented with NAT66, multiple RAs, or any number of possible future solutions.  Like maybe some variation of LISP, or some other GSE type solutions.  But, the details are irrelevant that is an operational issue not a policy one. 
>>> 
>>> Of the arguments in your message, it would seem to me that this one, combined with whatever security argument one would be the ones that should be further developed. 
>> 
>> Do you have suggestion how to further develop this argument?
> 
> I wrote the above because I don't understand how (4) is a driver, and so I presume others don't either.
> 
Regardless of your opinion on the subject (and mine is well known), there is a fraction of the community who believe that having ULA addresses for your interior and mapping those through NAT66 to provider assigned addresses is a good solution to the difficulty of renumbering and necessary to make IPv6 deployment palatable in their enterprise.

This is the rationale behind point 4 being a driver.

>> 
>>> In addition, given that ARIN and the RIRs have demonstrated reasonable flexibility in terms of making changes to policies, one could reasonably ask the question as to whether this proposal is well timed. 
>> 
>> Could you clarify what you mean here, are you suggesting this should wait?  If so, to an extent I agree, we realistically can't take this up until the Fall ARIN meeting, is that still to soon? However, as I discuss in my response to Chris, this issue is at least partially entwined in a couple policies that will be discussed next week in Toronto.
> 
> I'll put it another way: is there substantial customer demand for a service such as ULA-C?  I don't see it.  Until such time as others see it, why would we execute so soon?  With regard to NCNs, I can see them being related; but again, the policy process is pretty flexible.  In as much as demand is there, I would let that be the determining factor for timing, so long as we don't make decisions that would foreclose options or do not properly steward the space.  Do you see that happening here?

I do not know the size of the demand, but, there are at least a few vocal proponents of the idea. In fairness, they seem to be about the same in number as the vocal opponents of NAT66. It is almost impossible to determine the size of the constituencies lined up on either side, and, I suspect the vast majority of the community doesn't really care as long as they can get to their preferred content.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100413/d3d60ac2/attachment.htm>

From bill at herrin.us  Tue Apr 13 09:26:03 2010
From: bill at herrin.us (William Herrin)
Date: Tue, 13 Apr 2010 09:26:03 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <F34DDCEC-B4E1-4C0B-BAB2-E92321038ED0@delong.com>
References: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com> 
	<D58B3834-C5EA-4D7D-8CE9-549CE05463E8@delong.com>
	<g2h3c3e3fca1004121741nd4d75285wdce9d55ad3495ec5@mail.gmail.com>
	<3B16CEDE-291F-4AB6-AEF1-B36B92757A1B@delong.com>
	<v2h3c3e3fca1004121933lc324680fif5c7462de005a4ea@mail.gmail.com>
	<AE00BBD9-2AFF-44F6-BAA6-B4FEA10BA9C9@delong.com>
	<y2p3c3e3fca1004122008uc07a9a66m8fd0f5c224387302@mail.gmail.com>
	<83193A72-D442-4312-B579-02BBD39DA065@delong.com>
	<y2n3c3e3fca1004122150sd9a79b80y7d86dc1ae31caa1d@mail.gmail.com>
	<F34DDCEC-B4E1-4C0B-BAB2-E92321038ED0@delong.com>
Message-ID: <w2z3c3e3fca1004130626tbcce240m73050a16db4c784c@mail.gmail.com>

On Tue, Apr 13, 2010 at 1:14 AM, Owen DeLong <owen at delong.com> wrote:
> This is where we differ most strongly. ?I'm really tired of the <pick your
> noun> that GUA == Route Announcement or that route announcements are
> somehow evil or should be avoided by the RIR.
>
> 1. ? ? ?Not all uses for GUA will end up in the DFZ.
> 2. ? ? ?It's not ARIN's place to judge who is worthy or set the criteria by
> ? ? ? ?which others decide who is worthy of entries in the DFZ. That is
> ? ? ? ?best left for people who run actual routers.

Owen,

If you can get the netops to sign off on eliminating things like the
multihomed criteria and the the minimum host count criteria which for
IPv6 /48's serve solely to  suppress the public route count, I'll
stand in support. I think that's a fantasy but more power to you.


> So, having said that, I think that ULA should have a little bit stronger
> criteria than grab-and-go without planning anything. I think that GUA
> should also have a little bit stronger criteria than that.

This is where your position is unreasonable and self-serving. ULA is
private IP addresses, the successor in spirit to the no-rules RFC1918.
Of course it has to be grab and go. Self-serving because the real
reason you don't want it to be grab and go is that would mess with
your idea of unifying it with the GUA policy which would be difficult
to responsibly architect as grab and go.

Make your case for making RFC1918 more difficult to get than it is if
you want, but please get on the same page as the rest of us in
understanding that ULA is IPv6's RFC1918 with a nearly identical use
profile regardless of whether a registry is involved.



>> Of course if you'd rather, we can simply build up the ULA registry at
>> http://www.sixxs.net/tools/grh/ula/list/
>>
> Have fun with that. ?Personally, I think that project is short-sighted and
> harmful, but, as I've said, there's nothing ARIN can do about people who
> want to run competing registries.

It has 25% as many ULA registrations as IPv6 GUA announcements on the
public Internet and is growing as fast or faster than IPv6 is. Barring
someone else stepping forward to do a proper job (i.e. the RIRs) it's
on track to hit critical mass around the same time as IPv6 over all.

It doesn't do a great job meeting the need we're discussing, but it
does meet that need, something at which the notions you've suggested
still fall short.

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 bill at herrin.us  Tue Apr 13 09:32:10 2010
From: bill at herrin.us (William Herrin)
Date: Tue, 13 Apr 2010 09:32:10 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <4BC42C7D.3050004@cisco.com>
References: <28E139F46D45AF49A31950F88C497458058E241E@E03MVZ2-UKDY.domain1.systemhost.net>
	<k2h75cb24521004052242g4a4cdafy766dcdd1ee2a3b85@mail.gmail.com> 
	<8695009A81378E48879980039EEDAD28876D4435@MAIL1.polartel.local> 
	<o2y3c3e3fca1004060823n3df2085au5f992b20628c65de@mail.gmail.com> 
	<8695009A81378E48879980039EEDAD28876D443A@MAIL1.polartel.local> 
	<p2s3c3e3fca1004061302t9ae20cedma1dba6fdcd880fe7@mail.gmail.com> 
	<4BBC0D5D.2060903@umn.edu> <4BC33C87.8010304@cisco.com>
	<4BC3EF45.7050903@umn.edu> <4BC42C7D.3050004@cisco.com>
Message-ID: <n2t3c3e3fca1004130632h37b7fff2l81f286eddf73b71c@mail.gmail.com>

On Tue, Apr 13, 2010 at 4:34 AM, Eliot Lear <lear at cisco.com> wrote:
> I'll put it another way: is there substantial customer demand for a service
> such as ULA-C? ?I don't see it.

Eliot,

2900 routes in the public table. 700 ULA "registrations" at
http://www.sixxs.net/tools/grh/ula/list/ . What do the numbers tell
you about the relative demand?

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 marty at akamai.com  Tue Apr 13 10:05:26 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Tue, 13 Apr 2010 10:05:26 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <n2t3c3e3fca1004130632h37b7fff2l81f286eddf73b71c@mail.gmail.com>
Message-ID: <C7E9F266.2C4F6%marty@akamai.com>



> From: William Herrin <bill at herrin.us>
> Date: Tue, 13 Apr 2010 09:32:10 -0400
> To: Eliot Lear <lear at cisco.com>
> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] ULA-C
> 
> On Tue, Apr 13, 2010 at 4:34 AM, Eliot Lear <lear at cisco.com> wrote:
>> I'll put it another way: is there substantial customer demand for a service
>> such as ULA-C? ?I don't see it.
> 
> Eliot,
> 
> 2900 routes in the public table. 700 ULA "registrations" at
> http://www.sixxs.net/tools/grh/ula/list/ . What do the numbers tell
> you about the relative demand?
> 


Not a lot. If you clean up the data and make it unique to Name it's quite a
bit less. I'd say noise in the grand scheme of things.

Best,

-M<



From owen at delong.com  Tue Apr 13 10:11:29 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 13 Apr 2010 07:11:29 -0700
Subject: [arin-ppml] ULA-C
In-Reply-To: <w2z3c3e3fca1004130626tbcce240m73050a16db4c784c@mail.gmail.com>
References: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com>
	<D58B3834-C5EA-4D7D-8CE9-549CE05463E8@delong.com>
	<g2h3c3e3fca1004121741nd4d75285wdce9d55ad3495ec5@mail.gmail.com>
	<3B16CEDE-291F-4AB6-AEF1-B36B92757A1B@delong.com>
	<v2h3c3e3fca1004121933lc324680fif5c7462de005a4ea@mail.gmail.com>
	<AE00BBD9-2AFF-44F6-BAA6-B4FEA10BA9C9@delong.com>
	<y2p3c3e3fca1004122008uc07a9a66m8fd0f5c224387302@mail.gmail.com>
	<83193A72-D442-4312-B579-02BBD39DA065@delong.com>
	<y2n3c3e3fca1004122150sd9a79b80y7d86dc1ae31caa1d@mail.gmail.com>
	<F34DDCEC-B4E1-4C0B-BAB2-E92321038ED0@delong.com>
	<w2z3c3e3fca1004130626tbcce240m73050a16db4c784c@mail.gmail.com>
Message-ID: <C8597C38-AB87-4F68-9E03-EEB5A46804E4@delong.com>


On Apr 13, 2010, at 6:26 AM, William Herrin wrote:

> On Tue, Apr 13, 2010 at 1:14 AM, Owen DeLong <owen at delong.com> wrote:
>> This is where we differ most strongly.  I'm really tired of the <pick your
>> noun> that GUA == Route Announcement or that route announcements are
>> somehow evil or should be avoided by the RIR.
>> 
>> 1.      Not all uses for GUA will end up in the DFZ.
>> 2.      It's not ARIN's place to judge who is worthy or set the criteria by
>>        which others decide who is worthy of entries in the DFZ. That is
>>        best left for people who run actual routers.
> 
> Owen,
> 
> If you can get the netops to sign off on eliminating things like the
> multihomed criteria and the the minimum host count criteria which for
> IPv6 /48's serve solely to  suppress the public route count, I'll
> stand in support. I think that's a fantasy but more power to you.
> 
I think we'll eventually get [back] there. It's definitely worth the effort.

> 
>> So, having said that, I think that ULA should have a little bit stronger
>> criteria than grab-and-go without planning anything. I think that GUA
>> should also have a little bit stronger criteria than that.
> 
> This is where your position is unreasonable and self-serving. ULA is
> private IP addresses, the successor in spirit to the no-rules RFC1918.
> Of course it has to be grab and go. Self-serving because the real
> reason you don't want it to be grab and go is that would mess with
> your idea of unifying it with the GUA policy which would be difficult
> to responsibly architect as grab and go.
> 
I'm not sure how you see this as self-serving. The reason I think it must
be unified is because if it is not unified, ULA-C will NOT be a successor
to RFC-1918, it will become de facto GUA without the community's
GUA policies. This isn't because it's what is best for me, it's because I
believe it is necessary for the benefit of the community as a whole.

ULA-R is the successor to RFC-1918, and, even it does not have as
much protection from "GUA-Creep" for lack of a better term as RFC-1918
did. This is the advantage and the curse of the much larger address
space. Collisions are so much less likely that there is enough uniqueness
to represent a risk that these addresses may be used as a substitute for
GUA. That would negatively impact the community in two ways:

1.	It would make ULA meaningless to those that want it as an
	address space regarded by the community as un-routable on
	the "global internet".

2.	It would make GUA policies far less effective or meaningful
	as ULA becomes an end-run for those policies.

> Make your case for making RFC1918 more difficult to get than it is if
> you want, but please get on the same page as the rest of us in
> understanding that ULA is IPv6's RFC1918 with a nearly identical use
> profile regardless of whether a registry is involved.
> 
I agree with you about the community's intended use of RFC-1918 and
ULA. If I did not, I would probably be opposed to ULA in general rather
than specifically opposed to a ULA policy that invites abuse.

However, intended use and unintended consequences both need to
be evaluated. A non-unified policy for ULA/GUA will lead to abuse of
ULA as an end-run for GUA which is, in my opinion, an unacceptable
risk.

> 
> 
>>> Of course if you'd rather, we can simply build up the ULA registry at
>>> http://www.sixxs.net/tools/grh/ula/list/
>>> 
>> Have fun with that.  Personally, I think that project is short-sighted and
>> harmful, but, as I've said, there's nothing ARIN can do about people who
>> want to run competing registries.
> 
> It has 25% as many ULA registrations as IPv6 GUA announcements on the
> public Internet and is growing as fast or faster than IPv6 is. Barring
> someone else stepping forward to do a proper job (i.e. the RIRs) it's
> on track to hit critical mass around the same time as IPv6 over all.
> 
Your statement here is mathematically inconsistent with itself.

Be that as it may, even if this registry hits critical mass, it's much less likely
that ISPs might consider advertising routes based on this registry than based
on data in an RIR. In any case, there's not much ARIN can do about it.
Would I rather the SIXXS registry didn't exist? Probably.  Do I think that it has
the potential to become a disservice to the community for the exact
reasons I have mentioned above? Yes.

Nonetheless, I agree that it is out of scope for ARIN policy and I do believe
that anyone has the right to build any list of integers they want.  Integers
are not property, you can't own numbers.

> It doesn't do a great job meeting the need we're discussing, but it
> does meet that need, something at which the notions you've suggested
> still fall short.
> 
As I said, enjoy. I have no problem with you registering whatever you want
in other registries. I do not want to see ARIN create opportunities to
evade ARIN policies inside other ARIN policies. ULA as you want to see ARIN
register it would do exactly that.

Owen



From bill at herrin.us  Tue Apr 13 11:15:30 2010
From: bill at herrin.us (William Herrin)
Date: Tue, 13 Apr 2010 11:15:30 -0400
Subject: [arin-ppml] ULA-C
In-Reply-To: <C8597C38-AB87-4F68-9E03-EEB5A46804E4@delong.com>
References: <5A6D953473350C4B9995546AFE9939EE08FE6E58@RWC-EX1.corp.seven.com> 
	<3B16CEDE-291F-4AB6-AEF1-B36B92757A1B@delong.com>
	<v2h3c3e3fca1004121933lc324680fif5c7462de005a4ea@mail.gmail.com>
	<AE00BBD9-2AFF-44F6-BAA6-B4FEA10BA9C9@delong.com>
	<y2p3c3e3fca1004122008uc07a9a66m8fd0f5c224387302@mail.gmail.com>
	<83193A72-D442-4312-B579-02BBD39DA065@delong.com>
	<y2n3c3e3fca1004122150sd9a79b80y7d86dc1ae31caa1d@mail.gmail.com>
	<F34DDCEC-B4E1-4C0B-BAB2-E92321038ED0@delong.com>
	<w2z3c3e3fca1004130626tbcce240m73050a16db4c784c@mail.gmail.com>
	<C8597C38-AB87-4F68-9E03-EEB5A46804E4@delong.com>
Message-ID: <h2m3c3e3fca1004130815z3be70f09mab5cb55ac14ba6c7@mail.gmail.com>

On Tue, Apr 13, 2010 at 10:11 AM, Owen DeLong <owen at delong.com> wrote:
> On Apr 13, 2010, at 6:26 AM, William Herrin wrote:
>> If you can get the netops to sign off on eliminating things like the
>> multihomed criteria and the the minimum host count criteria which for
>> IPv6 /48's serve solely to ?suppress the public route count, I'll
>> stand in support.
>>
> I think we'll eventually get [back] there. It's definitely worth the effort.

More power to you.


> The reason I think it must
> be unified is because if it is not unified, ULA-C will NOT be a successor
> to RFC-1918, it will become de facto GUA without the community's
> GUA policies.

Given the trivially available controls (both technical and legal) to
prevent such an occurrence, this means you anticipate dissatisfaction
with ARIN's GUA policies to a degree that results in system collapse
unless artificially propped up. If that's a more than a paranoid fear,
perhaps you should work on solving the problems that make GUA so
unsatisfactory and let ULA do the job ULA is supposed to do.


> A non-unified policy for ULA/GUA will lead to abuse of
> ULA as an end-run for GUA which is, in my opinion, an unacceptable
> risk.

I asked in a previous message and I'll ask again: why wouldn't the
combination of ISP route filtering and policy language that directs
ARIN to revoke ULA registrations in response to misuse as GUA space
fully resolve this alleged problem?

I think you're throwing up a smoke screen here. There are perfectly
reasonable solutions to this problem that don't require a unified
policy. You seem want a unified policy and seem intent on bending the
facts of the situation to get it, regardless of whether that serves
users' needs. That's what I call self-serving... not because you
personally profit but because it serves your unjustified sense of
righteousness.

Prove me wrong. Make an honest attempt identify solutions to the
perceived route-leak problem that don't unify the policies, and
compromise.

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 info at arin.net  Tue Apr 13 12:06:25 2010
From: info at arin.net (Member Services)
Date: Tue, 13 Apr 2010 12:06:25 -0400
Subject: [arin-ppml] Attend ARIN XXV Remote Participation
Message-ID: <4BC49681.3050200@arin.net>

The ARIN XXV Public Policy and Members Meeting will be held next week in 
Toronto, and will feature a wide variety of presentations and important 
policy discussion. Can?t attend the meeting in person? No problem! ARIN 
XXV also offers many remote participation features. The entire ARIN XXV 
Meeting, including the premeeting activities, will be webcast. ARIN 
offers additional remote participation options, including a live 
transcript and chat rooms.

The live transcript will record all presentations and discussions from 
the meeting floor, so you can read along to enhance your meeting 
viewing. There will also be a variety of chat room options available to 
registered remote participants. Remote registration is free and all 
remote registrants will be listed on the ARIN website as online attendees.

To learn more about the ARIN meeting remote participation services 
please go to:

https://www.arin.net/ARIN-XXV/remote.html

Remote participants who pre-register their Jabber Identifiers (JIDs) 
will have access to the restricted chat rooms from the start of the 
meeting. You can register a JID at any time, but new participants will 
only be added during scheduled meeting breaks. Be sure to review the 
agenda at:

https://www.arin.net/ARIN-XXV/agenda.html

To ensure your access to these services, register now by going to 
?Register for ARIN XXV? at https://www.arin.net/ARIN-XXV/ and choose 
"ARIN XXV Remote Participant" from the drop-down. The form must be 
completed in order to access the meeting Jabber chat rooms. Registration 
is not required for the webcast and live transcript.

We look forward to your participation.

Regards,

Member Services

American Registry for Internet Numbers (ARIN)





From marquis at roble.com  Tue Apr 13 12:33:55 2010
From: marquis at roble.com (Roger Marquis)
Date: Tue, 13 Apr 2010 09:33:55 -0700 (PDT)
Subject: [arin-ppml] ULA-C
In-Reply-To: <mailman.5.1271174401.26062.arin-ppml@arin.net>
References: <mailman.5.1271174401.26062.arin-ppml@arin.net>
Message-ID: <20100413163355.37BF02B2128@mx5.roble.com>

William Herrin wrote:
> Owen DeLong wrote:
>> A non-unified policy for ULA/GUA will lead to abuse of
>> ULA as an end-run for GUA which is, in my opinion, an unacceptable
>> risk.
>
> I asked in a previous message and I'll ask again: why wouldn't the
> combination of ISP route filtering and policy language that directs
> ARIN to revoke ULA registrations in response to misuse as GUA space
> fully resolve this alleged problem?

I would also like to know why Owen believes filtering would be a suitable
replacement for NAT's security (such as it is), whereas similar filters
would not work for route announcements and ULA/GUA traffic.

Roger Marquis


From rsm at fast-serv.com  Tue Apr 13 13:31:49 2010
From: rsm at fast-serv.com (Randy McAnally)
Date: Tue, 13 Apr 2010 13:31:49 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
Message-ID: <20100413172714.M35473@fast-serv.com>

Why are extra-small ISP's with a /21 or /22 of v4 space forced to buy so much v6 
IP space and essentially double our fees?  I know there's a rebate in effect 
(for now) but regardless, I'm extremely displeased with this policy.

--
Randy




From tedm at ipinc.net  Tue Apr 13 14:02:30 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 13 Apr 2010 11:02:30 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <20100413172714.M35473@fast-serv.com>
References: <20100413172714.M35473@fast-serv.com>
Message-ID: <4BC4B1B6.7060804@ipinc.net>


Randy,

The assumption has always been that if your an extra-small ISP that you 
obtain IP addressing from your LIR  (ie: upstream ISP)

It isn't the amount of numbers that your planning to use that is the
problem.

The problem is that even if you got an extremely small allocation that
as soon as you advertise it, you consume the same amount of routing
resources on everyone else's BGP router on the Internet, that someone
with a larger allocation has who is advertising theirs.  Thus it is not
fair to base pricing solely on the amount of numbering.

Current IPv4 pricing is based both on the amount of numbering and
the principle that we want to make the cost-per-number more expensive
for the smaller ISPs to discourage them from obtaining portable numbers,
and encourage them to use numbers from their upstream, this reduces
growth of the DFZ.  That is why pricing on a per-IP basis gets higher
the smaller the allocations that you have.

Of course, ARIN continually claims that larger allocations require
less maintainence and smaller allocations require more maintainence
and has ginned-up reports purporting to prove this, which is why the 
smaller allocations are more expensive on a per-IP basis, but we all 
know that this is baloney.  ARIN claims it's charter prevents them from 
using pricing as a tool to effect policy which is why the official
line from them on pricing is what it is, so they have to resort
to some creativity to arrive at a fair pricing.  But, setting that
aside, if you consider the pricing from ALL angles, not just your
own parochial one, you will understand why pricing MUST be more
of a burden for the smaller orgs.

I personally feel that IP pricing could stand to have some tweaks in
it, as the price-per-IP difference between the very largest allocations
and the smallest allocations is to rediculously large, but I certainly
do not think it should be flat across all sizes of allocations, and
I suspect if you think about this and realize that your own router
expenditures for your own router/routers are driven by what everyone 
else on the Internet gets, you will realize the wisdom of the current
approach.

Ted Mittelstaedt
Internet Partners, Inc.



On 4/13/2010 10:31 AM, Randy McAnally wrote:
> Why are extra-small ISP's with a /21 or /22 of v4 space forced to buy so much v6
> IP space and essentially double our fees?  I know there's a rebate in effect
> (for now) but regardless, I'm extremely displeased with this policy.
>
> --
> Randy
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From tedm at ipinc.net  Tue Apr 13 14:02:30 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 13 Apr 2010 11:02:30 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <20100413172714.M35473@fast-serv.com>
References: <20100413172714.M35473@fast-serv.com>
Message-ID: <4BC4B1B6.7060804@ipinc.net>


Randy,

The assumption has always been that if your an extra-small ISP that you 
obtain IP addressing from your LIR  (ie: upstream ISP)

It isn't the amount of numbers that your planning to use that is the
problem.

The problem is that even if you got an extremely small allocation that
as soon as you advertise it, you consume the same amount of routing
resources on everyone else's BGP router on the Internet, that someone
with a larger allocation has who is advertising theirs.  Thus it is not
fair to base pricing solely on the amount of numbering.

Current IPv4 pricing is based both on the amount of numbering and
the principle that we want to make the cost-per-number more expensive
for the smaller ISPs to discourage them from obtaining portable numbers,
and encourage them to use numbers from their upstream, this reduces
growth of the DFZ.  That is why pricing on a per-IP basis gets higher
the smaller the allocations that you have.

Of course, ARIN continually claims that larger allocations require
less maintainence and smaller allocations require more maintainence
and has ginned-up reports purporting to prove this, which is why the 
smaller allocations are more expensive on a per-IP basis, but we all 
know that this is baloney.  ARIN claims it's charter prevents them from 
using pricing as a tool to effect policy which is why the official
line from them on pricing is what it is, so they have to resort
to some creativity to arrive at a fair pricing.  But, setting that
aside, if you consider the pricing from ALL angles, not just your
own parochial one, you will understand why pricing MUST be more
of a burden for the smaller orgs.

I personally feel that IP pricing could stand to have some tweaks in
it, as the price-per-IP difference between the very largest allocations
and the smallest allocations is to rediculously large, but I certainly
do not think it should be flat across all sizes of allocations, and
I suspect if you think about this and realize that your own router
expenditures for your own router/routers are driven by what everyone 
else on the Internet gets, you will realize the wisdom of the current
approach.

Ted Mittelstaedt
Internet Partners, Inc.



On 4/13/2010 10:31 AM, Randy McAnally wrote:
> Why are extra-small ISP's with a /21 or /22 of v4 space forced to buy so much v6
> IP space and essentially double our fees?  I know there's a rebate in effect
> (for now) but regardless, I'm extremely displeased with this policy.
>
> --
> Randy
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From rsm at fast-serv.com  Tue Apr 13 14:25:53 2010
From: rsm at fast-serv.com (Randy McAnally)
Date: Tue, 13 Apr 2010 14:25:53 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <4BC4B1B6.7060804@ipinc.net>
References: <20100413172714.M35473@fast-serv.com> <4BC4B1B6.7060804@ipinc.net>
Message-ID: <20100413181739.M43100@fast-serv.com>

---------- Original Message -----------
From: Ted Mittelstaedt <tedm at ipinc.net>
To: arin-ppml at arin.net
Sent: Tue, 13 Apr 2010 11:02:30 -0700
Subject: Re: [arin-ppml] IPv6 /32 minimum for extra-small ISP

> The assumption has always been that if your an extra-small ISP that 
> you obtain IP addressing from your LIR  (ie: upstream ISP)

ARIN made us give back that IP space to qualify for multihoming policy.  So 
now when we need IP space we have to go direct to ARIN, thus we have a /22 and 
a /21 and still qualify for extra-small pricing.  Try asking your upstream for 
IPs when you already have direct assignments... it's not going to happen.

Furthermore, my gripe IS NOT WITH PRICING PER IP.  

It is the fact that big multi-homed ISP can request a v6 allocation and see no 
increase in fees (they pay only the bigger of the two, obviously their v4 
space), yet a smaller multi-homed ISP requests v6 and doubles their yearly 
fees because a /32 is the minimum.

I thought ARIN was encouraging the adoption of v6 for everyone, not just big 
ISPs.

--
Randy
www.FastServ.com



From rsm at fast-serv.com  Tue Apr 13 14:33:28 2010
From: rsm at fast-serv.com (Randy McAnally)
Date: Tue, 13 Apr 2010 14:33:28 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <20100413181739.M43100@fast-serv.com>
References: <20100413172714.M35473@fast-serv.com> <4BC4B1B6.7060804@ipinc.net>
	<20100413181739.M43100@fast-serv.com>
Message-ID: <20100413183106.M55521@fast-serv.com>

I guess I'm just surprised that it costs twice as much to obtain IPv6 as IPv4 
for _us_.  Obviously this isn't the case for everyone (big ISP with a ton of v4) 
but for us it's a ridiculous policy.

--
Randy



From NOC at ChangeIP.com  Tue Apr 13 15:16:00 2010
From: NOC at ChangeIP.com (NOC at ChangeIP.com)
Date: Tue, 13 Apr 2010 12:16:00 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
References: <20100413172714.M35473@fast-serv.com> <4BC4B1B6.7060804@ipinc.net>
Message-ID: <A153ECC6B3414765B321340BCE7AFC16@changeip.com>

> From: "Ted Mittelstaedt" <tedm at ipinc.net>
>
> The problem is that even if you got an extremely small allocation that
> as soon as you advertise it, you consume the same amount of routing
> resources on everyone else's BGP router on the Internet, that someone
> with a larger allocation has who is advertising theirs.  Thus it is not
> fair to base pricing solely on the amount of numbering.

ARIN sets the pricing based on routing slots?  I thought ARIN was 
disentangled from the routing aspect of it.

Also, why do they even bother listing x-small fees for ISP allocations if 
you can't even get it.

Sam


From rsm at fast-serv.com  Tue Apr 13 15:30:21 2010
From: rsm at fast-serv.com (Randy McAnally)
Date: Tue, 13 Apr 2010 15:30:21 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <A153ECC6B3414765B321340BCE7AFC16@changeip.com>
References: <20100413172714.M35473@fast-serv.com> <4BC4B1B6.7060804@ipinc.net>
	<A153ECC6B3414765B321340BCE7AFC16@changeip.com>
Message-ID: <20100413192513.M42419@fast-serv.com>

Not to mention that certain large ISP's announce large blocks as contiguous 
/24's.

--
Randy

---------- Original Message -----------
From: <NOC at ChangeIP.com>
To: "Ted Mittelstaedt" <tedm at ipinc.net>, <arin-ppml at arin.net>
Sent: Tue, 13 Apr 2010 12:16:00 -0700
Subject: Re: [arin-ppml] IPv6 /32 minimum for extra-small ISP

> > From: "Ted Mittelstaedt" <tedm at ipinc.net>
> >
> > The problem is that even if you got an extremely small allocation that
> > as soon as you advertise it, you consume the same amount of routing
> > resources on everyone else's BGP router on the Internet, that someone
> > with a larger allocation has who is advertising theirs.  Thus it is not
> > fair to base pricing solely on the amount of numbering.
> 
> ARIN sets the pricing based on routing slots?  I thought ARIN was 
> disentangled from the routing aspect of it.
> 
> Also, why do they even bother listing x-small fees for ISP 
> allocations if you can't even get it.
> 
> Sam
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
------- End of Original Message -------



From tedm at ipinc.net  Tue Apr 13 15:34:24 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 13 Apr 2010 12:34:24 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <20100413181739.M43100@fast-serv.com>
References: <20100413172714.M35473@fast-serv.com> <4BC4B1B6.7060804@ipinc.net>
	<20100413181739.M43100@fast-serv.com>
Message-ID: <4BC4C740.9060208@ipinc.net>



On 4/13/2010 11:25 AM, Randy McAnally wrote:
> ---------- Original Message -----------
> From: Ted Mittelstaedt<tedm at ipinc.net>
> To: arin-ppml at arin.net
> Sent: Tue, 13 Apr 2010 11:02:30 -0700
> Subject: Re: [arin-ppml] IPv6 /32 minimum for extra-small ISP
>
>> The assumption has always been that if your an extra-small ISP that
>> you obtain IP addressing from your LIR  (ie: upstream ISP)
>
> ARIN made us give back that IP space to qualify for multihoming policy.

I think your mistaken or your situation had some other issues your
not explaining.  My employer, Internet Partners, ran multihomed
with upstream-assigned IPv4 for close to a decade.  I'm not familiar 
with any requirement to use ARIN-assigned IPv4 in order to multihome,
can you point me to this in the NRPM?

> So
> now when we need IP space we have to go direct to ARIN, thus we have a /22 and
> a /21 and still qualify for extra-small pricing.  Try asking your upstream for
> IPs when you already have direct assignments... it's not going to happen.
>

Why would your upstream withhold IPv6 allocations when you have IPv4 
assignments from ARIN?

I can understand your upstream withholding IPv4 allocations when you
already have IPv4 allocations from ARIN.  But, not IPv6.

> Furthermore, my gripe IS NOT WITH PRICING PER IP.
>
> It is the fact that big multi-homed ISP can request a v6 allocation and see no
> increase in fees (they pay only the bigger of the two, obviously their v4
> space), yet a smaller multi-homed ISP requests v6 and doubles their yearly
> fees because a /32 is the minimum.
>
> I thought ARIN was encouraging the adoption of v6 for everyone, not just big
> ISPs.
>

Yes and no.  Yes ARIN is encouraging adoption of IPv6 for everyone.  No,
ARIN is NOT encouraging everyone in the region to obtain IPv6 FROM THEM.

The idea behind IPv6 assignment is that most orgs should only need to 
request a single IPv6 allocation then never have to go back for more.
This is radically different than assignments for IPv4 where the goal is
to miser-out the IPv4 in dribs and drabs.  It is a much better system
because when the IPv4 is handed out in little bits it inflates the DFZ -
do you not realize for example that your advertisement of a separate /22
and /21 costs ME and everyone else MORE router ram than if you had 
returned your /22 and /21 and renumbered into a /20?  Thus, the IPv6
assignments are ENORMOUS if your just comparing IP number to IP number
from IPv4 to IPv6.  There really IS NO coorespondence between an "extra
small IPv4" allocation and an "extra small IPv6 allocation" because
such a thing (extra-small IPv6 allocation) does not exist.

The fact is that because of this approach, the "extra small" ISPs are
going to be in this situation that your in.  One of these days IPv4
is going to be worthless and then your going to have to either decide
to pay more money and get your own IPv6 from ARIN or pay your upstream
for an assignment out of it's IPv6.  But you have to keep in mind that
since your upstream will have a vast amount of IPv6, that they should
have no problems with giving you as much as you want, and further that
renumbering under IPv6 is much easier than under IPv4.

Now, granted, your upstream may not be running IPv6 at this time.  Well
to put it bluntly, it helps the IPv6 deployment more if you go to your
upstream and crawl up their butt until they get IPv6, than if you just
ignore them and get IPv6 for your corner of the Internet.

I've seen posts from orgs where the network guys were ready and wanted
to deploy IPv6 and the pointy-haired bosses didn't, because the
pointy-haired bosses never talked to a customer who asked about it,
thus assumed that it's not important.  If your a customer of such an
upstream, you might consider bothering the pointy haired bosses who
you are paying good money to for connectivity.

In summary I'm sure I'm not telling you anything you want to hear
but just try to keep the big picture in mind.  If we can't get those
large orgs to deploy IPv6 then there's no point in you and I bothering
with it, now is there?

Ted

> --
> Randy
> www.FastServ.com
>


From owen at delong.com  Tue Apr 13 23:51:08 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 13 Apr 2010 20:51:08 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <20100413172714.M35473@fast-serv.com>
References: <20100413172714.M35473@fast-serv.com>
Message-ID: <E4F0F49E-F599-4DC4-9711-DA34FED9FBED@delong.com>

You are welcome to submit a policy proposal to change that.

Owen

On Apr 13, 2010, at 10:31 AM, Randy McAnally wrote:

> Why are extra-small ISP's with a /21 or /22 of v4 space forced to buy so much v6 
> IP space and essentially double our fees?  I know there's a rebate in effect 
> (for now) but regardless, I'm extremely displeased with this policy.
> 
> --
> Randy
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From mysidia at gmail.com  Wed Apr 14 00:04:01 2010
From: mysidia at gmail.com (James Hess)
Date: Tue, 13 Apr 2010 23:04:01 -0500
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <A153ECC6B3414765B321340BCE7AFC16@changeip.com>
References: <20100413172714.M35473@fast-serv.com> <4BC4B1B6.7060804@ipinc.net>
	<A153ECC6B3414765B321340BCE7AFC16@changeip.com>
Message-ID: <r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com>

On Tue, Apr 13, 2010 at 2:16 PM,  <NOC at changeip.com> wrote:
>> The problem is that even if you got an extremely small allocation that
>> as soon as you advertise it, you consume the same amount of routing
>> resources on everyone else's BGP router on the Internet, that someone
>> with a larger allocation has who is advertising theirs. ?Thus it is not
>> fair to base pricing solely on the amount of numbering.
> ARIN sets the pricing based on routing slots? ?I thought ARIN was
> disentangled from the routing aspect of it.

ARIN does not guarantee routability of assignments. And ARIN does not
determine overall internet routing policy.  However, that does not
mean ARIN is  not entangled at all with routing aspects of IP
addressing or internet routing policy.    To  ignore routing, internet
stability considerations, and overall cost to the community, in making
address allocation decisions,  would be poor stewardship of the
resource.

It is not beneficial at all to minimize the cost of individual IP
addresses in a manner that  maximizes  overall costs for the greater
community requiring those addresses, of which addressing is just one
cost.



--
-J


From owen at delong.com  Wed Apr 14 00:20:42 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 13 Apr 2010 21:20:42 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <A153ECC6B3414765B321340BCE7AFC16@changeip.com>
References: <20100413172714.M35473@fast-serv.com> <4BC4B1B6.7060804@ipinc.net>
	<A153ECC6B3414765B321340BCE7AFC16@changeip.com>
Message-ID: <611D1C57-AD11-46AB-BC36-B78B7BB03191@delong.com>


On Apr 13, 2010, at 12:16 PM, <NOC at ChangeIP.com> <NOC at ChangeIP.com> wrote:

>> From: "Ted Mittelstaedt" <tedm at ipinc.net>
>> 
>> The problem is that even if you got an extremely small allocation that
>> as soon as you advertise it, you consume the same amount of routing
>> resources on everyone else's BGP router on the Internet, that someone
>> with a larger allocation has who is advertising theirs.  Thus it is not
>> fair to base pricing solely on the amount of numbering.
> 
> ARIN sets the pricing based on routing slots?  I thought ARIN was disentangled from the routing aspect of it.
> 
You are correct.  Ted is mistaken.

> Also, why do they even bother listing x-small fees for ISP allocations if you can't even get it.
> 
A very good question.  Perhaps so that there is a fee structure available in case of a policy change.

Owen



From jpalmer at american-webmasters.net  Wed Apr 14 02:27:55 2010
From: jpalmer at american-webmasters.net (John Palmer)
Date: Wed, 14 Apr 2010 01:27:55 -0500
Subject: [arin-ppml] ARIN Policy Clarification: Micro-Allocations
Message-ID: <AD990F00C9E042498CCFCEC16E02B53A@TAKA>

In the "ARIN Number Resource Policy Manual" is the following section on micro allocations
"4.4. Micro-allocation
ARIN will make micro-allocations to critical infrastructure providers of the Internet, including public exchange points, core DNS 
service providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs and IANA. These allocations will be no 
longer than a /24 using IPv4 or a /48 using IPv6. Multiple allocations may be granted in certain situations. - Exchange point 
allocations MUST be allocated from specific blocks reserved only for this purpose. All other micro-allocations WILL be allocated out 
of other blocks reserved for micro-allocation purposes. ARIN will make a list of these blocks publicly available. - Exchange point 
operators must provide justification for the allocation, including: connection policy, location, other participants (minimum of two 
total), ASN, and contact information. ISPs and other organizations receiving these micro-allocations will be charged under the ISP 
fee schedule, while end-users will be charged under the fee schedule for end-users. This policy does not preclude exchange point 
operators from requesting address space under other policies."

The part the concerns me is that part that says "e.g. ICANN-sanctioned root, gTLD and ccTLD operators".

Excuse me, but since when do DNS operators have to be ICANN sanctioned? You know that there is such a thing called the Inclusive 
Namespace. ICANN is not the only authorized root network operator.

ARIN is supposed to support the whole community, not just the DNS services sanctioned by ICANN.

I would like to propose to the ARIN board that the phrase "(e.g. ICANN-sanctioned root, gTLD and ccTLD operators)" be replaced with 
"(root, gTLD and ccTLD operators)".

My company manages and operates the WorldRoot, an Inclusive Namespace root network and would like to have 13 micro-allocations for 
Anycast operations of our 13 DNS server sets around the world as well as IP6 microallocations in the near future.  As it stands, we 
will probably be able to populate 3 to 4 complete cloneSets (13 servers each) in the next 3 to 5 years. The language in Section 4.4 
of the NRPM seems to exclude our ability to obtain the neccesary number resources and is discriminatory to the Inclusive Namespace 
and therefore in violation of ARIN's mission to serve the ENTIRE North American community.

ARIN Board - please take note of my request and respond.

Thanks
John Palmer - President
American Webmasters Inc
(operator of the WorldRoot root server network - http://worldroot.net)



From aaron at wholesaleinternet.net  Wed Apr 14 14:00:20 2010
From: aaron at wholesaleinternet.net (Aaron Wendel)
Date: Wed, 14 Apr 2010 13:00:20 -0500
Subject: [arin-ppml] ARIN Policy Clarification: Micro-Allocations
In-Reply-To: <AD990F00C9E042498CCFCEC16E02B53A@TAKA>
References: <AD990F00C9E042498CCFCEC16E02B53A@TAKA>
Message-ID: <007001cadbfc$59235610$0b6a0230$@net>

You can definitely write a policy proposal that changes the language of the
current text to provide for more "openness".



-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of John Palmer
Sent: Wednesday, April 14, 2010 1:28 AM
To: arin-ppml at arin.net
Subject: [arin-ppml] ARIN Policy Clarification: Micro-Allocations

In the "ARIN Number Resource Policy Manual" is the following section on
micro allocations
"4.4. Micro-allocation
ARIN will make micro-allocations to critical infrastructure providers of the
Internet, including public exchange points, core DNS 
service providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) as
well as the RIRs and IANA. These allocations will be no 
longer than a /24 using IPv4 or a /48 using IPv6. Multiple allocations may
be granted in certain situations. - Exchange point 
allocations MUST be allocated from specific blocks reserved only for this
purpose. All other micro-allocations WILL be allocated out 
of other blocks reserved for micro-allocation purposes. ARIN will make a
list of these blocks publicly available. - Exchange point 
operators must provide justification for the allocation, including:
connection policy, location, other participants (minimum of two 
total), ASN, and contact information. ISPs and other organizations receiving
these micro-allocations will be charged under the ISP 
fee schedule, while end-users will be charged under the fee schedule for
end-users. This policy does not preclude exchange point 
operators from requesting address space under other policies."

The part the concerns me is that part that says "e.g. ICANN-sanctioned root,
gTLD and ccTLD operators".

Excuse me, but since when do DNS operators have to be ICANN sanctioned? You
know that there is such a thing called the Inclusive 
Namespace. ICANN is not the only authorized root network operator.

ARIN is supposed to support the whole community, not just the DNS services
sanctioned by ICANN.

I would like to propose to the ARIN board that the phrase "(e.g.
ICANN-sanctioned root, gTLD and ccTLD operators)" be replaced with 
"(root, gTLD and ccTLD operators)".

My company manages and operates the WorldRoot, an Inclusive Namespace root
network and would like to have 13 micro-allocations for 
Anycast operations of our 13 DNS server sets around the world as well as IP6
microallocations in the near future.  As it stands, we 
will probably be able to populate 3 to 4 complete cloneSets (13 servers
each) in the next 3 to 5 years. The language in Section 4.4 
of the NRPM seems to exclude our ability to obtain the neccesary number
resources and is discriminatory to the Inclusive Namespace 
and therefore in violation of ARIN's mission to serve the ENTIRE North
American community.

ARIN Board - please take note of my request and respond.

Thanks
John Palmer - President
American Webmasters Inc
(operator of the WorldRoot root server network - http://worldroot.net)

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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 9.0.801 / Virus Database: 271.1.1/2796 - Release Date: 04/13/10
15:22:00



From christopher.morrow at gmail.com  Wed Apr 14 15:09:39 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Wed, 14 Apr 2010 15:09:39 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <28E139F46D45AF49A31950F88C49745805AF0623@E03MVZ2-UKDY.domain1.systemhost.net>
References: <k2m75cb24521004052327ne0e957b2w4ecf79f67a1bd1e2@mail.gmail.com>
	<28E139F46D45AF49A31950F88C49745805AF0623@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <y2q75cb24521004141209yffa1781ia375460170351d4a@mail.gmail.com>

On Tue, Apr 6, 2010 at 4:49 AM,  <michael.dillon at bt.com> wrote:
>
>> because I have 2 locations, one in NYC one in SFO. Running a
>> private network link between them is more expensive than 2
>> commodity internet links, I can't (today) expect longer than
>> a /48 to pass through inter-AS boundaries... so I need (now)
>> a /47.
>
> Why would you want to run a national network when you have
> only two locations?

I don't, I want to multi-home both of my sites... I have a regulatory
reason to want better assurance that my sites are up and reachable.

>
>> Look at Allstate Insurance that had, at last count +10k
>> remote sites... a /48 is a single SITE, not a single ORGANIZATION.
>
> Why would an insurance company want to run a national network?

they don't, they want to use commodity network services in region,
they also want (potentially) to multihome some portions of these
mythical 10k sites.

>> Note that none of the above colors the discussion about NAT
>> nor internal numbering schemes related to ULA*, I was simply
>> pointing out that it's entirely inaccurate to believe that
>> 'Few Organizations will need more than a single /48'.
>
> Those of us who believe that few organizations will need more
> than a single /48 expect that most organizations will stick
> to their knitting and buy network services from an ISP. In other
> words the ones that need more than a single /48 will not be
> interested in talking to ARIN.

huh? if you need more than a single PA /48 you'll have to talk to some
RIR, won't you?
(maybe I misread the above paragraph)

-Chris


From heather.skanks at gmail.com  Wed Apr 14 15:24:30 2010
From: heather.skanks at gmail.com (heather skanks)
Date: Wed, 14 Apr 2010 15:24:30 -0400
Subject: [arin-ppml] ARIN Policy Clarification: Micro-Allocations
In-Reply-To: <AD990F00C9E042498CCFCEC16E02B53A@TAKA>
References: <AD990F00C9E042498CCFCEC16E02B53A@TAKA>
Message-ID: <q2t616812071004141224x49c9004ah4323f257f1c97781@mail.gmail.com>

On Wed, Apr 14, 2010 at 2:27 AM, John Palmer
<jpalmer at american-webmasters.net> wrote:
<snip>
>
> I would like to propose to the ARIN board that the phrase "(e.g.
> ICANN-sanctioned root, gTLD and ccTLD operators)" be replaced with "(root,
> gTLD and ccTLD operators)".
>
<snip>

> ARIN Board - please take note of my request and respond.

I'm not ARIN board - but as an ARIN Advisory Council member, I'll say,
the policy proposal process is open to everyone - knock yourself out:

Policy Proposal Template:
https://www.arin.net/policy/pdp_appendix_b.html

Policy Proposal Process:
https://www.arin.net/policy/pdp.html



>
> Thanks
> John Palmer - President
> American Webmasters Inc
> (operator of the WorldRoot root server network - http://worldroot.net)
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>


From tedm at ipinc.net  Wed Apr 14 15:50:47 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 14 Apr 2010 12:50:47 -0700
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <y2q75cb24521004141209yffa1781ia375460170351d4a@mail.gmail.com>
References: <k2m75cb24521004052327ne0e957b2w4ecf79f67a1bd1e2@mail.gmail.com>	<28E139F46D45AF49A31950F88C49745805AF0623@E03MVZ2-UKDY.domain1.systemhost.net>
	<y2q75cb24521004141209yffa1781ia375460170351d4a@mail.gmail.com>
Message-ID: <4BC61C97.4090702@ipinc.net>



On 4/14/2010 12:09 PM, Christopher Morrow wrote:
> On Tue, Apr 6, 2010 at 4:49 AM,<michael.dillon at bt.com>  wrote:
>>
>>> because I have 2 locations, one in NYC one in SFO. Running a
>>> private network link between them is more expensive than 2
>>> commodity internet links, I can't (today) expect longer than
>>> a /48 to pass through inter-AS boundaries... so I need (now)
>>> a /47.
>>
>> Why would you want to run a national network when you have
>> only two locations?
>
> I don't, I want to multi-home both of my sites... I have a regulatory
> reason to want better assurance that my sites are up and reachable.
>

If this is true, that you really want to speak IPv6 over BGP to
multiple providers are each of those locations, then your going to be
laying out at LEAST $1500 per month per location, for the SMALLEST
amount of bandwidth.  At least, that is my experience with sites in
the US.

This kind of network simply does not match the hypothetical
Allstate Insurance remote sites.  I've BEEN in at least one of
those Allstate sites and I didn't see any 2 T1's coming into a router. 
DSL, Cable, yeah.  But not real live BGP-capable circuits.

>>
>>> Look at Allstate Insurance that had, at last count +10k
>>> remote sites... a /48 is a single SITE, not a single ORGANIZATION.
>>
>> Why would an insurance company want to run a national network?
>
> they don't, they want to use commodity network services in region,
> they also want (potentially) to multihome some portions of these
> mythical 10k sites.
>

Good luck.  As the famous quote in Gone With The Wind went,

"askin ain't gettin"

Ted


From mueller at syr.edu  Wed Apr 14 15:58:30 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 14 Apr 2010 15:58:30 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com>
References: <20100413172714.M35473@fast-serv.com>
	<4BC4B1B6.7060804@ipinc.net>	<A153ECC6B3414765B321340BCE7AFC16@changeip.com>
	<r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>

> -----Original Message-----
> The problem is that even if you got an extremely small allocation
> that as soon as you advertise it, you consume the same amount of 
> routing resources on everyone else's BGP router on the Internet, 
> that someone with a larger allocation has who is advertising theirs. 
>?Thus it is not fair to base pricing solely on the amount of numbering.

Just curious. Has this assertion ever been tested, examined, modeled?
There are two logical components to this statement that I am interested in verifying: 
A small allocation: 
a) "consumes the same amount of resources" 
b) on "everyone else's" BGP router

The latter is an especially strong claim.  

Milton Mueller
Professor, Syracuse University School of Information Studies
XS4All Professor, Delft University of Technology
------------------------------
Internet Governance Project:
http://internetgovernance.org



From sethm at rollernet.us  Wed Apr 14 16:00:26 2010
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 14 Apr 2010 13:00:26 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <20100413172714.M35473@fast-serv.com>
References: <20100413172714.M35473@fast-serv.com>
Message-ID: <4BC61EDA.7060005@rollernet.us>

On 4/13/2010 10:31, Randy McAnally wrote:
> Why are extra-small ISP's with a /21 or /22 of v4 space forced to buy so much v6 
> IP space and essentially double our fees?  I know there's a rebate in effect 
> (for now) but regardless, I'm extremely displeased with this policy.
> 

Keep in mind that there are still entities out there (like AS701) who
will not accept anything smaller than a /32 into their routing tables,
so for better or for worse, a /32 is the currently the best option for
maximum visibility.

~Seth


From mueller at syr.edu  Wed Apr 14 16:08:57 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 14 Apr 2010 16:08:57 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>
References: <20100413172714.M35473@fast-serv.com><4BC4B1B6.7060804@ipinc.net>
	<A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>
Message-ID: <75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>



> -----Original Message-----
> From: Bill Woodcock [mailto:woody at pch.net]
> 
> The router doesn't care how important you think a route is, or how much
> you like it, or how many IP addresses or users sit behind it. It's
> still a route, and the amount of memory it consumes is still just
> dependent upon its associated path and options.

"everyone else's router." 

So when a small ISP in Madagascar advertises a new route, resources are consumed here at my router here at Syracuse University? Please confirm this? 

--MM


From rsm at fast-serv.com  Wed Apr 14 16:09:12 2010
From: rsm at fast-serv.com (Randy McAnally)
Date: Wed, 14 Apr 2010 16:09:12 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <4BC61EDA.7060005@rollernet.us>
References: <20100413172714.M35473@fast-serv.com>
	<4BC61EDA.7060005@rollernet.us>
Message-ID: <20100414200154.M8857@fast-serv.com>

Thanks for the feedback.

I think my original question should be rephrased.. not to reduce the minimum
allocation size, but to modify pricing for ISP who obtain v4 space under the
existing v4 multi-homing policy and are currently in the 'extra-small' fee
schedule.

I don't feel it is a fair policy to bump us into 'small' fee schedule just to
obtain v6 as an ISP currently under the 'extra-small' v4 fee schedule -- at
least until we have utilized enough v4 to qualify as 'small'.

What do you guys think?

--
Randy

---------- Original Message -----------
From: Seth Mattinen <sethm at rollernet.us>
To: arin-ppml at arin.net
Sent: Wed, 14 Apr 2010 13:00:26 -0700
Subject: Re: [arin-ppml] IPv6 /32 minimum for extra-small ISP

> On 4/13/2010 10:31, Randy McAnally wrote:
> > Why are extra-small ISP's with a /21 or /22 of v4 space forced to buy so
much v6 
> > IP space and essentially double our fees?  I know there's a rebate in effect 
> > (for now) but regardless, I'm extremely displeased with this policy.
> >
> 
> Keep in mind that there are still entities out there (like AS701) who
> will not accept anything smaller than a /32 into their routing 
> tables, so for better or for worse, a /32 is the currently the best 
> option for maximum visibility.
> 
> ~Seth
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
------- End of Original Message -------



From tedm at ipinc.net  Wed Apr 14 16:13:05 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 14 Apr 2010 13:13:05 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
References: <20100413172714.M35473@fast-serv.com>	<4BC4B1B6.7060804@ipinc.net>	<A153ECC6B3414765B321340BCE7AFC16@changeip.com>	<r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4BC621D1.8020800@ipinc.net>



On 4/14/2010 12:58 PM, Milton L Mueller wrote:
>> -----Original Message-----
>> The problem is that even if you got an extremely small allocation
>> that as soon as you advertise it, you consume the same amount of
>> routing resources on everyone else's BGP router on the Internet,
>> that someone with a larger allocation has who is advertising theirs.
>>   Thus it is not fair to base pricing solely on the amount of numbering.
>
> Just curious. Has this assertion ever been tested, examined, modeled?
> There are two logical components to this statement that I am interested in verifying:
> A small allocation:
> a) "consumes the same amount of resources"
> b) on "everyone else's" BGP router
>
> The latter is an especially strong claim.
>

There are these things called "looking glasses" you can find them
at traceroute.org and when you log in to them you will see that
BGP propagation is pretty much world-wide.  It's a pretty amazing
thing, this Internet network.

<eyeroll>

Ted


From woody at pch.net  Wed Apr 14 16:04:37 2010
From: woody at pch.net (Bill Woodcock)
Date: Wed, 14 Apr 2010 20:04:37 +0000
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
References: <20100413172714.M35473@fast-serv.com><4BC4B1B6.7060804@ipinc.net>	<A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>

Yes, Milton.  You're being presented with facts about how routers operate, not a speculative framework to challenge. 

The router doesn't care how important you think a route is, or how much you like it, or how many IP addresses or users sit behind it. It's still a route, and the amount of memory it consumes is still just dependent upon its associated path and options. 



Sent via BlackBerry by AT&T

-----Original Message-----
From: Milton L Mueller <mueller at syr.edu>
Date: Wed, 14 Apr 2010 15:58:30 
To: 'James Hess'<mysidia at gmail.com>; NOC at changeip.com<NOC at changeip.com>
Cc: arin-ppml at arin.net<arin-ppml at arin.net>
Subject: Re: [arin-ppml] IPv6 /32 minimum for extra-small ISP

> -----Original Message-----
> The problem is that even if you got an extremely small allocation
> that as soon as you advertise it, you consume the same amount of
> routing resources on everyone else's BGP router on the Internet,
> that someone with a larger allocation has who is advertising theirs.
>?Thus it is not fair to base pricing solely on the amount of numbering.

Just curious. Has this assertion ever been tested, examined, modeled?
There are two logical components to this statement that I am interested in verifying:
A small allocation:
a) "consumes the same amount of resources"
b) on "everyone else's" BGP router

The latter is an especially strong claim.

Milton Mueller
Professor, Syracuse University School of Information Studies
XS4All Professor, Delft University of Technology
------------------------------
Internet Governance Project:
http://internetgovernance.org

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


From mksmith at adhost.com  Wed Apr 14 16:15:56 2010
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Wed, 14 Apr 2010 13:15:56 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
References: <20100413172714.M35473@fast-serv.com><4BC4B1B6.7060804@ipinc.net>	<A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <17838240D9A5544AAA5FF95F8D52031607EE0E93@ad-exh01.adhost.lan>

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Milton L Mueller
> Sent: Wednesday, April 14, 2010 12:59 PM
> To: 'James Hess'; NOC at changeip.com
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] IPv6 /32 minimum for extra-small ISP
> 
> > -----Original Message-----
> > The problem is that even if you got an extremely small allocation
> > that as soon as you advertise it, you consume the same amount of
> > routing resources on everyone else's BGP router on the Internet,
> > that someone with a larger allocation has who is advertising theirs.
> >?Thus it is not fair to base pricing solely on the amount of
> numbering.
> 
> Just curious. Has this assertion ever been tested, examined, modeled?
> There are two logical components to this statement that I am interested
> in verifying:
> A small allocation:
> a) "consumes the same amount of resources"

Within limits.  Every route requires a single slot in your FIB that consumes more or less the same resources.

> b) on "everyone else's" BGP router

If you are speaking BGP and accepting the full DFZ routing table then this is also true.  If you are filtering based upon some local policy then YMMV.

The differences are more pedantic than technical.  I think the original assertion stands.

Mike



From dsd at carpathiahost.com  Wed Apr 14 16:12:48 2010
From: dsd at carpathiahost.com (David Divins)
Date: Wed, 14 Apr 2010 16:12:48 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>
References: <20100413172714.M35473@fast-serv.com><4BC4B1B6.7060804@ipinc.net>
	<A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <46D17940F4B3C84AB02E7D5BFC0588CC077CAFC5@EX2K7VS04.4emm.local>

If you are taking full tables and the route is not filtered along the way, yes, you should have a new route in BGP on your router.

-dsd

David S. Divins
Principal Engineer
Carpathia Hosting, Inc.
43480 Yukon Dr., #200
Ashburn, VA ?20147
(703) 652-5955
www.carpathiahost.com

ServerVault is now Carpathia Hosting!
www.carpathiahosting.com<www.carpathiahosting.com>?

This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller
Sent: Wednesday, April 14, 2010 4:09 PM
To: 'woody at pch.net'; arin-ppml-bounces at arin.net; 'James Hess'; NOC at changeip.com
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] IPv6 /32 minimum for extra-small ISP



> -----Original Message-----
> From: Bill Woodcock [mailto:woody at pch.net]
> 
> The router doesn't care how important you think a route is, or how much
> you like it, or how many IP addresses or users sit behind it. It's
> still a route, and the amount of memory it consumes is still just
> dependent upon its associated path and options.

"everyone else's router." 

So when a small ISP in Madagascar advertises a new route, resources are consumed here at my router here at Syracuse University? Please confirm this? 

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


From sethm at rollernet.us  Wed Apr 14 16:19:30 2010
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 14 Apr 2010 13:19:30 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>
References: <20100413172714.M35473@fast-serv.com><4BC4B1B6.7060804@ipinc.net>	<A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4BC62352.2090202@rollernet.us>

On 4/14/2010 13:08, Milton L Mueller wrote:
> 
> 
>> -----Original Message-----
>> From: Bill Woodcock [mailto:woody at pch.net]
>>
>> The router doesn't care how important you think a route is, or how much
>> you like it, or how many IP addresses or users sit behind it. It's
>> still a route, and the amount of memory it consumes is still just
>> dependent upon its associated path and options.
> 
> "everyone else's router." 
> 
> So when a small ISP in Madagascar advertises a new route, resources are consumed here at my router here at Syracuse University? Please confirm this? 
> 


If you take a full unfiltered table without a default route, yes. This
is pretty basic for BGP.

~Seth


From joelja at bogus.com  Wed Apr 14 16:18:51 2010
From: joelja at bogus.com (joel jaeggli)
Date: Wed, 14 Apr 2010 13:18:51 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>
References: <20100413172714.M35473@fast-serv.com><4BC4B1B6.7060804@ipinc.net>	<A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4BC6232B.2060303@bogus.com>

On 4/14/2010 1:08 PM, Milton L Mueller wrote:
>
>
>> -----Original Message----- From: Bill Woodcock
>> [mailto:woody at pch.net]
>>
>> The router doesn't care how important you think a route is, or how
>> much you like it, or how many IP addresses or users sit behind it.
>> It's still a route, and the amount of memory it consumes is still
>> just dependent upon its associated path and options.
>
> "everyone else's router."
>
> So when a small ISP in Madagascar advertises a new route, resources
> are consumed here at my router here at Syracuse University? Please
> confirm this?

today my internet vrf has 338343 active routes in it, how many does 
your's have? if it's 1, we're having the wrong discussion.


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



From Donald.Smith at qwest.com  Wed Apr 14 16:19:34 2010
From: Donald.Smith at qwest.com (Smith, Donald)
Date: Wed, 14 Apr 2010 14:19:34 -0600
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>
References: <20100413172714.M35473@fast-serv.com><4BC4B1B6.7060804@ipinc.net>
	<A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <B01905DA0C7CDC478F42870679DF0F1007A3E98C10@qtdenexmbm24.AD.QINTRA.COM>



(coffee != sleep) & (!coffee == sleep)
Donald.Smith at qwest.com gcia

> -----Original Message-----
> From: arin-ppml-bounces at arin.net
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller
> Sent: Wednesday, April 14, 2010 2:09 PM
> To: 'woody at pch.net'; arin-ppml-bounces at arin.net; 'James
> Hess'; NOC at changeip.com
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] IPv6 /32 minimum for extra-small ISP
>
>
>
> > -----Original Message-----
> > From: Bill Woodcock [mailto:woody at pch.net]
> >
> > The router doesn't care how important you think a route is,
> or how much
> > you like it, or how many IP addresses or users sit behind it. It's
> > still a route, and the amount of memory it consumes is still just
> > dependent upon its associated path and options.
>
> "everyone else's router."
Only if you hold all routes.
But unless you hold all routes your not likely to care about rib/fib exaustion:)

>
> So when a small ISP in Madagascar advertises a new route,
> resources are consumed here at my router here at Syracuse
> University? Please confirm this?
>
> --MM
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.


From tme at multicasttech.com  Wed Apr 14 16:26:28 2010
From: tme at multicasttech.com (Marshall Eubanks)
Date: Wed, 14 Apr 2010 16:26:28 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>
References: <20100413172714.M35473@fast-serv.com><4BC4B1B6.7060804@ipinc.net>
	<A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <743F8789-B488-4208-BD9E-578323C801E8@multicasttech.com>


On Apr 14, 2010, at 4:08 PM, Milton L Mueller wrote:

>
>
>> -----Original Message-----
>> From: Bill Woodcock [mailto:woody at pch.net]
>>
>> The router doesn't care how important you think a route is, or how  
>> much
>> you like it, or how many IP addresses or users sit behind it. It's
>> still a route, and the amount of memory it consumes is still just
>> dependent upon its associated path and options.
>
> "everyone else's router."
>
> So when a small ISP in Madagascar advertises a new route, resources  
> are consumed here at my router here at Syracuse University? Please  
> confirm this?

Yes, if you are running BGP, unless their routes are aggregated.

Now, I don't see any routes from  Madagascar just now,
but I do see some from (to pick somewhere at random far from the East  
Coast) Cambodia, including this AS :

ASN  24441         CITYLINK-AS-KH                  [MG213- 
AP]           {Cambodia, KH}                CityLink, Routing AS -  
Service Provider, Phnom Penh, KH

24441 has 202.84.72.0/21, and

show ip bgp 202.84.72.0
BGP routing table entry for 202.84.72.0/21, version 99023878
Paths: (1 available, best #1, table Default-IP-Routing-Table)
   Not advertised to any peer
   174 3491 18403 24441 24441 24441
     38.101.161.116 from 38.101.161.116 (66.28.1.192)
       Origin IGP, metric 3992, localpref 100, valid, external, best
       Community: 11424264 11425277

So, yes, they are in my table, consuming some small amount of flash  
memory. If you're running BGP, you should see them too.

It all adds up.

Regards
Marshall

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



From michael.dillon at bt.com  Wed Apr 14 16:51:13 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 14 Apr 2010 21:51:13 +0100
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <4BC621D1.8020800@ipinc.net>
Message-ID: <28E139F46D45AF49A31950F88C49745805C3F7F3@E03MVZ2-UKDY.domain1.systemhost.net>


> There are these things called "looking glasses" you can find 
> them at traceroute.org and when you log in to them you will 
> see that BGP propagation is pretty much world-wide.  It's a 
> pretty amazing thing, this Internet network.

Oh yeah? And where might one find these "looking glass" thingies?

And don't try to fob off a bunch of URLs listing Looking Glass
sites where 90% of the sites listed were shut down years ago.

I really would like to know if someone is keeping an up
to date and maintained list of open looking glass sites.

--Michael Dillon


From mueller at syr.edu  Wed Apr 14 16:52:59 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 14 Apr 2010 16:52:59 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <4BC62352.2090202@rollernet.us>
References: <20100413172714.M35473@fast-serv.com><4BC4B1B6.7060804@ipinc.net>
	<A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>
	<4BC62352.2090202@rollernet.us>
Message-ID: <75822E125BCB994F8446858C4B19F0D701D5FCA511@SUEX07-MBX-04.ad.syr.edu>

> If you take a full unfiltered table without a default route, yes. This
> is pretty basic for BGP.
> 

I understand that. The issue is how many take a full table. 

Milton Mueller
Professor, Syracuse University School of Information Studies
XS4All Professor, Delft University of Technology
------------------------------
Internet Governance Project:
http://internetgovernance.org



From marty at akamai.com  Wed Apr 14 16:54:34 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Wed, 14 Apr 2010 16:54:34 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <28E139F46D45AF49A31950F88C49745805C3F7F3@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <C7EBA3CA.2C76B%marty@akamai.com>



> From: <michael.dillon at bt.com>
> Date: Wed, 14 Apr 2010 21:51:13 +0100
> To: <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] IPv6 /32 minimum for extra-small ISP
> 
> 
>> There are these things called "looking glasses" you can find
>> them at traceroute.org and when you log in to them you will
>> see that BGP propagation is pretty much world-wide.  It's a
>> pretty amazing thing, this Internet network.
> 
> Oh yeah? And where might one find these "looking glass" thingies?


    http://www.lookingglass.level3.net


> 
> And don't try to fob off a bunch of URLs listing Looking Glass
> sites where 90% of the sites listed were shut down years ago.
> 
> I really would like to know if someone is keeping an up
> to date and maintained list of open looking glass sites.
> 

Try your favorite search engine.

-M<




From Donald.Smith at qwest.com  Wed Apr 14 16:56:12 2010
From: Donald.Smith at qwest.com (Smith, Donald)
Date: Wed, 14 Apr 2010 14:56:12 -0600
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <28E139F46D45AF49A31950F88C49745805C3F7F3@E03MVZ2-UKDY.domain1.systemhost.net>
References: <4BC621D1.8020800@ipinc.net>
	<28E139F46D45AF49A31950F88C49745805C3F7F3@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <B01905DA0C7CDC478F42870679DF0F1007A3E98C3A@qtdenexmbm24.AD.QINTRA.COM>

Not perfect but traceroute.org is pretty well maintained.


(coffee != sleep) & (!coffee == sleep)
Donald.Smith at qwest.com gcia

> -----Original Message-----
> From: arin-ppml-bounces at arin.net
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com
> Sent: Wednesday, April 14, 2010 2:51 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] IPv6 /32 minimum for extra-small ISP
>
>
> > There are these things called "looking glasses" you can find
> > them at traceroute.org and when you log in to them you will
> > see that BGP propagation is pretty much world-wide.  It's a
> > pretty amazing thing, this Internet network.
>
> Oh yeah? And where might one find these "looking glass" thingies?
>
> And don't try to fob off a bunch of URLs listing Looking Glass
> sites where 90% of the sites listed were shut down years ago.
>
> I really would like to know if someone is keeping an up
> to date and maintained list of open looking glass sites.
>
> --Michael Dillon
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.


From steve at ibctech.ca  Wed Apr 14 16:56:43 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Wed, 14 Apr 2010 16:56:43 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <28E139F46D45AF49A31950F88C49745805C3F7F3@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745805C3F7F3@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4BC62C0B.50904@ibctech.ca>

On 2010.04.14 16:51, michael.dillon at bt.com wrote:
> 
>> There are these things called "looking glasses" you can find 
>> them at traceroute.org and when you log in to them you will 
>> see that BGP propagation is pretty much world-wide.  It's a 
>> pretty amazing thing, this Internet network.
> 
> Oh yeah? And where might one find these "looking glass" thingies?

Do these count?:

acct-dev: ISP % telnet route-views.routeviews.org
Trying 2001:468:d01:33::80df:3367...
Connected to route-views.routeviews.org.
Escape character is '^]'.

or, for v6:

http://www.sixxs.net/tools/grh/lg/

Steve


From tedm at ipinc.net  Wed Apr 14 16:58:10 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 14 Apr 2010 13:58:10 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <28E139F46D45AF49A31950F88C49745805C3F7F3@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745805C3F7F3@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4BC62C62.6060608@ipinc.net>



On 4/14/2010 1:51 PM, michael.dillon at bt.com wrote:
>
>> There are these things called "looking glasses" you can find
>> them at traceroute.org and when you log in to them you will
>> see that BGP propagation is pretty much world-wide.  It's a
>> pretty amazing thing, this Internet network.
>
> Oh yeah? And where might one find these "looking glass" thingies?
>
> And don't try to fob off a bunch of URLs listing Looking Glass
> sites where 90% of the sites listed were shut down years ago.
>

Now now, it's probably only about 60% of them that were shut
down years ago.

> I really would like to know if someone is keeping an up
> to date and maintained list of open looking glass sites.
>

So would I!

Ted


From mueller at syr.edu  Wed Apr 14 16:58:54 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 14 Apr 2010 16:58:54 -0400
Subject: [arin-ppml] FW:  IPv6 /32 minimum for extra-small ISP
Message-ID: <75822E125BCB994F8446858C4B19F0D701D5FCA512@SUEX07-MBX-04.ad.syr.edu>


> 
> If you are taking full tables and the route is not filtered along the
> way, yes, you should have a new route in BGP on your router.
> 

A couple of important "ifs". Thanks.

How many organizational routers on the Internet don't "take full tables?" 

As usual, things which are bandied about as "facts" have nuances that are quite consequential if you are trying to understand the real economics and interdependencies. 

Milton Mueller
Professor, Syracuse University School of Information Studies
XS4All Professor, Delft University of Technology
------------------------------
Internet Governance Project:
http://internetgovernance.org



From mueller at syr.edu  Wed Apr 14 17:00:45 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 14 Apr 2010 17:00:45 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <k2if65fb55e1004141335y1a73bda2n17dd4e42218ad45d@mail.gmail.com>
References: <20100413172714.M35473@fast-serv.com> <4BC4B1B6.7060804@ipinc.net>
	<A153ECC6B3414765B321340BCE7AFC16@changeip.com>
	<r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>
	<k2if65fb55e1004141335y1a73bda2n17dd4e42218ad45d@mail.gmail.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D701D5FCA513@SUEX07-MBX-04.ad.syr.edu>

> and remember, its not the number of routes per se, it's the cost of
> memory due to churn in routing announcements that is the cost you are
> talking about.

Thanks, now we are getting even more specific. Good. Details matter.

Churn probably has a completely different cost structure than simple "addition" of routes/memory consumption. 

Amazing how we've gone from a categorical statement to an incredibly nuanced and conditional one, isn't it?

Milton Mueller
Professor, Syracuse University School of Information Studies
XS4All Professor, Delft University of Technology
------------------------------
Internet Governance Project:
http://internetgovernance.org



From tedm at ipinc.net  Wed Apr 14 17:07:13 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 14 Apr 2010 14:07:13 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5FCA511@SUEX07-MBX-04.ad.syr.edu>
References: <20100413172714.M35473@fast-serv.com><4BC4B1B6.7060804@ipinc.net>	<A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>	<4BC62352.2090202@rollernet.us>
	<75822E125BCB994F8446858C4B19F0D701D5FCA511@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4BC62E81.3040600@ipinc.net>



On 4/14/2010 1:52 PM, Milton L Mueller wrote:
>> If you take a full unfiltered table without a default route, yes. This
>> is pretty basic for BGP.
>>
>
> I understand that. The issue is how many take a full table.
>

I think that years ago a lot more didn't take a full table.  But
dram is cheaper than paying a network admin to maintain a filter
table and so many sites nowadays haven't seemed to have heard
anything about the RADb or what it does, so filters created from
that database are more historical interest than anything else.
Without a valid and current routing arbiter it's a very labor intensive 
process to keep a filter updated, and the community cannot seem even to
keep WHOIS updated properly.

I'm just crossing my fingers that the hardware vendors can keep
ahead of table growth.  Maybe it would have been better for Nvidia
or ATI to be the major router manufacturers instead of Juniper or
Cisco, since both those companies seem to have an allergy to large
amounts of high speed ram in their products.

Ted


From mksmith at adhost.com  Wed Apr 14 17:08:12 2010
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Wed, 14 Apr 2010 14:08:12 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5FCA513@SUEX07-MBX-04.ad.syr.edu>
References: <20100413172714.M35473@fast-serv.com>
	<4BC4B1B6.7060804@ipinc.net><A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu><1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry><75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu><k2if65fb55e1004141335y1a73bda2n17dd4e42218ad45d@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D701D5FCA513@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <17838240D9A5544AAA5FF95F8D52031607EE0EA8@ad-exh01.adhost.lan>

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of Milton L Mueller
> Sent: Wednesday, April 14, 2010 2:01 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] IPv6 /32 minimum for extra-small ISP
> 
> > and remember, its not the number of routes per se, it's the cost of
> > memory due to churn in routing announcements that is the cost you
are
> > talking about.
> 
> Thanks, now we are getting even more specific. Good. Details matter.
> 
> Churn probably has a completely different cost structure than simple
> "addition" of routes/memory consumption.
> 
> Amazing how we've gone from a categorical statement to an incredibly
> nuanced and conditional one, isn't it?
> 
To what end?  What The people who have full tables are well aware of the
costs associated with a routing slot.  And, it's not just churn, it's
the actual routes in your RIB, then the FIB, plus the churn.  You have
memory and processor requirements that increase with each new route
added to the DFZ.

You seem to have a hypothesis hiding somewhere behind the Socratic
questioning.  What is it you want everyone to see?

Mike


From mueller at syr.edu  Wed Apr 14 17:09:50 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 14 Apr 2010 17:09:50 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <4BC62E81.3040600@ipinc.net>
References: <20100413172714.M35473@fast-serv.com><4BC4B1B6.7060804@ipinc.net>
	<A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>
	<4BC62352.2090202@rollernet.us>
	<75822E125BCB994F8446858C4B19F0D701D5FCA511@SUEX07-MBX-04.ad.syr.edu>
	<4BC62E81.3040600@ipinc.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D701D5FCA516@SUEX07-MBX-04.ad.syr.edu>

Thanks, Ted. Yet another interesting economic trade-off emerges. How would one get a bead on how many do and do not take a full table and how that ratio has changed over time? 

> I think that years ago a lot more didn't take a full table.  But
> dram is cheaper than paying a network admin to maintain a filter
> table and so many sites nowadays haven't seemed to have heard

Milton Mueller
Professor, Syracuse University School of Information Studies
XS4All Professor, Delft University of Technology
------------------------------
Internet Governance Project:
http://internetgovernance.org



From ggiesen at akn.ca  Wed Apr 14 17:11:13 2010
From: ggiesen at akn.ca (Gary T. Giesen)
Date: Wed, 14 Apr 2010 17:11:13 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <4BC62E81.3040600@ipinc.net>
References: <20100413172714.M35473@fast-serv.com> <4BC4B1B6.7060804@ipinc.net>
	<A153ECC6B3414765B321340BCE7AFC16@changeip.com>
	<r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>
	<4BC62352.2090202@rollernet.us>
	<75822E125BCB994F8446858C4B19F0D701D5FCA511@SUEX07-MBX-04.ad.syr.edu>
	<4BC62E81.3040600@ipinc.net>
Message-ID: <1271279473.5224.71.camel@ggiesen-workstation.netsurf.net>

On Wed, 2010-04-14 at 17:07 -0400, Ted Mittelstaedt wrote:
> 
> On 4/14/2010 1:52 PM, Milton L Mueller wrote:
> >> If you take a full unfiltered table without a default route, yes. This
> >> is pretty basic for BGP.
> >>
> >
> > I understand that. The issue is how many take a full table.
> >
> 
> I think that years ago a lot more didn't take a full table.  But
> dram is cheaper than paying a network admin to maintain a filter
> table and so many sites nowadays haven't seemed to have heard
> anything about the RADb or what it does, so filters created from
> that database are more historical interest than anything else.
> Without a valid and current routing arbiter it's a very labor intensive 
> process to keep a filter updated, and the community cannot seem even to
> keep WHOIS updated properly.
> 
> I'm just crossing my fingers that the hardware vendors can keep
> ahead of table growth.  Maybe it would have been better for Nvidia
> or ATI to be the major router manufacturers instead of Juniper or
> Cisco, since both those companies seem to have an allergy to large
> amounts of high speed ram in their products.

Even new Cisco's CPEs have have 2 GB of ram in them these days
(19xx/29xx series). But you're comparing two *COMPLETELY* different
kinds of ram. The Tertiary Content-Addressable Memory in hardware
forwarding platforms (7600 & up, Juniper M series) is *extremely*
expensive and they're running into density problems now. It's nothing
like the DRAM you see in a GPU.

GG


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



From mueller at syr.edu  Wed Apr 14 17:26:17 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 14 Apr 2010 17:26:17 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <17838240D9A5544AAA5FF95F8D52031607EE0EA8@ad-exh01.adhost.lan>
References: <20100413172714.M35473@fast-serv.com>
	<4BC4B1B6.7060804@ipinc.net><A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu><1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry><75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu><k2if65fb55e1004141335y1a73bda2n17dd4e42218ad45d@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D701D5FCA513@SUEX07-MBX-04.ad.syr.edu>
	<17838240D9A5544AAA5FF95F8D52031607EE0EA8@ad-exh01.adhost.lan>
Message-ID: <75822E125BCB994F8446858C4B19F0D701D5FCA517@SUEX07-MBX-04.ad.syr.edu>


> The people who have full tables are well aware of the
> costs associated with a routing slot.  And, it's not just churn, it's
> the actual routes in your RIB, then the FIB, plus the churn.  You have
> memory and processor requirements that increase with each new route
> added to the DFZ.

Sure. And everyone knew that apples fell down, not up, before Newton.
 
> You seem to have a hypothesis hiding somewhere behind the Socratic
> questioning.  

A hypothesis? No. What I do have is a hunch that the social and private costs of various approaches to routing policy/aggregation are much less well understood than we think they are - and therefore we have an inadequate basis for understanding the economic and efficiency implications of alternative policies.

Hmm, it might be possible to formulate that as a hypothesis, but I am doing it on the fly: 

H1: RIRs' discussions of address policy, esp concerning the tradeoffs concerning aggregation and accessibility of address blocks, and our ability to formulate appropriate policies, would improve if we had a more sophisticated model of how the size and distribution of the costs of route additions. 

--MM


From woody at pch.net  Wed Apr 14 17:36:38 2010
From: woody at pch.net (Bill Woodcock)
Date: Wed, 14 Apr 2010 21:36:38 +0000
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5FCA513@SUEX07-MBX-04.ad.syr.edu>
References: <20100413172714.M35473@fast-serv.com>
	<4BC4B1B6.7060804@ipinc.net><A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu><1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry><75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu><k2if65fb55e1004141335y1a73bda2n17dd4e42218ad45d@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA513@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <1665735650-1271281000-cardhu_decombobulator_blackberry.rim.net-452158009-@bda040.bisx.prod.on.blackberry>

No, Milton, It's not amazing, it's just what we do.  If we didn't, you'd be leaving your rants on well-worn cassette tapes in answering machines on the ends of analog pots lines instead of all over our nice clean Internet. There are, in fact, people on this list who are quite good at their jobs, and the fact of the matter is that they were quite good at their jobs long before you started asking them basic questions that you could have found the answers to if you had half the academic curiosity that motivated all of them as teenagers, when they asked the same questions. 

These revelations you keep having do not constitute brilliant academic insights.  You are merely receiving, and generally failing to comprehend the import of, the answers to _very_ basic questions. 

You're not a clever economic anthropologist studying the inscrutable ritual practices of a na?ve tribe of autistic engineers.  You are instead skimming the surface of a very complex and delicately architected economic, technical, and logical system, designed, built, and rebuilt-while-under-exponential-acceleration by people much smarter, more thoughtful, more introspective, and better-connected than yourself.  

And you're wasting their time. 


Sent via BlackBerry by AT&T

-----Original Message-----
From: Milton L Mueller <mueller at syr.edu>
Date: Wed, 14 Apr 2010 17:00:45 
To: arin-ppml at arin.net<arin-ppml at arin.net>
Subject: Re: [arin-ppml] IPv6 /32 minimum for extra-small ISP

> and remember, its not the number of routes per se, it's the cost of
> memory due to churn in routing announcements that is the cost you are
> talking about.

Thanks, now we are getting even more specific. Good. Details matter.

Churn probably has a completely different cost structure than simple "addition" of routes/memory consumption.

Amazing how we've gone from a categorical statement to an incredibly nuanced and conditional one, isn't it?

Milton Mueller
Professor, Syracuse University School of Information Studies
XS4All Professor, Delft University of Technology
------------------------------
Internet Governance Project:
http://internetgovernance.org

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


From mueller at syr.edu  Wed Apr 14 17:38:37 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 14 Apr 2010 17:38:37 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5FCA517@SUEX07-MBX-04.ad.syr.edu>
References: <20100413172714.M35473@fast-serv.com>
	<4BC4B1B6.7060804@ipinc.net><A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu><1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry><75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu><k2if65fb55e1004141335y1a73bda2n17dd4e42218ad45d@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D701D5FCA513@SUEX07-MBX-04.ad.syr.edu>
	<17838240D9A5544AAA5FF95F8D52031607EE0EA8@ad-exh01.adhost.lan>
	<75822E125BCB994F8446858C4B19F0D701D5FCA517@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <75822E125BCB994F8446858C4B19F0D701D5FCA51A@SUEX07-MBX-04.ad.syr.edu>

Yuk, that wasn't even grammatical. I warned you it was on the fly. Here's an edited version:

 H1: RIRs' discussions of address policy, and our ability to formulate 
 appropriate policies esp concerning the tradeoffs between aggregation 
 and accessibility of address blocks,, would improve if we had a more 
 sophisticated model of the size and distribution of the costs
 of route additions.


Milton Mueller
Professor, Syracuse University School of Information Studies
XS4All Professor, Delft University of Technology
------------------------------
Internet Governance Project:
http://internetgovernance.org




From NOC at ChangeIP.com  Wed Apr 14 17:39:24 2010
From: NOC at ChangeIP.com (NOC at ChangeIP.com)
Date: Wed, 14 Apr 2010 14:39:24 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
References: <20100413172714.M35473@fast-serv.com><4BC4B1B6.7060804@ipinc.net><A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu><1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry><75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu><k2if65fb55e1004141335y1a73bda2n17dd4e42218ad45d@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA513@SUEX07-MBX-04.ad.syr.edu><17838240D9A5544AAA5FF95F8D52031607EE0EA8@ad-exh01.adhost.lan>
	<75822E125BCB994F8446858C4B19F0D701D5FCA517@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <8692A26B68F04BC7A404E3579E7B0171@changeip.com>

Guys - stick to the question at hand... who cares about routing slots at the
moment, let's address the pricing piece of it.

If IPv6 is not supposed to cost any more if your already assigned IPv4, then
how can a small ISP get it without increased cost?  The pricing schedule on
arin.net lists x-small, but it's impossible to get, and the next size up is
more than the x-small IPv4 pricing.  Let's not argue and bicker about whos
router has more routes and memory.

Sam 



From mueller at syr.edu  Wed Apr 14 17:47:03 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 14 Apr 2010 17:47:03 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <1665735650-1271281000-cardhu_decombobulator_blackberry.rim.net-452158009-@bda040.bisx.prod.on.blackberry>
References: <20100413172714.M35473@fast-serv.com>
	<4BC4B1B6.7060804@ipinc.net><A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu><1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry><75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu><k2if65fb55e1004141335y1a73bda2n17dd4e42218ad45d@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA513@SUEX07-MBX-04.ad.syr.edu>
	<1665735650-1271281000-cardhu_decombobulator_blackberry.rim.net-452158009-@bda040.bisx.prod.on.blackberry>
Message-ID: <75822E125BCB994F8446858C4B19F0D701D5FCA51B@SUEX07-MBX-04.ad.syr.edu>


> -----Original Message-----
> 
> No, Milton, It's not amazing, it's just what we do.  If we didn't,
> you'd be leaving your rants on well-worn cassette tapes in answering

Bill, your hostility is wearisome and pointless. You need to think about why it exists - it's certainly not my problem, nor is it the list's. And everyone knows that there is nothing more to this statement than an expression of personal hostility. If ARIN is consistent about its acceptable use policies on this list you'll be promptly reprimanded. I'll leave it at that.  



From ggiesen at akn.ca  Wed Apr 14 17:55:25 2010
From: ggiesen at akn.ca (Gary T. Giesen)
Date: Wed, 14 Apr 2010 17:55:25 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <8692A26B68F04BC7A404E3579E7B0171@changeip.com>
References: <20100413172714.M35473@fast-serv.com>
	<4BC4B1B6.7060804@ipinc.net><A153ECC6B3414765B321340BCE7AFC16@changeip.com>
	<r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>
	<k2if65fb55e1004141335y1a73bda2n17dd4e42218ad45d@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D701D5FCA513@SUEX07-MBX-04.ad.syr.edu>
	<17838240D9A5544AAA5FF95F8D52031607EE0EA8@ad-exh01.adhost.lan>
	<75822E125BCB994F8446858C4B19F0D701D5FCA517@SUEX07-MBX-04.ad.syr.edu>
	<8692A26B68F04BC7A404E3579E7B0171@changeip.com>
Message-ID: <1271282125.5224.80.camel@ggiesen-workstation.netsurf.net>

On Wed, 2010-04-14 at 17:39 -0400, NOC at ChangeIP.com wrote:
> Guys - stick to the question at hand... who cares about routing slots at the
> moment, let's address the pricing piece of it.

There two are somewhat interrelated. If ARIN offered smaller
allocations, that would affect the goal of massive aggregation (and
impact routing slots).

If they offered the same allocation (/32) at a discounted price for ISPs
who would have previously paid a lesser amount, the guys who actually
need /32's would argue for the same price and obviously have a
significant impact on ARIN's operating budget. Since ISPs are the only
ones affected by this, and in the grand scheme of things the cost of IP
space is but a tiny fraction of the vast majority of most ISP's ongoing
costs (we're talking about $2250, or the cost of a *one* CPE router, per
year), I'm inclined to say let the policy stand as it is.

> If IPv6 is not supposed to cost any more if your already assigned IPv4, then
> how can a small ISP get it without increased cost?  The pricing schedule on
> arin.net lists x-small, but it's impossible to get, and the next size up is
> more than the x-small IPv4 pricing.  Let's not argue and bicker about whos
> router has more routes and memory.
> 
> Sam 
> 


GG



From mueller at syr.edu  Wed Apr 14 18:08:55 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 14 Apr 2010 18:08:55 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <4BC628EA.4040008@ipinc.net>
References: <20100413172714.M35473@fast-serv.com><4BC4B1B6.7060804@ipinc.net>
	<A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>
	<4BC628EA.4040008@ipinc.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D701D5FCA51F@SUEX07-MBX-04.ad.syr.edu>


> -----Original Message-----
> 
> Now, to turn your question on it's head, I'd like to ask if
> the assertion that a significant number of ISP's are filtering
> incoming BGP advertisements above a /24 has ever been tested,
> examined, or modeled?

No one made that assertion, as far as I can recall, in the current discussion, although I have seen intimations of such. 
But as far as I know, it has not been tested, examined or modeled in any depth. I wish it could be.

> (other than filtering the obvious stuff like
> a default route, RFC3330, etc.) as I think this is much less
> likely.  Would you really want to manage your routers on an Internet
> where everyone would be forced into doing this due to table bloat?

Of course not. But if various factors conspire, as you say, to "force" people to do that, it's precisely the kind of trade-off that needs to be understood better. As economic analyst, I am not immediately interested in whether that's a the ideal situation for the Internet. I am interested in 
  a) if it is happening 
  b) what economic incentives are making it happen and sustaining it
  c) what externalities (negative or otherwise) it imposes on the rest of the Internet

There are people on this list who seem to be deeply threatened by the fact that someone is merely asking these kinds of questions. I am completely puzzled by this.  



From mueller at syr.edu  Wed Apr 14 18:17:29 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 14 Apr 2010 18:17:29 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <1271282125.5224.80.camel@ggiesen-workstation.netsurf.net>
References: <20100413172714.M35473@fast-serv.com>
	<4BC4B1B6.7060804@ipinc.net><A153ECC6B3414765B321340BCE7AFC16@changeip.com>
	<r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>
	<k2if65fb55e1004141335y1a73bda2n17dd4e42218ad45d@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D701D5FCA513@SUEX07-MBX-04.ad.syr.edu>
	<17838240D9A5544AAA5FF95F8D52031607EE0EA8@ad-exh01.adhost.lan>
	<75822E125BCB994F8446858C4B19F0D701D5FCA517@SUEX07-MBX-04.ad.syr.edu>
	<8692A26B68F04BC7A404E3579E7B0171@changeip.com>
	<1271282125.5224.80.camel@ggiesen-workstation.netsurf.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D701D5FCA520@SUEX07-MBX-04.ad.syr.edu>


> -----Original Message-----
> 
> There two are somewhat interrelated. If ARIN offered smaller
> allocations, that would affect the goal of massive aggregation (and
> impact routing slots).

Yes, obviously. That is why we got into a discussion of the tradeoff. 

> If they offered the same allocation (/32) at a discounted price for
> ISPs who would have previously paid a lesser amount, the guys who actually
> need /32's would argue for the same price and obviously have a
> significant impact on ARIN's operating budget. Since ISPs are the only
> ones affected by this, and in the grand scheme of things the cost of IP
> space is but a tiny fraction of the vast majority of most ISP's ongoing
> costs (we're talking about $2250, or the cost of a *one* CPE router,
> per year), I'm inclined to say let the policy stand as it is.

What's wrong with offering the smaller ISP something smaller than a /32 at a lower price? 



From michael.dillon at bt.com  Wed Apr 14 18:18:44 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 14 Apr 2010 23:18:44 +0100
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <C7EBA3CA.2C76B%marty@akamai.com>
Message-ID: <28E139F46D45AF49A31950F88C49745805C3F813@E03MVZ2-UKDY.domain1.systemhost.net>

>     http://www.lookingglass.level3.net

Non-existent site.

> > I really would like to know if someone is keeping an up to date and 
> > maintained list of open looking glass sites.
> > 
> 
> Try your favorite search engine.

A an up to date and maintained list of everything, everywhere,
is not the same as a list of open looking glass sites.

YMMV

--Michael Dillon


From farmer at umn.edu  Wed Apr 14 18:20:39 2010
From: farmer at umn.edu (David Farmer)
Date: Wed, 14 Apr 2010 17:20:39 -0500
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5FCA516@SUEX07-MBX-04.ad.syr.edu>
References: <20100413172714.M35473@fast-serv.com><4BC4B1B6.7060804@ipinc.net>	<A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>	<4BC62352.2090202@rollernet.us>	<75822E125BCB994F8446858C4B19F0D701D5FCA511@SUEX07-MBX-04.ad.syr.edu>	<4BC62E81.3040600@ipinc.net>
	<75822E125BCB994F8446858C4B19F0D701D5FCA516@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4BC63FB7.5000404@umn.edu>

Milton L Mueller wrote:
> How would one get a bead on how many do and do not take a full table and how that ratio has changed over time? 

<snarky on>

At the risk of creating an matter-antimatter reaction within ARIN's list 
server, I will use both Randy's and Milton's names in the same email.  I 
will apologize now if the chain reaction destroys the universe.  :)

<snarky off>

Randy Bush and others have the done some related work;

http://psg.com/~olaf/measurements/as3130/measurements.html

For paper and slides;

http://psg.com/~olaf/measurements/as3130/publications.html

Quick summary from there data;

		# tested 	default 	default-free 	mixed
stub 		24,224 		77.1% 		19.3% 		3.6%
small ISP 	1,307 		44.5% 		42.2% 		13.3%
large ISP 	246 		17.1% 		60.6% 		22.3%

You could probably come up with some kind of model to create an estimate 
of how many routers that represents.

When I look at this data it seem to me that it supports the general 
hypothesis those that add prefixes to the DFZ are probably not sharing 
equally in the costs associated with the additional prefixes.

Whoops, there she Blow......

:)

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


From michael.dillon at bt.com  Wed Apr 14 18:20:49 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 14 Apr 2010 23:20:49 +0100
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <4BC62C0B.50904@ibctech.ca>
Message-ID: <28E139F46D45AF49A31950F88C49745805C3F814@E03MVZ2-UKDY.domain1.systemhost.net>


> Do these count?:
> 
> acct-dev: ISP % telnet route-views.routeviews.org Trying 
> 2001:468:d01:33::80df:3367...
> Connected to route-views.routeviews.org.
> Escape character is '^]'.

Nope. 

Not a site, and definitely not the kind of thing
that you could refer to the average college professor,
high school student, etc.

--Michael Dillon

P.S. Did I err in saying "site" rather than website?




From steve at ibctech.ca  Wed Apr 14 18:21:11 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Wed, 14 Apr 2010 18:21:11 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <4BC62C0B.50904@ibctech.ca>
References: <28E139F46D45AF49A31950F88C49745805C3F7F3@E03MVZ2-UKDY.domain1.systemhost.net>
	<4BC62C0B.50904@ibctech.ca>
Message-ID: <4BC63FD7.40903@ibctech.ca>

On 2010.04.14 16:56, Steve Bertrand wrote:
> On 2010.04.14 16:51, michael.dillon at bt.com wrote:
>>
>>> There are these things called "looking glasses" you can find 
>>> them at traceroute.org and when you log in to them you will 
>>> see that BGP propagation is pretty much world-wide.  It's a 
>>> pretty amazing thing, this Internet network.
>>
>> Oh yeah? And where might one find these "looking glass" thingies?
> 
> Do these count?:
> 
> acct-dev: ISP % telnet route-views.routeviews.org
> Trying 2001:468:d01:33::80df:3367...
> Connected to route-views.routeviews.org.
> Escape character is '^]'.

To fix my own post, I believe that I implied that routeviews.org was v4
only when I said this:

> or, for v6:
> 
> http://www.sixxs.net/tools/grh/lg/

That isn't the case. route-views.routeviews.org provides both v4 and v6
(as is probably evident in my vty connection above).

What I meant to say was:

or, *web-based* for v6:

http://www.sixxs.net/tools/grh/lg/

Point is, there are still very, very reliable looking glasses. Kudos to
you all who maintain them.

Steve


From kkargel at polartel.com  Wed Apr 14 18:26:20 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 14 Apr 2010 17:26:20 -0500
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <28E139F46D45AF49A31950F88C49745805C3F813@E03MVZ2-UKDY.domain1.systemhost.net>
References: <C7EBA3CA.2C76B%marty@akamai.com>
	<28E139F46D45AF49A31950F88C49745805C3F813@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <8695009A81378E48879980039EEDAD28876D44EC@MAIL1.polartel.local>

Hey Micheal,
If you would create and maintain such a site that would be great.  Please let me know when you make it public.

Kevin


 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of michael.dillon at bt.com
> Sent: Wednesday, April 14, 2010 5:19 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] IPv6 /32 minimum for extra-small ISP
> 
> >     http://www.lookingglass.level3.net
> 
> Non-existent site.
> 
> > > I really would like to know if someone is keeping an up to date and
> > > maintained list of open looking glass sites.
> > >
> >
> > Try your favorite search engine.
> 
> A an up to date and maintained list of everything, everywhere,
> is not the same as a list of open looking glass sites.
> 
> YMMV
> 
> --Michael Dillon
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From steve at ibctech.ca  Wed Apr 14 18:27:59 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Wed, 14 Apr 2010 18:27:59 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <28E139F46D45AF49A31950F88C49745805C3F814@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745805C3F814@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4BC6416F.6040809@ibctech.ca>

On 2010.04.14 18:20, michael.dillon at bt.com wrote:
> 
>> Do these count?:
>>
>> acct-dev: ISP % telnet route-views.routeviews.org Trying 
>> 2001:468:d01:33::80df:3367...
>> Connected to route-views.routeviews.org.
>> Escape character is '^]'.
> 
> Nope. 
> 
> Not a site, and definitely not the kind of thing
> that you could refer to the average college professor,
> high school student, etc.
> 
> --Michael Dillon
> 
> P.S. Did I err in saying "site" rather than website?

My apologies. I didn't read far enough into it. I should have known
better ;)

Steve


From steve at ibctech.ca  Wed Apr 14 18:30:20 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Wed, 14 Apr 2010 18:30:20 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <8695009A81378E48879980039EEDAD28876D44EC@MAIL1.polartel.local>
References: <C7EBA3CA.2C76B%marty@akamai.com>	<28E139F46D45AF49A31950F88C49745805C3F813@E03MVZ2-UKDY.domain1.systemhost.net>
	<8695009A81378E48879980039EEDAD28876D44EC@MAIL1.polartel.local>
Message-ID: <4BC641FC.2090202@ibctech.ca>

On 2010.04.14 18:26, Kevin Kargel wrote:
> Hey Micheal,
> If you would create and maintain such a site that would be great.  Please let me know when you make it public.

That, or financially sponsor someone to do so. Particularly, someone who
has been providing the service reliably for years, but doesn't have the
resources to put a web GUI on top of it.

Steve


From michael.dillon at bt.com  Wed Apr 14 18:30:21 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 14 Apr 2010 23:30:21 +0100
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <8692A26B68F04BC7A404E3579E7B0171@changeip.com>
Message-ID: <28E139F46D45AF49A31950F88C49745805C3F815@E03MVZ2-UKDY.domain1.systemhost.net>

> If IPv6 is not supposed to cost any more if your already 
> assigned IPv4, then how can a small ISP get it without 
> increased cost? 

Number all your internal infrastructure with a ULA-L block
as defined in RFC 4193, and get another ULA-L block to
reuse for every customer. Yes, it means that they will
have problems doing P2P with each other, but that's life.
Then get a /48 block from your upstream. All this is free.

> The pricing schedule on arin.net lists 
> x-small, but it's impossible to get, and the next size up is 
> more than the x-small IPv4 pricing.  Let's not argue and 
> bicker about whos router has more routes and memory.

Screw ARIN and their price lists, screw arguing and bickering.
Skip the agravation and go straight to your upstream and your
RFC 4193 blocks. Use this tool to help you choose your ULA-L
prefix: <http://www.sixxs.net/tools/grh/ula/>

Let the big boys play ARIN games. You don't have to.

--Michael Dillon

P.S. some might think that I am joking around. Not really.
The fact is that there are options out there, and not
everybody needs to follow the same piper. Diversity is
good.


From michael.dillon at bt.com  Wed Apr 14 18:37:40 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 14 Apr 2010 23:37:40 +0100
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <4BC641FC.2090202@ibctech.ca>
Message-ID: <28E139F46D45AF49A31950F88C49745805C3F816@E03MVZ2-UKDY.domain1.systemhost.net>

> > If you would create and maintain such a site that would be 
> great.  Please let me know when you make it public.
> 
> That, or financially sponsor someone to do so. Particularly, 
> someone who has been providing the service reliably for 
> years, but doesn't have the resources to put a web GUI on top of it.

I don't have the resources (time or money) to do this.

Generally, it is better to publicize the need, and some
entrepreneurial folks lurking at the back of the list,
build these things and offer them to the world.

If the need was real, the sites grow and thrive. For a case
study, look at what happened with Cymru and the bogon lists.

Perhaps traceroute.org just never got enough users to make
it worthwhile to maintain the list... Perhaps the need for
such things no longer exists.

--Michael Dillon


From farmer at umn.edu  Wed Apr 14 18:38:39 2010
From: farmer at umn.edu (David Farmer)
Date: Wed, 14 Apr 2010 17:38:39 -0500
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <4BC641FC.2090202@ibctech.ca>
References: <C7EBA3CA.2C76B%marty@akamai.com>	<28E139F46D45AF49A31950F88C49745805C3F813@E03MVZ2-UKDY.domain1.systemhost.net>	<8695009A81378E48879980039EEDAD28876D44EC@MAIL1.polartel.local>
	<4BC641FC.2090202@ibctech.ca>
Message-ID: <4BC643EF.10206@umn.edu>

Steve Bertrand wrote:
> On 2010.04.14 18:26, Kevin Kargel wrote:
>> Hey Micheal,
>> If you would create and maintain such a site that would be great.  Please let me know when you make it public.
> 
> That, or financially sponsor someone to do so. Particularly, someone who
> has been providing the service reliably for years, but doesn't have the
> resources to put a web GUI on top of it.
> 
> Steve

Check out;

http://www.bgp4.net/

Specifically;

http://www.bgp4.net/wiki/doku.php?id=tools:ipv4_looking_glasses
http://www.bgp4.net/wiki/doku.php?id=tools:ipv6_looking_glasses

How is that?

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


From mueller at syr.edu  Wed Apr 14 18:39:43 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 14 Apr 2010 18:39:43 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <4BC63FB7.5000404@umn.edu>
References: <20100413172714.M35473@fast-serv.com><4BC4B1B6.7060804@ipinc.net>
	<A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>
	<4BC62352.2090202@rollernet.us>
	<75822E125BCB994F8446858C4B19F0D701D5FCA511@SUEX07-MBX-04.ad.syr.edu>
	<4BC62E81.3040600@ipinc.net>
	<75822E125BCB994F8446858C4B19F0D701D5FCA516@SUEX07-MBX-04.ad.syr.edu>
	<4BC63FB7.5000404@umn.edu>
Message-ID: <75822E125BCB994F8446858C4B19F0D701D5FCA522@SUEX07-MBX-04.ad.syr.edu>

Thanks. Real data. Seems like a useful contribution to the discussion. Not sure why the questions leading to this point generated such hostility, nor why it had to be preambled with "snarky" stuff.

So the "every router" statement has now dwindled to "most large ISP routers and about half of small ISP routers, which together compose about 10% of the world's routers." (Could be a misreading of the data because we don't know whether Randy's #tested is representative of the proportion in the total population.)  

And the interpretation you draw, which I agree with:

> those that add prefixes to the DFZ are probably not sharing
> equally in the costs associated with the additional prefixes

Yeah, we all knew that, but it is better to have a finer understanding of the specific disjunction in the distribution of costs and benefits, which is well known at least in my field as the motor of policy conflict and change...this could lead to a better understanding of how the associated tragedy of the commons has a specific structure and dynamic and what policy measures would best address it.

--MM

> -----Original Message-----
> 
> 
> 		     # tested 	default 	default-free 	mixed
> stub 		24,224 	77.1% 	19.3% 		3.6%
> small ISP 	1,307 	44.5% 	42.2% 		13.3%
> large ISP 	246 		17.1% 	60.6% 		22.3%
> 
> You could probably come up with some kind of model to create an
> estimate of how many routers that represents.
> 
> When I look at this data it seem to me that it supports the general
> hypothesis those that add prefixes to the DFZ are probably not sharing
> equally in the costs associated with the additional prefixes.
> 
> Whoops, there she Blow......
> 
> :)
> 
> --
> ===============================================
> David Farmer               Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE	    Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================


From steve at ibctech.ca  Wed Apr 14 18:43:36 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Wed, 14 Apr 2010 18:43:36 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <4BC643EF.10206@umn.edu>
References: <C7EBA3CA.2C76B%marty@akamai.com>	<28E139F46D45AF49A31950F88C49745805C3F813@E03MVZ2-UKDY.domain1.systemhost.net>	<8695009A81378E48879980039EEDAD28876D44EC@MAIL1.polartel.local>
	<4BC641FC.2090202@ibctech.ca> <4BC643EF.10206@umn.edu>
Message-ID: <4BC64518.80607@ibctech.ca>

On 2010.04.14 18:38, David Farmer wrote:
> Steve Bertrand wrote:
>> On 2010.04.14 18:26, Kevin Kargel wrote:
>>> Hey Micheal,
>>> If you would create and maintain such a site that would be great. 
>>> Please let me know when you make it public.
>>
>> That, or financially sponsor someone to do so. Particularly, someone who
>> has been providing the service reliably for years, but doesn't have the
>> resources to put a web GUI on top of it.
>>
>> Steve
> 
> Check out;
> 
> http://www.bgp4.net/
> 
> Specifically;
> 
> http://www.bgp4.net/wiki/doku.php?id=tools:ipv4_looking_glasses
> http://www.bgp4.net/wiki/doku.php?id=tools:ipv6_looking_glasses
> 
> How is that?

Perfectly great!

Did I miss those links earlier in the thread?

fwiw, I'm content being gui-less, but a couple 'clicks' on random links
from those pages most certainly provide an interface to a working
looking glass.

Steve



From bill at herrin.us  Wed Apr 14 18:50:55 2010
From: bill at herrin.us (William Herrin)
Date: Wed, 14 Apr 2010 18:50:55 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
References: <20100413172714.M35473@fast-serv.com> <4BC4B1B6.7060804@ipinc.net>
	<A153ECC6B3414765B321340BCE7AFC16@changeip.com>
	<r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <m2q3c3e3fca1004141550jf150bea5m7caff7176b63625e@mail.gmail.com>

On Wed, Apr 14, 2010 at 3:58 PM, Milton L Mueller <mueller at syr.edu> wrote:
>> -----Original Message-----
>> The problem is that even if you got an extremely small allocation
>> that as soon as you advertise it, you consume the same amount of
>> routing resources on everyone else's BGP router on the Internet,
>> that someone with a larger allocation has who is advertising theirs.
>>?Thus it is not fair to base pricing solely on the amount of numbering.
>
> Just curious. Has this assertion ever been tested, examined, modeled?
> There are two logical components to this statement that I am
> interested in verifying:
> A small allocation:
> a) "consumes the same amount of resources"
> b) on "everyone else's" BGP router
>
> The latter is an especially strong claim.

Hi Milton,

One prefix has the same routing table cost regardless of whether it's
the whole Internet (0.0.0.0/0) or a single address (e.g.
99.88.77.66/32.). To be effective each prefix must be carried in every
"DFZ" router.* Worse, routing table costs are overhead for which no
mechanism presently exists to recover the cost from the folks
announcing the prefix.

Packet forwarding costs vary by traffic instead of by route count, but
packet forwarding costs are directly recovered from the customers
generating and/or consuming the packets.

See http://bill.herrin.us/network/bgpcost.html for an analysis of
routing table costs.

* I talk about routers in the "default-free zone" (DFZ) instead of BGP
routers because it's possible to run partial BGP at the edge of the
network that replaces some or all routes with a default route. Such
routers are not part of the DFZ since they need a default route to
someone else who does carry the whole table in order to reach everyone
else.


A more subtle question is the degree to which an organization's size
tends to impact their disaggregation (tendency to announce each
address block as multiple prefixes).


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 marty at akamai.com  Wed Apr 14 18:51:18 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Wed, 14 Apr 2010 18:51:18 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <28E139F46D45AF49A31950F88C49745805C3F813@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <C7EBBF26.2C7BE%marty@akamai.com>


> From: <michael.dillon at bt.com>
> Date: Wed, 14 Apr 2010 23:18:44 +0100
> To: <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] IPv6 /32 minimum for extra-small ISP
> 
>>     http://www.lookingglass.level3.net
> 
> Non-existent site.


That's right, drop the www. But you knew that.




From ptimmins at clearrate.com  Wed Apr 14 18:54:49 2010
From: ptimmins at clearrate.com (Paul G. Timmins)
Date: Wed, 14 Apr 2010 22:54:49 +0000
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5FCA522@SUEX07-MBX-04.ad.syr.edu>
References: <20100413172714.M35473@fast-serv.com><4BC4B1B6.7060804@ipinc.net>
	<A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>
	<4BC62352.2090202@rollernet.us>
	<75822E125BCB994F8446858C4B19F0D701D5FCA511@SUEX07-MBX-04.ad.syr.edu>
	<4BC62E81.3040600@ipinc.net>
	<75822E125BCB994F8446858C4B19F0D701D5FCA516@SUEX07-MBX-04.ad.syr.edu>
	<4BC63FB7.5000404@umn.edu>
	<75822E125BCB994F8446858C4B19F0D701D5FCA522@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <DD9D6CFA501E424DB214385CBF643C031CD67F8B@exchange1.corp.clearrate.net>


> Thanks. Real data. Seems like a useful contribution to the discussion.
> Not sure why the questions leading to this point generated such
> hostility, nor why it had to be preambled with "snarky" stuff.
> 
> So the "every router" statement has now dwindled to "most large ISP
> routers and about half of small ISP routers, which together compose
> about 10% of the world's routers." (Could be a misreading of the data
> because we don't know whether Randy's #tested is representative of the
> proportion in the total population.)

Another thing to consider is that just because someone has a default route doesn't mean they don't carry full tables. A recent acquisition by our company had two routers with full tables to different ISPs, but there was still a floating static route configured.

I think this is probably pretty common - admins who aren't BGP professionals not wanting to trust their BGP configurations entirely in the event they do something wrong. But there are definitely costs to carry the routes, regardless if they use a floating static or not.

-Paul
(who has a router taking full feeds at his house (hiding behind his employer's ASN, not de-aggregating!), with a floating static out to a backup internet connection)


From steve at ibctech.ca  Wed Apr 14 19:13:34 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Wed, 14 Apr 2010 19:13:34 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <DD9D6CFA501E424DB214385CBF643C031CD67F8B@exchange1.corp.clearrate.net>
References: <20100413172714.M35473@fast-serv.com><4BC4B1B6.7060804@ipinc.net>	<A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>	<4BC62352.2090202@rollernet.us>	<75822E125BCB994F8446858C4B19F0D701D5FCA511@SUEX07-MBX-04.ad.syr.edu>	<4BC62E81.3040600@ipinc.net>	<75822E125BCB994F8446858C4B19F0D701D5FCA516@SUEX07-MBX-04.ad.syr.edu>	<4BC63FB7.5000404@umn.edu>	<75822E125BCB994F8446858C4B19F0D701D5FCA522@SUEX07-MBX-04.ad.syr.edu>
	<DD9D6CFA501E424DB214385CBF643C031CD67F8B@exchange1.corp.clearrate.net>
Message-ID: <4BC64C1E.1060401@ibctech.ca>

On 2010.04.14 18:54, Paul G. Timmins wrote:
> 
>> Thanks. Real data. Seems like a useful contribution to the discussion.
>> Not sure why the questions leading to this point generated such
>> hostility, nor why it had to be preambled with "snarky" stuff.
>>
>> So the "every router" statement has now dwindled to "most large ISP
>> routers and about half of small ISP routers, which together compose
>> about 10% of the world's routers." (Could be a misreading of the data
>> because we don't know whether Randy's #tested is representative of the
>> proportion in the total population.)
> 
> Another thing to consider is that just because someone has a default route doesn't mean they don't carry full tables. A recent acquisition by our company had two routers with full tables to different ISPs, but there was still a floating static route configured.
> 
> I think this is probably pretty common - admins who aren't BGP professionals not wanting to trust their BGP configurations entirely in the event they do something wrong. But there are definitely costs to carry the routes, regardless if they use a floating static or not.

I can't differentiate between NANOG and ARIN PPML anymore, so what the
heck :)

What I haven't seen noted yet, is that there is also a cost to
_filtering_ a route that you don't want.

If you aren't AS-HUGE who can afford to accept only very large prefixes
until they find out whether it makes practical sense to do otherwise, it
costs the same or even more to keep a route *out* of my routing table.

Whether it's accepting a prefix in BGP, or having a default route where
one has to create ACLs to block traffic to a destination, there is a cost.

I'd like to think that even a small enterprise would maintain a list of
destination prefixes that they don't want their users going to...when
they do, where do they apply the rules?

Do they lower costs by maintaining the rules only at the outside
perimeter, and then deal with bandwidth issues when they have to focus
on excess traffic transiting the network until it hits the ACL? Or do
they spend on documenting the network clearly, applying sound practices
on each device on the network?

...I'm just curious. I see that there is a cost to each new prefix,
whether BGP is involved or not.

Steve


From christopher.morrow at gmail.com  Wed Apr 14 21:03:48 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Wed, 14 Apr 2010 21:03:48 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <4BC61C97.4090702@ipinc.net>
References: <k2m75cb24521004052327ne0e957b2w4ecf79f67a1bd1e2@mail.gmail.com>
	<28E139F46D45AF49A31950F88C49745805AF0623@E03MVZ2-UKDY.domain1.systemhost.net>
	<y2q75cb24521004141209yffa1781ia375460170351d4a@mail.gmail.com>
	<4BC61C97.4090702@ipinc.net>
Message-ID: <m2l75cb24521004141803t97b3f3bfn35d973fe49b84595@mail.gmail.com>

On Wed, Apr 14, 2010 at 3:50 PM, Ted Mittelstaedt <tedm at ipinc.net> wrote:
>
>
> On 4/14/2010 12:09 PM, Christopher Morrow wrote:
>>
>> On Tue, Apr 6, 2010 at 4:49 AM,<michael.dillon at bt.com> ?wrote:
>>>
>>>> because I have 2 locations, one in NYC one in SFO. Running a
>>>> private network link between them is more expensive than 2
>>>> commodity internet links, I can't (today) expect longer than
>>>> a /48 to pass through inter-AS boundaries... so I need (now)
>>>> a /47.
>>>
>>> Why would you want to run a national network when you have
>>> only two locations?
>>
>> I don't, I want to multi-home both of my sites... I have a regulatory
>> reason to want better assurance that my sites are up and reachable.
>>
>
> If this is true, that you really want to speak IPv6 over BGP to
> multiple providers are each of those locations, then your going to be
> laying out at LEAST $1500 per month per location, for the SMALLEST
> amount of bandwidth. ?At least, that is my experience with sites in
> the US.

that's not really relevant to the scenario, and if business needs
dictate better/more-reliable internet (all your transactions in the
remote location depend upon the interwebz) then... 1500 isn't all that
much really.

My point really is, there are quite a few folks multihomed today, the
trend isn't downward sloping on that, or wasn't last I looked.

> This kind of network simply does not match the hypothetical
> Allstate Insurance remote sites. ?I've BEEN in at least one of
> those Allstate sites and I didn't see any 2 T1's coming into a router. DSL,
> Cable, yeah. ?But not real live BGP-capable circuits.

sure, allstate's an extreme example and they chose a different
architecture, but my point again is that multihoming is increasing,
and dependence upon the network is increasing. we ought to plan for
that, not box people into less capable solutions. (or remove options
they may chose to use because they better fit their business needs)

-Chris

>>>
>>>> Look at Allstate Insurance that had, at last count +10k
>>>> remote sites... a /48 is a single SITE, not a single ORGANIZATION.
>>>
>>> Why would an insurance company want to run a national network?
>>
>> they don't, they want to use commodity network services in region,
>> they also want (potentially) to multihome some portions of these
>> mythical 10k sites.
>>
>
> Good luck. ?As the famous quote in Gone With The Wind went,
>
> "askin ain't gettin"
>
> Ted
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>


From joelja at bogus.com  Wed Apr 14 23:58:42 2010
From: joelja at bogus.com (Joel Jaeggli)
Date: Wed, 14 Apr 2010 20:58:42 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <28E139F46D45AF49A31950F88C49745805C3F814@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745805C3F814@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4BC68EF2.6070500@bogus.com>



On 04/14/2010 03:20 PM, michael.dillon at bt.com wrote:
> 
>> Do these count?:
>>
>> acct-dev: ISP % telnet route-views.routeviews.org Trying 
>> 2001:468:d01:33::80df:3367...
>> Connected to route-views.routeviews.org.
>> Escape character is '^]'.
> 
> Nope. 
> 
> Not a site, and definitely not the kind of thing
> that you could refer to the average college professor,
> high school student, etc.

given the amount of papers and tools generated  using routeviews and
routeviews data over the last 13 years that statement gives me pause.

http://routeviews.org/


> --Michael Dillon
> 
> P.S. Did I err in saying "site" rather than website?
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 


From owen at delong.com  Wed Apr 14 23:55:10 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 14 Apr 2010 20:55:10 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
References: <20100413172714.M35473@fast-serv.com>
	<4BC4B1B6.7060804@ipinc.net>	<A153ECC6B3414765B321340BCE7AFC16@changeip.com>
	<r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <1E008F81-663D-4C43-BBC6-E423647DB657@delong.com>


On Apr 14, 2010, at 12:58 PM, Milton L Mueller wrote:

>> -----Original Message-----
>> The problem is that even if you got an extremely small allocation
>> that as soon as you advertise it, you consume the same amount of 
>> routing resources on everyone else's BGP router on the Internet, 
>> that someone with a larger allocation has who is advertising theirs. 
>>  Thus it is not fair to base pricing solely on the amount of numbering.
> 
> Just curious. Has this assertion ever been tested, examined, modeled?
> There are two logical components to this statement that I am interested in verifying: 
> A small allocation: 
> a) "consumes the same amount of resources" 
> b) on "everyone else's" BGP router
> 
Milton,
	A globally visible prefix is a globally visible prefix.

	If your prefix is globally visible, then, yes, it takes a single
prefix slot in everyone else's "full-table" router(s).

	There is no difference in the amount of table space occupied
on any router between a /33, a /48, and a /128 unless one of them
is de-aggregated into multiple prefixes.

These facts are routing 101 nature of how routers work. They are
not logical assumptions that need to be modeled. They are simple
hard fact of how the system is designed and operates.

Owen

(Note, I still think that PI for whoever needs it is a good idea and that
the routing system will find a way to adapt well within the required
timeframe. As such, if it were somehow possible to prove these
facts wrong, I would have a vested interest in doing so, but, even
I recognize that these are the basic facts of the situation.)



From owen at delong.com  Thu Apr 15 00:04:14 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 14 Apr 2010 21:04:14 -0700
Subject: [arin-ppml] FW:  IPv6 /32 minimum for extra-small ISP
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5FCA512@SUEX07-MBX-04.ad.syr.edu>
References: <75822E125BCB994F8446858C4B19F0D701D5FCA512@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <43908D31-F6B1-4239-95BB-9E62BB3AD523@delong.com>

Virtually all backbone routers
All DFZ ISP Edge Routers
Virtually all core routers
Many many others.

So many that for any practical discussion of addressing policy, let's just say they
constitute the vast majority of deployed ISP routers.

Owen

On Apr 14, 2010, at 1:58 PM, Milton L Mueller wrote:

> 
>> 
>> If you are taking full tables and the route is not filtered along the
>> way, yes, you should have a new route in BGP on your router.
>> 
> 
> A couple of important "ifs". Thanks.
> 
> How many organizational routers on the Internet don't "take full tables?" 
> 
> As usual, things which are bandied about as "facts" have nuances that are quite consequential if you are trying to understand the real economics and interdependencies. 
> 
> Milton Mueller
> Professor, Syracuse University School of Information Studies
> XS4All Professor, Delft University of Technology
> ------------------------------
> Internet Governance Project:
> http://internetgovernance.org
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From owen at delong.com  Thu Apr 15 00:00:19 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 14 Apr 2010 21:00:19 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <28E139F46D45AF49A31950F88C49745805C3F7F3@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745805C3F7F3@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <3ED2B3D3-D84B-4BF3-9C4C-E8FD8365B49C@delong.com>

Routeviews still works
route-server.cerf.net still worked last I checked
route-server.he.net still works

There are many more that still work.

Owen

On Apr 14, 2010, at 1:51 PM, <michael.dillon at bt.com> <michael.dillon at bt.com> wrote:

> 
>> There are these things called "looking glasses" you can find 
>> them at traceroute.org and when you log in to them you will 
>> see that BGP propagation is pretty much world-wide.  It's a 
>> pretty amazing thing, this Internet network.
> 
> Oh yeah? And where might one find these "looking glass" thingies?
> 
> And don't try to fob off a bunch of URLs listing Looking Glass
> sites where 90% of the sites listed were shut down years ago.
> 
> I really would like to know if someone is keeping an up
> to date and maintained list of open looking glass sites.
> 
> --Michael Dillon
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From owen at delong.com  Thu Apr 15 00:00:43 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 14 Apr 2010 21:00:43 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5FCA511@SUEX07-MBX-04.ad.syr.edu>
References: <20100413172714.M35473@fast-serv.com><4BC4B1B6.7060804@ipinc.net>
	<A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>
	<4BC62352.2090202@rollernet.us>
	<75822E125BCB994F8446858C4B19F0D701D5FCA511@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <7674C60E-692F-437C-ACEE-1CB90133107A@delong.com>

All of the ones that care about FIB expansion.

Owen

On Apr 14, 2010, at 1:52 PM, Milton L Mueller wrote:

>> If you take a full unfiltered table without a default route, yes. This
>> is pretty basic for BGP.
>> 
> 
> I understand that. The issue is how many take a full table. 
> 
> Milton Mueller
> Professor, Syracuse University School of Information Studies
> XS4All Professor, Delft University of Technology
> ------------------------------
> Internet Governance Project:
> http://internetgovernance.org
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From michael.dillon at bt.com  Thu Apr 15 01:43:40 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 15 Apr 2010 06:43:40 +0100
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <4BC643EF.10206@umn.edu>
Message-ID: <28E139F46D45AF49A31950F88C49745805C3F831@E03MVZ2-UKDY.domain1.systemhost.net>


> http://www.bgp4.net/wiki/doku.php?id=tools:ipv4_looking_glasses
> http://www.bgp4.net/wiki/doku.php?id=tools:ipv6_looking_glasses
> 
> How is that?

Very good. Of the 5 links that I tried, 5 led to a looking glass.
It does require a good command of geography, company names, and
two letter TLDs to choose locations, but it is a good start.

--Michael Dillon


From michael.dillon at bt.com  Thu Apr 15 01:51:15 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 15 Apr 2010 06:51:15 +0100
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <4BC68EF2.6070500@bogus.com>
Message-ID: <28E139F46D45AF49A31950F88C49745805C3F833@E03MVZ2-UKDY.domain1.systemhost.net>

> > Not a site, and definitely not the kind of thing that you 
> could refer 
> > to the average college professor, high school student, etc.
> 
> given the amount of papers and tools generated  using 
> routeviews and routeviews data over the last 13 years that 
> statement gives me pause.
> 
> http://routeviews.org/

Routeviews is a tool for professionals who run networks and 
debug anomalies in routing. Or for academics who study network
behavior. Not the same thing as a looking glass.

--Michael Dillon


From Matthew.Gams at chartercom.com  Thu Apr 15 10:27:43 2010
From: Matthew.Gams at chartercom.com (Gams, Matthew D)
Date: Thu, 15 Apr 2010 09:27:43 -0500
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA616@Skyhawk>
References: <mailman.833.1269897550.28982.arin-ppml@arin.net>
	<F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA616@Skyhawk>
Message-ID: <21E4831D76704142BBAF6DC8F252904A0164AD6302@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>

I don't understand why everyone wants to go IPv6 with global addressing everywhere. And the solution to renumbering is getting organizations with their own blocks which will slowly make the routing tables just as ugly as IPv4????

I would say NAT66 with Site-local "private" addressing on the inside.

On the networks I've ran, I would never want to worry about renumbering just because of an ISP change and I am not thinking that GUA is the way to go.

Keep the internal network internal and only change your outside numberings when you need along with static NAT/NAT pools.

Am I missing something???


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Engel
Sent: Wednesday, March 31, 2010 9:56 AM
To: 'arin-ppml at arin.net'
Subject: Re: [arin-ppml] The role of NAT in IPv6

Owen Delong wrote:

> Actually, the places that most need to deploy IPv6 at this
> point being eye-ball ISPs and the public-facing portions of
> content and services providers, I don't think that NAT has
> been an actual barrier to adoption in either of those spaces.
> The vast majority of people calling for NAT66 are the
> enterprise interior, which is, IMHO, the least critical and
> least likely group to get on the IPv6 bandwagon quickly
> regardless of what is done to appease them.


Well, in addition to being an Enterprise...my company is also an ASP.... which I believe would qualify as a "content and services provider" under your definition.

So lets see, if I want to deploy IPv6 currently....

 - Huge transition costs

 - No support for tools I rely on every day to make MY environment work the way I want it.

 - Out of compliance with current regulatory standards.


Gee Whiz... where do I get to sign up for that?






Christopher Engel

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


From Lee at Dilkie.com  Thu Apr 15 10:50:58 2010
From: Lee at Dilkie.com (Lee Dilkie)
Date: Thu, 15 Apr 2010 10:50:58 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <21E4831D76704142BBAF6DC8F252904A0164AD6302@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
References: <mailman.833.1269897550.28982.arin-ppml@arin.net>	<F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA616@Skyhawk>
	<21E4831D76704142BBAF6DC8F252904A0164AD6302@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
Message-ID: <4BC727D2.6090700@Dilkie.com>



<http://www.fuelly.com/driver/dilkie/golf>

On 4/15/2010 10:27 AM, Gams, Matthew D wrote:
> I don't understand why everyone wants to go IPv6 with global addressing everywhere. And the solution to renumbering is getting organizations with their own blocks which will slowly make the routing tables just as ugly as IPv4????
>
> I would say NAT66 with Site-local "private" addressing on the inside.
>
> On the networks I've ran, I would never want to worry about renumbering just because of an ISP change and I am not thinking that GUA is the way to go.
>
> Keep the internal network internal and only change your outside numberings when you need along with static NAT/NAT pools.
>
> Am I missing something???
>   

yes. how does NAT66 handle protocols with addresses inside?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100415/a5fe092e/attachment.htm>

From ggiesen at akn.ca  Thu Apr 15 10:54:45 2010
From: ggiesen at akn.ca (Gary Giesen)
Date: Thu, 15 Apr 2010 10:54:45 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <21E4831D76704142BBAF6DC8F252904A0164AD6302@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
Message-ID: <C7ECA0F5.923F%ggiesen@akn.ca>

On 10-04-15 10:27 AM, "Gams, Matthew D" <Matthew.Gams at chartercom.com> wrote:

> I don't understand why everyone wants to go IPv6 with global addressing
> everywhere. And the solution to renumbering is getting organizations with
> their own blocks which will slowly make the routing tables just as ugly as
> IPv4????
> 
> I would say NAT66 with Site-local "private" addressing on the inside.
> 
> On the networks I've ran, I would never want to worry about renumbering just
> because of an ISP change and I am not thinking that GUA is the way to go.
> 
> Keep the internal network internal and only change your outside numberings
> when you need along with static NAT/NAT pools.
> 
> Am I missing something???

Yes, NAT is an ugly beast that we wish would disappear...

Since we have abundant globally unique addresses, and no equivalent to
RFC1918 in IPv6, it has reached the end of its usefulness...
> 
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf
> Of Chris Engel
> Sent: Wednesday, March 31, 2010 9:56 AM
> To: 'arin-ppml at arin.net'
> Subject: Re: [arin-ppml] The role of NAT in IPv6
> 
> Owen Delong wrote:
> 
>> Actually, the places that most need to deploy IPv6 at this
>> point being eye-ball ISPs and the public-facing portions of
>> content and services providers, I don't think that NAT has
>> been an actual barrier to adoption in either of those spaces.
>> The vast majority of people calling for NAT66 are the
>> enterprise interior, which is, IMHO, the least critical and
>> least likely group to get on the IPv6 bandwagon quickly
>> regardless of what is done to appease them.
> 
> 
> Well, in addition to being an Enterprise...my company is also an ASP.... which
> I believe would qualify as a "content and services provider" under your
> definition.
> 
> So lets see, if I want to deploy IPv6 currently....
> 
>  - Huge transition costs
> 
>  - No support for tools I rely on every day to make MY environment work the
> way I want it.
> 
>  - Out of compliance with current regulatory standards.
> 
> 
> Gee Whiz... where do I get to sign up for that?
> 
> 
> 
> 
> 
> 
> Christopher Engel
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From Matthew.Gams at chartercom.com  Thu Apr 15 11:21:50 2010
From: Matthew.Gams at chartercom.com (Gams, Matthew D)
Date: Thu, 15 Apr 2010 10:21:50 -0500
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <C7ECA0F5.923F%ggiesen@akn.ca>
References: <21E4831D76704142BBAF6DC8F252904A0164AD6302@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
	<C7ECA0F5.923F%ggiesen@akn.ca>
Message-ID: <21E4831D76704142BBAF6DC8F252904A0164AD6444@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>

This assumes that just because you access the Internet you should be globally routable. I know it's too late to debate addressing schemes as IPv6 is already here but just because you have an insanely large address pool doesn't mean every toaster needs to have a globally unique address.

I don't want NAT for security reasons as that is just the wrong model. I and that layer of abstraction between public and private resources. This is the same model used in just about every area you look. In the physical world and city addresses where multiple 5th Streets exist in different cities but you have state, city, zip to make the repeated address unique. This also occurs with computer memory etc. where the virtual address space is given independent of physical RAM and allows you to have more virtual RAM than physical.

As you might be able to tell I would have preferred a different approach than IPv6 altogether where the full IPv4 address space was used for private addressing and edge devices would have prefixes that made them unique based on geographic/country/ISP information. But anyway, I am not convinced that NAT should be abandoned...



-----Original Message-----
From: Gary Giesen [mailto:ggiesen at akn.ca] 
Sent: Thursday, April 15, 2010 9:55 AM
To: Gams, Matthew D; 'arin-ppml at arin.net'
Subject: Re: [arin-ppml] The role of NAT in IPv6

On 10-04-15 10:27 AM, "Gams, Matthew D" <Matthew.Gams at chartercom.com> wrote:

> I don't understand why everyone wants to go IPv6 with global addressing
> everywhere. And the solution to renumbering is getting organizations with
> their own blocks which will slowly make the routing tables just as ugly as
> IPv4????
> 
> I would say NAT66 with Site-local "private" addressing on the inside.
> 
> On the networks I've ran, I would never want to worry about renumbering just
> because of an ISP change and I am not thinking that GUA is the way to go.
> 
> Keep the internal network internal and only change your outside numberings
> when you need along with static NAT/NAT pools.
> 
> Am I missing something???

Yes, NAT is an ugly beast that we wish would disappear...

Since we have abundant globally unique addresses, and no equivalent to
RFC1918 in IPv6, it has reached the end of its usefulness...
> 
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf
> Of Chris Engel
> Sent: Wednesday, March 31, 2010 9:56 AM
> To: 'arin-ppml at arin.net'
> Subject: Re: [arin-ppml] The role of NAT in IPv6
> 
> Owen Delong wrote:
> 
>> Actually, the places that most need to deploy IPv6 at this
>> point being eye-ball ISPs and the public-facing portions of
>> content and services providers, I don't think that NAT has
>> been an actual barrier to adoption in either of those spaces.
>> The vast majority of people calling for NAT66 are the
>> enterprise interior, which is, IMHO, the least critical and
>> least likely group to get on the IPv6 bandwagon quickly
>> regardless of what is done to appease them.
> 
> 
> Well, in addition to being an Enterprise...my company is also an ASP.... which
> I believe would qualify as a "content and services provider" under your
> definition.
> 
> So lets see, if I want to deploy IPv6 currently....
> 
>  - Huge transition costs
> 
>  - No support for tools I rely on every day to make MY environment work the
> way I want it.
> 
>  - Out of compliance with current regulatory standards.
> 
> 
> Gee Whiz... where do I get to sign up for that?
> 
> 
> 
> 
> 
> 
> Christopher Engel
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From ggiesen at akn.ca  Thu Apr 15 11:39:38 2010
From: ggiesen at akn.ca (Gary T. Giesen)
Date: Thu, 15 Apr 2010 11:39:38 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <21E4831D76704142BBAF6DC8F252904A0164AD6444@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
References: <21E4831D76704142BBAF6DC8F252904A0164AD6302@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
	<C7ECA0F5.923F%ggiesen@akn.ca>
	<21E4831D76704142BBAF6DC8F252904A0164AD6444@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
Message-ID: <1271345978.5224.84.camel@ggiesen-workstation.netsurf.net>

On Thu, 2010-04-15 at 11:21 -0400, Gams, Matthew D wrote:
> This assumes that just because you access the Internet you should be globally routable. I know it's too late to debate addressing schemes as IPv6 is already here but just because you have an insanely large address pool doesn't mean every toaster needs to have a globally unique address.
> 
> I don't want NAT for security reasons as that is just the wrong model. I and that layer of abstraction between public and private resources. This is the same model used in just about every area you look. In the physical world and city addresses where multiple 5th Streets exist in different cities but you have state, city, zip to make the repeated address unique. This also occurs with computer memory etc. where the virtual address space is given independent of physical RAM and allows you to have more virtual RAM than physical.
> 
We actually have a pretty close analogue to this. The last /64 is the
"street address" which is repeated over and over, and the first /64 is
the combination of "city, state, country" just happens to be broken up
along more arbitrary lines (a group of /32's are assigned to ARIN as
your "region", and the individual /32's or /48's are assigned to your
ISP (or directly to you). It's really the same model. We're not
operating on the layer 2 model where it's a completely flat addressing
scheme....

GG

> As you might be able to tell I would have preferred a different approach than IPv6 altogether where the full IPv4 address space was used for private addressing and edge devices would have prefixes that made them unique based on geographic/country/ISP information. But anyway, I am not convinced that NAT should be abandoned...
> 
> 
> 
> -----Original Message-----
> From: Gary Giesen [mailto:ggiesen at akn.ca] 
> Sent: Thursday, April 15, 2010 9:55 AM
> To: Gams, Matthew D; 'arin-ppml at arin.net'
> Subject: Re: [arin-ppml] The role of NAT in IPv6
> 
> On 10-04-15 10:27 AM, "Gams, Matthew D" <Matthew.Gams at chartercom.com> wrote:
> 
> > I don't understand why everyone wants to go IPv6 with global addressing
> > everywhere. And the solution to renumbering is getting organizations with
> > their own blocks which will slowly make the routing tables just as ugly as
> > IPv4????
> > 
> > I would say NAT66 with Site-local "private" addressing on the inside.
> > 
> > On the networks I've ran, I would never want to worry about renumbering just
> > because of an ISP change and I am not thinking that GUA is the way to go.
> > 
> > Keep the internal network internal and only change your outside numberings
> > when you need along with static NAT/NAT pools.
> > 
> > Am I missing something???
> 
> Yes, NAT is an ugly beast that we wish would disappear...
> 
> Since we have abundant globally unique addresses, and no equivalent to
> RFC1918 in IPv6, it has reached the end of its usefulness...
> > 
> > 
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf
> > Of Chris Engel
> > Sent: Wednesday, March 31, 2010 9:56 AM
> > To: 'arin-ppml at arin.net'
> > Subject: Re: [arin-ppml] The role of NAT in IPv6
> > 
> > Owen Delong wrote:
> > 
> >> Actually, the places that most need to deploy IPv6 at this
> >> point being eye-ball ISPs and the public-facing portions of
> >> content and services providers, I don't think that NAT has
> >> been an actual barrier to adoption in either of those spaces.
> >> The vast majority of people calling for NAT66 are the
> >> enterprise interior, which is, IMHO, the least critical and
> >> least likely group to get on the IPv6 bandwagon quickly
> >> regardless of what is done to appease them.
> > 
> > 
> > Well, in addition to being an Enterprise...my company is also an ASP.... which
> > I believe would qualify as a "content and services provider" under your
> > definition.
> > 
> > So lets see, if I want to deploy IPv6 currently....
> > 
> >  - Huge transition costs
> > 
> >  - No support for tools I rely on every day to make MY environment work the
> > way I want it.
> > 
> >  - Out of compliance with current regulatory standards.
> > 
> > 
> > Gee Whiz... where do I get to sign up for that?
> > 
> > 
> > 
> > 
> > 
> > 
> > Christopher Engel
> > 
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> 
> 
> E-MAIL CONFIDENTIALITY NOTICE: 
> 
>  
> 
> 
> 
> 
> 
> The contents of this e-mail message and 
> any attachments are intended solely for the 
> addressee(s) and may contain confidential 
> and/or legally privileged information. If you 
> are not the intended recipient of this message 
> or if this message has been addressed to you 
> in error, please immediately alert the sender
>  by reply e-mail and then delete this message 
> and any attachments. If you are not the 
> intended recipient, you are notified that 
> any use, dissemination, distribution, copying, 
> or storage of this message or any attachment 
> is strictly prohibited.
> 
> 
> 
> 
> 
> 
> 
> 



From trejrco at gmail.com  Thu Apr 15 11:47:14 2010
From: trejrco at gmail.com (TJ)
Date: Thu, 15 Apr 2010 11:47:14 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <21E4831D76704142BBAF6DC8F252904A0164AD6444@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
References: <21E4831D76704142BBAF6DC8F252904A0164AD6302@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
	<C7ECA0F5.923F%ggiesen@akn.ca>
	<21E4831D76704142BBAF6DC8F252904A0164AD6444@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
Message-ID: <x2y71bfd60c1004150847x18168c8cq3905494789b7cee@mail.gmail.com>

On Thu, Apr 15, 2010 at 11:21, Gams, Matthew D
<Matthew.Gams at chartercom.com>wrote:

> This assumes that just because you access the Internet you should be
> globally routable. I know it's too late to debate addressing schemes as IPv6
> is already here but just because you have an insanely large address pool
> doesn't mean every toaster needs to have a globally unique address.
>

Agreed, it doesn't NEED a GUA.  However, if we live in a world where it had
one, do we gain anything?  I'd argue yes ...
And, absent the address shortage concern - if something could add value, at
no real cost, why not do it.

The conversation over "'But NAT with static rules and FW permits' is the
same as 'GUAs with static FW permits'" is incorrect.
The simplest example - two devices, both listening for the same port and
client SW that will only (readily) talk to that port.
Is that surmountable sans IPv6?  Yes.
But is it easier, more efficient, etc. with IPv6?  Yes.

(Even more-so as certain "deperimeterization efforts progress .. but that is
an entirely separate conversation, for a different mailing list!)

I don't want NAT for security reasons as that is just the wrong model. I and
> that layer of abstraction between public and private resources. This is the
> same model used in just about every area you look. In the physical world and
> city addresses where multiple 5th Streets exist in different cities but you
> have state, city, zip to make the repeated address unique. This also occurs
> with computer memory etc. where the virtual address space is given
> independent of physical RAM and allows you to have more virtual RAM than
> physical.
>
> As you might be able to tell I would have preferred a different approach
> than IPv6 altogether where the full IPv4 address space was used for private
> addressing and edge devices would have prefixes that made them unique based
> on geographic/country/ISP information. But anyway, I am not convinced that
> NAT should be abandoned...


And don't get me wrong - I am not as vehemently Anti-NAT as some ... I just
hope that even if "NAT66" becomes a standard, it does  not become the
standard way to deploy IPv6 :).


Cheers,
/TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100415/3cc9142f/attachment.htm>

From Donald.Smith at qwest.com  Thu Apr 15 11:50:46 2010
From: Donald.Smith at qwest.com (Smith, Donald)
Date: Thu, 15 Apr 2010 09:50:46 -0600
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <21E4831D76704142BBAF6DC8F252904A0164AD6302@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
References: <mailman.833.1269897550.28982.arin-ppml@arin.net>
	<F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA616@Skyhawk>
	<21E4831D76704142BBAF6DC8F252904A0164AD6302@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
Message-ID: <B01905DA0C7CDC478F42870679DF0F1007A3E98D0B@qtdenexmbm24.AD.QINTRA.COM>

+1 (as in I agree with Matthew)!


(coffee != sleep) & (!coffee == sleep)
Donald.Smith at qwest.com gcia

> -----Original Message-----
> From: arin-ppml-bounces at arin.net
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Gams, Matthew D
> Sent: Thursday, April 15, 2010 8:28 AM
> To: 'arin-ppml at arin.net'
> Subject: Re: [arin-ppml] The role of NAT in IPv6
>
> I don't understand why everyone wants to go IPv6 with global
> addressing everywhere. And the solution to renumbering is
> getting organizations with their own blocks which will slowly
> make the routing tables just as ugly as IPv4????
>
> I would say NAT66 with Site-local "private" addressing on the inside.
>
> On the networks I've ran, I would never want to worry about
> renumbering just because of an ISP change and I am not
> thinking that GUA is the way to go.
>
> Keep the internal network internal and only change your
> outside numberings when you need along with static NAT/NAT pools.
>
> Am I missing something???
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Engel
> Sent: Wednesday, March 31, 2010 9:56 AM
> To: 'arin-ppml at arin.net'
> Subject: Re: [arin-ppml] The role of NAT in IPv6
>
> Owen Delong wrote:
>
> > Actually, the places that most need to deploy IPv6 at this
> > point being eye-ball ISPs and the public-facing portions of
> > content and services providers, I don't think that NAT has
> > been an actual barrier to adoption in either of those spaces.
> > The vast majority of people calling for NAT66 are the
> > enterprise interior, which is, IMHO, the least critical and
> > least likely group to get on the IPv6 bandwagon quickly
> > regardless of what is done to appease them.
>
>
> Well, in addition to being an Enterprise...my company is also
> an ASP.... which I believe would qualify as a "content and
> services provider" under your definition.
>
> So lets see, if I want to deploy IPv6 currently....
>
>  - Huge transition costs
>
>  - No support for tools I rely on every day to make MY
> environment work the way I want it.
>
>  - Out of compliance with current regulatory standards.
>
>
> Gee Whiz... where do I get to sign up for that?
>
>
>
>
>
>
> Christopher Engel
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.


From Matthew.Gams at chartercom.com  Thu Apr 15 11:52:20 2010
From: Matthew.Gams at chartercom.com (Gams, Matthew D)
Date: Thu, 15 Apr 2010 10:52:20 -0500
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <1271345978.5224.84.camel@ggiesen-workstation.netsurf.net>
References: <21E4831D76704142BBAF6DC8F252904A0164AD6302@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
	<C7ECA0F5.923F%ggiesen@akn.ca>
	<21E4831D76704142BBAF6DC8F252904A0164AD6444@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
	<1271345978.5224.84.camel@ggiesen-workstation.netsurf.net>
Message-ID: <21E4831D76704142BBAF6DC8F252904A0164AD64E3@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>



> -----Original Message-----
> From: Gary T. Giesen [mailto:ggiesen at akn.ca]
> Sent: Thursday, April 15, 2010 10:40 AM
> To: Gams, Matthew D
> Cc: 'arin-ppml at arin.net'
> Subject: RE: [arin-ppml] The role of NAT in IPv6
> 
> On Thu, 2010-04-15 at 11:21 -0400, Gams, Matthew D wrote:
> > This assumes that just because you access the Internet you should be
> globally routable. I know it's too late to debate addressing schemes as
> IPv6 is already here but just because you have an insanely large address
> pool doesn't mean every toaster needs to have a globally unique address.
> >
> > I don't want NAT for security reasons as that is just the wrong model.
> I and that layer of abstraction between public and private resources.
> This is the same model used in just about every area you look. In the
> physical world and city addresses where multiple 5th Streets exist in
> different cities but you have state, city, zip to make the repeated
> address unique. This also occurs with computer memory etc. where the
> virtual address space is given independent of physical RAM and allows
> you to have more virtual RAM than physical.
> >
> We actually have a pretty close analogue to this. The last /64 is the
> "street address" which is repeated over and over, and the first /64 is
> the combination of "city, state, country" just happens to be broken up
> along more arbitrary lines (a group of /32's are assigned to ARIN as
> your "region", and the individual /32's or /48's are assigned to your
> ISP (or directly to you). It's really the same model. We're not
> operating on the layer 2 model where it's a completely flat addressing
> scheme....
>

Close is the key word. It is a flat address which is then being logically broken down. A true hierarchical model (closer to the OSI addressing) would have those layers built-in and be able to take them out when not needed. Also, the IPv6 model breaks down as you allow exceptions with bigger organizations getting direct allocations.

I like the level concept in IS-IS and wish IPv6 would have taken the concept and created something a bit different. Level-0, 1, 2, 3, and 4. We could have still ended up with 128-bit addressing if needed (or more) and been much more efficient. Organizations would still use their comfortable 32-bit IPv4 addresses and only the network "gods" would know anything about the larger space available. During transition RFC1918 would be kept intact but eventually DNS would respond with the updated prefixes to allow global routing of the new blocks and in theory the whole 32-bit address space could be used internally.

Routers would only know about the level are configured for with only Level-4 being the biggest back-bone routers that know the whole structure.

Oh well, maybe in another reality...  :)

> GG
>
> > As you might be able to tell I would have preferred a different
> approach than IPv6 altogether where the full IPv4 address space was used
> for private addressing and edge devices would have prefixes that made
> them unique based on geographic/country/ISP information. But anyway, I
> am not convinced that NAT should be abandoned...
> >
> >
> >
> > -----Original Message-----
> > From: Gary Giesen [mailto:ggiesen at akn.ca]
> > Sent: Thursday, April 15, 2010 9:55 AM
> > To: Gams, Matthew D; 'arin-ppml at arin.net'
> > Subject: Re: [arin-ppml] The role of NAT in IPv6
> >
> > On 10-04-15 10:27 AM, "Gams, Matthew D" <Matthew.Gams at chartercom.com>
> wrote:
> >
> > > I don't understand why everyone wants to go IPv6 with global
> addressing
> > > everywhere. And the solution to renumbering is getting organizations
> with
> > > their own blocks which will slowly make the routing tables just as
> ugly as
> > > IPv4????
> > >
> > > I would say NAT66 with Site-local "private" addressing on the
> inside.
> > >
> > > On the networks I've ran, I would never want to worry about
> renumbering just
> > > because of an ISP change and I am not thinking that GUA is the way
> to go.
> > >
> > > Keep the internal network internal and only change your outside
> numberings
> > > when you need along with static NAT/NAT pools.
> > >
> > > Am I missing something???
> >
> > Yes, NAT is an ugly beast that we wish would disappear...
> >
> > Since we have abundant globally unique addresses, and no equivalent to
> > RFC1918 in IPv6, it has reached the end of its usefulness...
> > >
> > >
> > > -----Original Message-----
> > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> On Behalf
> > > Of Chris Engel
> > > Sent: Wednesday, March 31, 2010 9:56 AM
> > > To: 'arin-ppml at arin.net'
> > > Subject: Re: [arin-ppml] The role of NAT in IPv6
> > >
> > > Owen Delong wrote:
> > >
> > >> Actually, the places that most need to deploy IPv6 at this
> > >> point being eye-ball ISPs and the public-facing portions of
> > >> content and services providers, I don't think that NAT has
> > >> been an actual barrier to adoption in either of those spaces.
> > >> The vast majority of people calling for NAT66 are the
> > >> enterprise interior, which is, IMHO, the least critical and
> > >> least likely group to get on the IPv6 bandwagon quickly
> > >> regardless of what is done to appease them.
> > >
> > >
> > > Well, in addition to being an Enterprise...my company is also an
> ASP.... which
> > > I believe would qualify as a "content and services provider" under
> your
> > > definition.
> > >
> > > So lets see, if I want to deploy IPv6 currently....
> > >
> > >  - Huge transition costs
> > >
> > >  - No support for tools I rely on every day to make MY environment
> work the
> > > way I want it.
> > >
> > >  - Out of compliance with current regulatory standards.
> > >
> > >
> > > Gee Whiz... where do I get to sign up for that?
> > >
> > >
> > >
> > >
> > >
> > >
> > > Christopher Engel
> > >
> > > _______________________________________________
> > > PPML
> > > You are receiving this message because you are subscribed to
> > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact info at arin.net if you experience any issues.
> > > _______________________________________________
> > > PPML
> > > You are receiving this message because you are subscribed to
> > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact info at arin.net if you experience any issues.
> >
> >
> > E-MAIL CONFIDENTIALITY NOTICE:
> >
> >
> >
> >
> >
> >
> >
> > The contents of this e-mail message and
> > any attachments are intended solely for the
> > addressee(s) and may contain confidential
> > and/or legally privileged information. If you
> > are not the intended recipient of this message
> > or if this message has been addressed to you
> > in error, please immediately alert the sender
> >  by reply e-mail and then delete this message
> > and any attachments. If you are not the
> > intended recipient, you are notified that
> > any use, dissemination, distribution, copying,
> > or storage of this message or any attachment
> > is strictly prohibited.
> >
> >
> >
> >
> >
> >
> >
> >



From trejrco at gmail.com  Thu Apr 15 12:09:58 2010
From: trejrco at gmail.com (TJ)
Date: Thu, 15 Apr 2010 12:09:58 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <21E4831D76704142BBAF6DC8F252904A0164AD64E3@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
References: <21E4831D76704142BBAF6DC8F252904A0164AD6302@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
	<C7ECA0F5.923F%ggiesen@akn.ca>
	<21E4831D76704142BBAF6DC8F252904A0164AD6444@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
	<1271345978.5224.84.camel@ggiesen-workstation.netsurf.net> 
	<21E4831D76704142BBAF6DC8F252904A0164AD64E3@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
Message-ID: <m2j71bfd60c1004150909qfa817d5wea24ec88ac0b1c80@mail.gmail.com>

>
> > -----Original Message-----
> > From: Gary T. Giesen [mailto:ggiesen at akn.ca]
> > Sent: Thursday, April 15, 2010 10:40 AM
> > To: Gams, Matthew D
> > Cc: 'arin-ppml at arin.net'
> > Subject: RE: [arin-ppml] The role of NAT in IPv6
> >
> > On Thu, 2010-04-15 at 11:21 -0400, Gams, Matthew D wrote:
>
Close is the key word. It is a flat address which is then being logically
> broken down. A true hierarchical model (closer to the OSI addressing) would
> have those layers built-in and be able to take them out when not needed.
> Also, the IPv6 model breaks down as you allow exceptions with bigger
> organizations getting direct allocations.
>
> I like the level concept in IS-IS and wish IPv6 would have taken the
> concept and created something a bit different. Level-0, 1, 2, 3, and 4. We
> could have still ended up with 128-bit addressing if needed (or more) and
> been much more efficient. Organizations would still use their comfortable
> 32-bit IPv4 addresses and only the network "gods" would know anything about
> the larger space available. During transition RFC1918 would be kept intact
> but eventually DNS would respond with the updated prefixes to allow global
> routing of the new blocks and in theory the whole 32-bit address space could
> be used internally.
>
> Routers would only know about the level are configured for with only
> Level-4 being the biggest back-bone routers that know the whole structure.
>
> Oh well, maybe in another reality...  :)


That model works for edge nodes accessing centrally located/managed
services, client-server style.
Scaling it to end-to-end / peer-to-peer operations is either
really kludgey at Layer3 or relies increasingly on Layer7'ish helpers.
(In some cases that model breaks even sooner - there are networks where a
total of 4.3Billion addresses may not be enough by the time you divie it up
in a hierarchical fashion ... requiring yet more layers of duct tape
and/or bailing wire.)

IMHO, if it is a network problem it should almost always be solved at the
network layer.
Let's get that part fixed first, and let's see where we can make it with
that infrastructure ...


/TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100415/44a15fda/attachment.htm>

From Matthew.Gams at chartercom.com  Thu Apr 15 12:21:52 2010
From: Matthew.Gams at chartercom.com (Gams, Matthew D)
Date: Thu, 15 Apr 2010 11:21:52 -0500
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <m2j71bfd60c1004150909qfa817d5wea24ec88ac0b1c80@mail.gmail.com>
References: <21E4831D76704142BBAF6DC8F252904A0164AD6302@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
	<C7ECA0F5.923F%ggiesen@akn.ca>
	<21E4831D76704142BBAF6DC8F252904A0164AD6444@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
	<1271345978.5224.84.camel@ggiesen-workstation.netsurf.net>
	<21E4831D76704142BBAF6DC8F252904A0164AD64E3@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
	<m2j71bfd60c1004150909qfa817d5wea24ec88ac0b1c80@mail.gmail.com>
Message-ID: <21E4831D76704142BBAF6DC8F252904A0164AD6584@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>

There would be no need for upper levels to help out. Only during the transition would there be IPv4 only clients. They would still talk to the globally unique IPv4 addresses. However, once upgraded to IPv-X they would have the ability to use the other level prefixes to communicate. Biggest IPv6 problem is the lack of compatibility with IPv4.

Anyway, since we have IPv6 my main point is that keeping your private network separate from the public is more a matter of minimizing changes to your internal LAN during whatever need comes up.



From: TJ [mailto:trejrco at gmail.com]
Sent: Thursday, April 15, 2010 11:10 AM
To: Gams, Matthew D
Cc: Gary T. Giesen; arin-ppml at arin.net
Subject: Re: [arin-ppml] The role of NAT in IPv6

> -----Original Message-----
> From: Gary T. Giesen [mailto:ggiesen at akn.ca<mailto:ggiesen at akn.ca>]
> Sent: Thursday, April 15, 2010 10:40 AM
> To: Gams, Matthew D
> Cc: 'arin-ppml at arin.net<mailto:arin-ppml at arin.net>'
> Subject: RE: [arin-ppml] The role of NAT in IPv6
>
> On Thu, 2010-04-15 at 11:21 -0400, Gams, Matthew D wrote:
Close is the key word. It is a flat address which is then being logically broken down. A true hierarchical model (closer to the OSI addressing) would have those layers built-in and be able to take them out when not needed. Also, the IPv6 model breaks down as you allow exceptions with bigger organizations getting direct allocations.

I like the level concept in IS-IS and wish IPv6 would have taken the concept and created something a bit different. Level-0, 1, 2, 3, and 4. We could have still ended up with 128-bit addressing if needed (or more) and been much more efficient. Organizations would still use their comfortable 32-bit IPv4 addresses and only the network "gods" would know anything about the larger space available. During transition RFC1918 would be kept intact but eventually DNS would respond with the updated prefixes to allow global routing of the new blocks and in theory the whole 32-bit address space could be used internally.

Routers would only know about the level are configured for with only Level-4 being the biggest back-bone routers that know the whole structure.

Oh well, maybe in another reality...  :)

That model works for edge nodes accessing centrally located/managed services, client-server style.
Scaling it to end-to-end / peer-to-peer operations is either really kludgey at Layer3 or relies increasingly on Layer7'ish helpers.
(In some cases that model breaks even sooner - there are networks where a total of 4.3Billion addresses may not be enough by the time you divie it up in a hierarchical fashion ... requiring yet more layers of duct tape and/or bailing wire.)

IMHO, if it is a network problem it should almost always be solved at the network layer.
Let's get that part fixed first, and let's see where we can make it with that infrastructure ...


/TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100415/31fa1f16/attachment.htm>

From farmer at umn.edu  Thu Apr 15 12:48:37 2010
From: farmer at umn.edu (David Farmer)
Date: Thu, 15 Apr 2010 11:48:37 -0500
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <C7ECA0F5.923F%ggiesen@akn.ca>
References: <C7ECA0F5.923F%ggiesen@akn.ca>
Message-ID: <4BC74365.4080607@umn.edu>

Gary Giesen wrote:

> Yes, NAT is an ugly beast that we wish would disappear...

Yes, NAT is ugly, it would be nice to leave it behind in the IPv4 world.

However, there are other equally ugly problems that IPv6 has not solved 
and are not being left behind in IPv4 world.

- IPv6 doesn't fundamentally solve the routing table growth problem, 
large initial allocation will help some, but it doesn't solve it

- IPv6 doesn't eliminate the renumbering problem, it is not as bad, but 
again it is not solved

- IPv6 doesn't eliminate the motivation to do NAT, I believe there 
should be less and more people should have other options, but it doesn't 
eliminate it

I think NAT is ugly, heck I think it is an abomination, but I think 
telling other people how to run there network is much more ugly thing 
than NAT.  And how much ever I dislike NAT, it has been an effective way 
to run a network for a lot of people.  How effective have you been in 
telling other people how to run (or not run) there network?

> Since we have abundant globally unique addresses, and no equivalent to
> RFC1918 in IPv6, it has reached the end of its usefulness...

Yes, there is abundant address space in IPv6.  But, please read RFC 
4193, which is fundamentally the IPv6 replacement for RFC 1918 in IPv4. 
  Since IPv6 has abundant address space it is possible to provide 
private address space in a much better ways than the simple solution 
chosen for RFC 1918.  So unfortunately, no NAT has not reached the end 
of its usefulness at least for everyone.

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


From tedm at ipinc.net  Thu Apr 15 13:22:03 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Thu, 15 Apr 2010 10:22:03 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <4BC63FD7.40903@ibctech.ca>
References: <28E139F46D45AF49A31950F88C49745805C3F7F3@E03MVZ2-UKDY.domain1.systemhost.net>	<4BC62C0B.50904@ibctech.ca>
	<4BC63FD7.40903@ibctech.ca>
Message-ID: <4BC74B3B.1000805@ipinc.net>



On 4/14/2010 3:21 PM, Steve Bertrand wrote:
> On 2010.04.14 16:56, Steve Bertrand wrote:
>> On 2010.04.14 16:51, michael.dillon at bt.com wrote:
>>>
>>>> There are these things called "looking glasses" you can find
>>>> them at traceroute.org and when you log in to them you will
>>>> see that BGP propagation is pretty much world-wide.  It's a
>>>> pretty amazing thing, this Internet network.
>>>
>>> Oh yeah? And where might one find these "looking glass" thingies?
>>
>> Do these count?:
>>
>> acct-dev: ISP % telnet route-views.routeviews.org
>> Trying 2001:468:d01:33::80df:3367...
>> Connected to route-views.routeviews.org.
>> Escape character is '^]'.
>
> To fix my own post, I believe that I implied that routeviews.org was v4
> only when I said this:
>
>> or, for v6:
>>
>> http://www.sixxs.net/tools/grh/lg/
>
> That isn't the case. route-views.routeviews.org provides both v4 and v6
> (as is probably evident in my vty connection above).
>
> What I meant to say was:
>
> or, *web-based* for v6:
>
> http://www.sixxs.net/tools/grh/lg/
>
> Point is, there are still very, very reliable looking glasses. Kudos to
> you all who maintain them.
>

It is trivial to modify the publically accessible looking glass code to
support IPv6.  I did:

http://whois.ipinc.net/cgi-bin/lg.pl

anyone interested can e-mail me for diffs.

Ted

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


From tedm at ipinc.net  Thu Apr 15 13:24:16 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Thu, 15 Apr 2010 10:24:16 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5FCA516@SUEX07-MBX-04.ad.syr.edu>
References: <20100413172714.M35473@fast-serv.com><4BC4B1B6.7060804@ipinc.net>	<A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>	<4BC62352.2090202@rollernet.us>	<75822E125BCB994F8446858C4B19F0D701D5FCA511@SUEX07-MBX-04.ad.syr.edu>
	<4BC62E81.3040600@ipinc.net>
	<75822E125BCB994F8446858C4B19F0D701D5FCA516@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4BC74BC0.4000606@ipinc.net>

I'm basing my suspicion that years ago more didn't take a
full table mainly on my gut feeling, based on 3 things,
first that most of the BGP info and examples out there
that discuss partial tables date from years ago, second that
routers years ago had a lot less "uumph" (I've read postings
in the Usenet archives that state that people once did a
full BGP table for the Internet on a Cisco 2501, with filtering,
if you can imagine) and it appears that during the early
"commercial"  growth of the Internet during the 1995-1997
period that table growth outstripped the speed the router
vendors to come out with routers with more ram, and third
that the RADb project wound down during the early 2000s -
the only explanation for that is people didn't have to have it.

Ted

On 4/14/2010 2:09 PM, Milton L Mueller wrote:
> Thanks, Ted. Yet another interesting economic trade-off emerges. How would one get a bead on how many do and do not take a full table and how that ratio has changed over time?
>
>> I think that years ago a lot more didn't take a full table.  But
>> dram is cheaper than paying a network admin to maintain a filter
>> table and so many sites nowadays haven't seemed to have heard
>
> Milton Mueller
> Professor, Syracuse University School of Information Studies
> XS4All Professor, Delft University of Technology
> ------------------------------
> Internet Governance Project:
> http://internetgovernance.org
>
>


From Lee at Dilkie.com  Thu Apr 15 13:25:57 2010
From: Lee at Dilkie.com (Lee Dilkie)
Date: Thu, 15 Apr 2010 13:25:57 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <21E4831D76704142BBAF6DC8F252904A0164AD6444@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
References: <21E4831D76704142BBAF6DC8F252904A0164AD6302@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>	<C7ECA0F5.923F%ggiesen@akn.ca>
	<21E4831D76704142BBAF6DC8F252904A0164AD6444@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
Message-ID: <4BC74C25.5040604@Dilkie.com>



<http://www.fuelly.com/driver/dilkie/golf>

On 4/15/2010 11:21 AM, Gams, Matthew D wrote:
> This assumes that just because you access the Internet you should be globally routable. I know it's too late to debate addressing schemes as IPv6 is already here but just because you have an insanely large address pool doesn't mean every toaster needs to have a globally unique address.
>
> I don't want NAT for security reasons as that is just the wrong model. I and that layer of abstraction between public and private resources. This is the same model used in just about every area you look. In the physical world and city addresses where multiple 5th Streets exist in different cities but you have state, city, zip to make the repeated address unique. This also occurs with computer memory etc. where the virtual address space is given independent of physical RAM and allows you to have more virtual RAM than physical.
>
> As you might be able to tell I would have preferred a different approach than IPv6 altogether where the full IPv4 address space was used for private addressing and edge devices would have prefixes that made them unique based on geographic/country/ISP information. But anyway, I am not convinced that NAT should be abandoned...
>   

And tell me, do you just put "5th street" as your return address on
letters or are you aware of your globally unique mailing address?

Because I *think* you do know your globally unique address and that is
what you give out to folks whom want to mail things to you. And why
should the electronic world be any different. All sorts of communication
protocols have a need to "give out" their address so they can be reached
at a later time.

-lee

>
>
> -----Original Message-----
> From: Gary Giesen [mailto:ggiesen at akn.ca] 
> Sent: Thursday, April 15, 2010 9:55 AM
> To: Gams, Matthew D; 'arin-ppml at arin.net'
> Subject: Re: [arin-ppml] The role of NAT in IPv6
>
> On 10-04-15 10:27 AM, "Gams, Matthew D" <Matthew.Gams at chartercom.com> wrote:
>
>   
>> I don't understand why everyone wants to go IPv6 with global addressing
>> everywhere. And the solution to renumbering is getting organizations with
>> their own blocks which will slowly make the routing tables just as ugly as
>> IPv4????
>>
>> I would say NAT66 with Site-local "private" addressing on the inside.
>>
>> On the networks I've ran, I would never want to worry about renumbering just
>> because of an ISP change and I am not thinking that GUA is the way to go.
>>
>> Keep the internal network internal and only change your outside numberings
>> when you need along with static NAT/NAT pools.
>>
>> Am I missing something???
>>     
> Yes, NAT is an ugly beast that we wish would disappear...
>
> Since we have abundant globally unique addresses, and no equivalent to
> RFC1918 in IPv6, it has reached the end of its usefulness...
>   
>>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf
>> Of Chris Engel
>> Sent: Wednesday, March 31, 2010 9:56 AM
>> To: 'arin-ppml at arin.net'
>> Subject: Re: [arin-ppml] The role of NAT in IPv6
>>
>> Owen Delong wrote:
>>
>>     
>>> Actually, the places that most need to deploy IPv6 at this
>>> point being eye-ball ISPs and the public-facing portions of
>>> content and services providers, I don't think that NAT has
>>> been an actual barrier to adoption in either of those spaces.
>>> The vast majority of people calling for NAT66 are the
>>> enterprise interior, which is, IMHO, the least critical and
>>> least likely group to get on the IPv6 bandwagon quickly
>>> regardless of what is done to appease them.
>>>       
>>
>> Well, in addition to being an Enterprise...my company is also an ASP.... which
>> I believe would qualify as a "content and services provider" under your
>> definition.
>>
>> So lets see, if I want to deploy IPv6 currently....
>>
>>  - Huge transition costs
>>
>>  - No support for tools I rely on every day to make MY environment work the
>> way I want it.
>>
>>  - Out of compliance with current regulatory standards.
>>
>>
>> Gee Whiz... where do I get to sign up for that?
>>
>>
>>
>>
>>
>>
>> Christopher Engel
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>     
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100415/17b97999/attachment.htm>

From tedm at ipinc.net  Thu Apr 15 13:26:47 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Thu, 15 Apr 2010 10:26:47 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5FCA522@SUEX07-MBX-04.ad.syr.edu>
References: <20100413172714.M35473@fast-serv.com><4BC4B1B6.7060804@ipinc.net>	<A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>	<4BC62352.2090202@rollernet.us>	<75822E125BCB994F8446858C4B19F0D701D5FCA511@SUEX07-MBX-04.ad.syr.edu>	<4BC62E81.3040600@ipinc.net>	<75822E125BCB994F8446858C4B19F0D701D5FCA516@SUEX07-MBX-04.ad.syr.edu>	<4BC63FB7.5000404@umn.edu>
	<75822E125BCB994F8446858C4B19F0D701D5FCA522@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4BC74C57.9010602@ipinc.net>



On 4/14/2010 3:39 PM, Milton L Mueller wrote:
> Thanks. Real data. Seems like a useful contribution to the discussion. Not sure why the questions leading to this point generated such hostility, nor why it had to be preambled with "snarky" stuff.
>
> So the "every router" statement has now dwindled to "most large ISP routers and about half of small ISP routers, which together compose about 10% of the world's routers." (Could be a misreading of the data because we don't know whether Randy's #tested is representative of the proportion in the total population.)
>

Ah, yes, but without the routers in that 10% we wouldn't have
an Internet to even be discussing.  They are more important
than the rest of the 90%.

Ted

PS  If you include the small consumer routers (Linksys, etc.)
then 10% is probably 9.9999999% too high.

> And the interpretation you draw, which I agree with:
>
>> those that add prefixes to the DFZ are probably not sharing
>> equally in the costs associated with the additional prefixes
>
> Yeah, we all knew that, but it is better to have a finer understanding of the specific disjunction in the distribution of costs and benefits, which is well known at least in my field as the motor of policy conflict and change...this could lead to a better understanding of how the associated tragedy of the commons has a specific structure and dynamic and what policy measures would best address it.
>
> --MM
>
>> -----Original Message-----
>>
>>
>> 		     # tested 	default 	default-free 	mixed
>> stub 		24,224 	77.1% 	19.3% 		3.6%
>> small ISP 	1,307 	44.5% 	42.2% 		13.3%
>> large ISP 	246 		17.1% 	60.6% 		22.3%
>>
>> You could probably come up with some kind of model to create an
>> estimate of how many routers that represents.
>>
>> When I look at this data it seem to me that it supports the general
>> hypothesis those that add prefixes to the DFZ are probably not sharing
>> equally in the costs associated with the additional prefixes.
>>
>> Whoops, there she Blow......
>>
>> :)
>>
>> --
>> ===============================================
>> David Farmer               Email:farmer at umn.edu
>> Networking&  Telecommunication Services
>> Office of Information Technology
>> University of Minnesota
>> 2218 University Ave SE	    Phone: 612-626-0815
>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>> ===============================================
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From Matthew.Gams at chartercom.com  Thu Apr 15 13:30:30 2010
From: Matthew.Gams at chartercom.com (Gams, Matthew D)
Date: Thu, 15 Apr 2010 12:30:30 -0500
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <4BC74C25.5040604@Dilkie.com>
References: <21E4831D76704142BBAF6DC8F252904A0164AD6302@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
	<C7ECA0F5.923F%ggiesen@akn.ca>
	<21E4831D76704142BBAF6DC8F252904A0164AD6444@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
	<4BC74C25.5040604@Dilkie.com>
Message-ID: <21E4831D76704142BBAF6DC8F252904A0164B9E746@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>



From: Lee Dilkie [mailto:Lee at Dilkie.com]
Sent: Thursday, April 15, 2010 12:26 PM
To: Gams, Matthew D
Cc: Gary Giesen; 'arin-ppml at arin.net'
Subject: Re: [arin-ppml] The role of NAT in IPv6



<http://www.fuelly.com/driver/dilkie/golf>

On 4/15/2010 11:21 AM, Gams, Matthew D wrote:

This assumes that just because you access the Internet you should be globally routable. I know it's too late to debate addressing schemes as IPv6 is already here but just because you have an insanely large address pool doesn't mean every toaster needs to have a globally unique address.



I don't want NAT for security reasons as that is just the wrong model. I and that layer of abstraction between public and private resources. This is the same model used in just about every area you look. In the physical world and city addresses where multiple 5th Streets exist in different cities but you have state, city, zip to make the repeated address unique. This also occurs with computer memory etc. where the virtual address space is given independent of physical RAM and allows you to have more virtual RAM than physical.



As you might be able to tell I would have preferred a different approach than IPv6 altogether where the full IPv4 address space was used for private addressing and edge devices would have prefixes that made them unique based on geographic/country/ISP information. But anyway, I am not convinced that NAT should be abandoned...



And tell me, do you just put "5th street" as your return address on letters or are you aware of your globally unique mailing address?

Because I *think* you do know your globally unique address and that is what you give out to folks whom want to mail things to you. And why should the electronic world be any different. All sorts of communication protocols have a need to "give out" their address so they can be reached at a later time.

-lee









-----Original Message-----

From: Gary Giesen [mailto:ggiesen at akn.ca]

Sent: Thursday, April 15, 2010 9:55 AM

To: Gams, Matthew D; 'arin-ppml at arin.net<mailto:arin-ppml at arin.net>'

Subject: Re: [arin-ppml] The role of NAT in IPv6



On 10-04-15 10:27 AM, "Gams, Matthew D" <Matthew.Gams at chartercom.com><mailto:Matthew.Gams at chartercom.com> wrote:





I don't understand why everyone wants to go IPv6 with global addressing

everywhere. And the solution to renumbering is getting organizations with

their own blocks which will slowly make the routing tables just as ugly as

IPv4????



I would say NAT66 with Site-local "private" addressing on the inside.



On the networks I've ran, I would never want to worry about renumbering just

because of an ISP change and I am not thinking that GUA is the way to go.



Keep the internal network internal and only change your outside numberings

when you need along with static NAT/NAT pools.



Am I missing something???





Yes, NAT is an ugly beast that we wish would disappear...



Since we have abundant globally unique addresses, and no equivalent to

RFC1918 in IPv6, it has reached the end of its usefulness...







-----Original Message-----

From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net] On Behalf

Of Chris Engel

Sent: Wednesday, March 31, 2010 9:56 AM

To: 'arin-ppml at arin.net<mailto:arin-ppml at arin.net>'

Subject: Re: [arin-ppml] The role of NAT in IPv6



Owen Delong wrote:





Actually, the places that most need to deploy IPv6 at this

point being eye-ball ISPs and the public-facing portions of

content and services providers, I don't think that NAT has

been an actual barrier to adoption in either of those spaces.

The vast majority of people calling for NAT66 are the

enterprise interior, which is, IMHO, the least critical and

least likely group to get on the IPv6 bandwagon quickly

regardless of what is done to appease them.







Well, in addition to being an Enterprise...my company is also an ASP.... which

I believe would qualify as a "content and services provider" under your

definition.



So lets see, if I want to deploy IPv6 currently....



 - Huge transition costs



 - No support for tools I rely on every day to make MY environment work the

way I want it.



 - Out of compliance with current regulatory standards.





Gee Whiz... where do I get to sign up for that?













Christopher Engel



_______________________________________________

PPML

You are receiving this message because you are subscribed to

the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto:ARIN-PPML at arin.net>).

Unsubscribe or manage your mailing list subscription at:

http://lists.arin.net/mailman/listinfo/arin-ppml

Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.

_______________________________________________

PPML

You are receiving this message because you are subscribed to

the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto:ARIN-PPML at arin.net>).

Unsubscribe or manage your mailing list subscription at:

http://lists.arin.net/mailman/listinfo/arin-ppml

Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.





_______________________________________________

PPML

You are receiving this message because you are subscribed to

the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto:ARIN-PPML at arin.net>).

Unsubscribe or manage your mailing list subscription at:

http://lists.arin.net/mailman/listinfo/arin-ppml

Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.





No, my letters to others have the full address information but my house only has 1234. Not even the street name is on my house. A true hierarchical address scheme would allow this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100415/7fd5cb5d/attachment.htm>

From tkubic at psi-inc.org  Thu Apr 15 13:21:09 2010
From: tkubic at psi-inc.org (Thomas Kubic)
Date: Thu, 15 Apr 2010 13:21:09 -0400
Subject: [arin-ppml] ISP Customer Data Privacy Proposal
Message-ID: <00a601cadcc0$09f80080$1de80180$@org>

Gentlemen:

 

I am writing to post a comment on the question of the ISP Customer Data
Privacy Proposal.

 

The Pharmaceutical Security Institute (PSI) is a not for profit organization
established in the early 1990's by the security directors from twenty-four
international, research based pharmaceutical manufacturers.  Now
headquartered in the Washington, D.C. area, the mission of PSI is to assist
member pharmaceutical manufacturers to collect and analyze information
related to the counterfeiting, illegal diversion and theft of
pharmaceuticals and to disseminate that information to law enforcement and
drug regulatory authorities.   The objective of these efforts is to disrupt
well-established counterfeiting groups.

 

Counterfeiting is viewed as a serious public health menace promoted by
criminals with little regard for the health and safety of patients.  The
security directors and their staff regularly work with the authorities to
stem the follow of illegal, unapproved and dangerous medicines.  

 

                One area of continued concern is the continued deluge of
unsolicited spam advertizing discount prices for medicines that has
bombarded the public.  A 2009 report from LegitScript and KnujOn found that
80 to 90 percent of the search engine-sponsored advertisements of online
drug pharmacies violated federal and state laws.[1] (see:
http://r20.rs6.net/tn.jsp?t=hxlt9mdab.0.9p97cqdab.ynkefvbab.2522
<http://r20.rs6.net/tn.jsp?t=hxlt9mdab.0.9p97cqdab.ynkefvbab.2522&ts=S0467&p
=http%3A%2F%2Fwww.safemedicines.org%2F2009%2F09%2Finternet-search-engines-pr
omote-illegal-online-pharmacies.html>
&ts=S0467&p=http%3A%2F%2Fwww.safemedicines.org%2F2009%2F09%2Finternet-search
-engines-promote-illegal-online-pharmacies.html)

 

 

The World Health Organization has consistently warned against on-line
purchases of medicines noting the high percentage of counterfeit drugs being
sold.  

 

It seems to me that hiding the identity of the business user of an IP
address would further aggravate this problem for law enforcement officers,
customs agents and drug regulatory authorities.  Importantly, I see the
following negative impact on patients and consumers:

 

            It would deny the consumer access to the true identity of the
owners - today, consumers have few resources available to verify the owners
of the business sites;

 

It would facilitate fraudster's ability to steal money from consumers -
these fraudsters already exploit the internets' anonymous environment and
deny consumers protection against fraud;

 

It would complicate a consumer's ability to redress legitimate grievances;
and, finally,

 

It would further limit transparency in business transactions.  

 

            Would you kindly post my remarks,

 

            Thank you,

 

            Tom Kubic


  _____  

[1] See:  http://r20.rs6.net/tn.jsp?t=hxlt9mdab.0.9p97cqdab.ynkefvbab.2522
<http://r20.rs6.net/tn.jsp?t=hxlt9mdab.0.9p97cqdab.ynkefvbab.2522&ts=S0467&p
=http%3A%2F%2Fwww.safemedicines.org%2F2009%2F09%2Finternet-search-engines-pr
omote-illegal-online-pharmacies.html>
&ts=S0467&p=http%3A%2F%2Fwww.safemedicines.org%2F2009%2F09%2Finternet-search
-engines-promote-illegal-online-pharmacies.html>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100415/b60f409e/attachment.htm>

From dwhite at olp.net  Thu Apr 15 14:31:23 2010
From: dwhite at olp.net (Dan White)
Date: Thu, 15 Apr 2010 13:31:23 -0500
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <21E4831D76704142BBAF6DC8F252904A0164AD6444@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
References: <21E4831D76704142BBAF6DC8F252904A0164AD6302@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
	<C7ECA0F5.923F%ggiesen@akn.ca>
	<21E4831D76704142BBAF6DC8F252904A0164AD6444@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
Message-ID: <20100415183123.GA8802@dan.olp.net>

On 15/04/10?10:21?-0500, Gams, Matthew D wrote:
>This assumes that just because you access the Internet you should be globally routable. I know it's too late to debate addressing schemes as IPv6 is already here but just because you have an insanely large address pool doesn't mean every toaster needs to have a globally unique address.

Frederick P Brooks, in his new Design on Design book, articulates something
that I've always strongly believed in. When discussing several key
components of a good design (not networking specific):

	Generality is the ability to use a function for many ends. It expresses
     the professional humility of the designer, his conviction that users
     will be inventive beyond his imagination and that needs may change
     beyond his ability to forecast. The designer should avoid limiting a
     function by his own notions about its use. When you don't know, grant
     freedom.

Protocol designers should not be thinking about the wisdom of addressing a
toaster. They have a different purpose. The same should be (mostly) true of
the RIR allocation process, and the ISP assignment process.

The debate about how addresses should be used should be done at the end
user or enterprise level. NAT will be used in IPv6, because many enterprise
and home users will deem that to be most appropriate for their users.
Those admins have the responsibility to secure their networks in
whatever way makes most sense to them.

But I feel that ISPs and network operators that NAT in front of their
enterprise, business, and residential customers are doing them a great
disservice.

-- 
Dan White


From Matthew.Gams at chartercom.com  Thu Apr 15 14:36:04 2010
From: Matthew.Gams at chartercom.com (Gams, Matthew D)
Date: Thu, 15 Apr 2010 13:36:04 -0500
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <20100415183123.GA8802@dan.olp.net>
References: <21E4831D76704142BBAF6DC8F252904A0164AD6302@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
	<C7ECA0F5.923F%ggiesen@akn.ca>
	<21E4831D76704142BBAF6DC8F252904A0164AD6444@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
	<20100415183123.GA8802@dan.olp.net>
Message-ID: <21E4831D76704142BBAF6DC8F252904A0164B9E92E@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>



> -----Original Message-----
> From: Dan White [mailto:dwhite at olp.net]
> Sent: Thursday, April 15, 2010 1:31 PM
> To: Gams, Matthew D
> Cc: Gary Giesen; 'arin-ppml at arin.net'
> Subject: Re: The role of NAT in IPv6
> 
> On 15/04/10?10:21?-0500, Gams, Matthew D wrote:
> >This assumes that just because you access the Internet you should be
> globally routable. I know it's too late to debate addressing schemes as
> IPv6 is already here but just because you have an insanely large address
> pool doesn't mean every toaster needs to have a globally unique address.
> 
> Frederick P Brooks, in his new Design on Design book, articulates
> something
> that I've always strongly believed in. When discussing several key
> components of a good design (not networking specific):
> 
> 	Generality is the ability to use a function for many ends. It
> expresses
>      the professional humility of the designer, his conviction that
> users
>      will be inventive beyond his imagination and that needs may change
>      beyond his ability to forecast. The designer should avoid limiting
> a
>      function by his own notions about its use. When you don't know,
> grant
>      freedom.
> 
> Protocol designers should not be thinking about the wisdom of addressing
> a
> toaster. They have a different purpose. The same should be (mostly) true
> of
> the RIR allocation process, and the ISP assignment process.
> 
> The debate about how addresses should be used should be done at the end
> user or enterprise level. NAT will be used in IPv6, because many
> enterprise
> and home users will deem that to be most appropriate for their users.
> Those admins have the responsibility to secure their networks in
> whatever way makes most sense to them.
> 
> But I feel that ISPs and network operators that NAT in front of their
> enterprise, business, and residential customers are doing them a great
> disservice.

Agreed.
 

> --
> Dan White


From ggiesen at akn.ca  Thu Apr 15 15:08:43 2010
From: ggiesen at akn.ca (Gary T. Giesen)
Date: Thu, 15 Apr 2010 15:08:43 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <20100415183123.GA8802@dan.olp.net>
References: <21E4831D76704142BBAF6DC8F252904A0164AD6302@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
	<C7ECA0F5.923F%ggiesen@akn.ca>
	<21E4831D76704142BBAF6DC8F252904A0164AD6444@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
	<20100415183123.GA8802@dan.olp.net>
Message-ID: <1271358523.5224.95.camel@ggiesen-workstation.netsurf.net>

On Thu, 2010-04-15 at 14:31 -0400, Dan White wrote:
> On 15/04/10 10:21 -0500, Gams, Matthew D wrote:
> >This assumes that just because you access the Internet you should be globally routable. I know it's too late to debate addressing schemes as IPv6 is already here but just because you have an insanely large address pool doesn't mean every toaster needs to have a globally unique address.
> 
> Frederick P Brooks, in his new Design on Design book, articulates something
> that I've always strongly believed in. When discussing several key
> components of a good design (not networking specific):
> 
> 	Generality is the ability to use a function for many ends. It expresses
>      the professional humility of the designer, his conviction that users
>      will be inventive beyond his imagination and that needs may change
>      beyond his ability to forecast. The designer should avoid limiting a
>      function by his own notions about its use. When you don't know, grant
>      freedom.
> 
> Protocol designers should not be thinking about the wisdom of addressing a
> toaster. They have a different purpose. The same should be (mostly) true of
> the RIR allocation process, and the ISP assignment process.
> 
> The debate about how addresses should be used should be done at the end
> user or enterprise level. NAT will be used in IPv6, because many enterprise
> and home users will deem that to be most appropriate for their users.
> Those admins have the responsibility to secure their networks in
> whatever way makes most sense to them.
> 
For home users (whose cost to renumber is the smallest out of all groups
and truly have absolutely no reason to use it) will get the greatest
benefit from not having NAT. Since they don't have dedicated network
admins to troubleshoot NAT issues.

> But I feel that ISPs and network operators that NAT in front of their
> enterprise, business, and residential customers are doing them a great
> disservice.

I don't think any ISP is talking about NAT66'ing their customers, it's
more about whether their customers should do it themselves.

As Owen has pointed out many times, the cost of supporting NAT is rarely
borne by the person implementing it. It's borne by everyone else trying
to sell services to the the NAT'd customer.

If you think it's wrong to use IP allocation policy as a tool for a
prescriptive approach to NAT in IPv6 (or lack thereof), we're already
using it as a measure to constrain BGP table growth, which like NAT, is
a cost shared mostly not by the route originator (read: NAT
implementer), but by everyone else.

GG



From Bill.Smith at paypal.com  Thu Apr 15 15:28:19 2010
From: Bill.Smith at paypal.com (Smith, Bill)
Date: Thu, 15 Apr 2010 13:28:19 -0600
Subject: [arin-ppml] Comments - Draft Policy 2010-3: Customer Confidentiality
Message-ID: <39BF0C2785E4044E81A4D55B333D5106611D4B2551@DEN-MEXMS-001.corp.ebay.com>

Proposal 2010-3 fails to meet the spirit, if not the letter of the Policy Development Process that instructs proposers to "make a clear and concise policy statement that is unambiguous and actionable" that "will ideally fit right into the Number Resource Policy Manual". A quick analysis follows:
Concise: a model of brevity using only 47 words.
Actionable: requests a new policy, but no changes to existing policy language.
Ambiguity: conflicts with NPRM 3.3 [1] and RSA 5. (b). [2]
Clarity: does not clearly state who can request "actual customer information"; who that request is made to; uses a term of art "strictest confidence" that is open to broad interpretation; and does not clearly state who is required to maintain that confidence.
As written, Proposal 2010-3 is far from "ideal". If the requested action (add the proposal text as a new policy) is taken, the NPRM becomes self-contradictory or at best ambiguous. Substituting an ISP's contact information for a customer's will institutionalize as acceptable, inaccurate WHOIS information in direct contravention to the RSA. Resolving these ambiguities will require changes to other ARIN polices and the RSA yet this proposal does not specify what those changes should be.
The rationale provided for Proposal 2010-3 does not articulate a specific problem as suggested in Appendix B of the PDP. Rather, it informs us that customer lists are proprietary assets that any good business would zealously protect. It goes on to suggest that current ARIN agreement and policy requirements "invites competitors and others to solicit both individuals and companies" "contrary to good business practices"..
The problem, if any, as articulated in the rationale is that the petitioner knowingly entered into an agreement but failed to exercise good business judgment or the petitioner was unaware of ARIN policies and long-standing Internet practice of providing and publishing the information in question. In either case, this is not the forum to address such a failure or lack of knowledge.
Proposal 2010-3 is a solution in search of a problem, and as articulated above, fails to meet the reasonable criteria for a policy as established by the PDP and consequently should not be adopted.
As a final comment, Proposal 2010-3 should not be adopted "on the merits". Others have argued against it on those grounds and repeating those arguments would needlessly consume yet more of our time.

[1] NPRM 3.3 that states "Organizations may designate certain points of contact as private from ARIN WHOIS, with the exception that, at the minimum, one point of contact must be viewable."
[2] RSA 5. (b) places a responsibility on the Applicant (ISP) "for the timely and accurate maintenance of directory services data (WHOIS), as well as data concerning any organization to which it further sub-delegates number resources".

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100415/57e380a5/attachment.htm>

From cengel at sponsordirect.com  Thu Apr 15 17:48:37 2010
From: cengel at sponsordirect.com (Chris Engel)
Date: Thu, 15 Apr 2010 17:48:37 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <mailman.1141.1271358531.28982.arin-ppml@arin.net>
Message-ID: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA634@Skyhawk>


Gary T. Giesen wrote:

> As Owen has pointed out many times, the cost of supporting
> NAT is rarely borne by the person implementing it. It's borne
> by everyone else trying to sell services to the the NAT'd customer.

So let me get this straight, you're complaining that your customers demand support for X functionality (NAT or fill in whatever blank you want) in the services that you are trying to sell them and then assert how unfair it is that you have to carry the costs of meeting your own (potential) customers demand?

Let me introduce you to this concept called a "free market economy".



Christopher Engel



From owen at delong.com  Thu Apr 15 17:59:03 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 15 Apr 2010 14:59:03 -0700
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA634@Skyhawk>
References: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA634@Skyhawk>
Message-ID: <BBFC01FA-DC9D-43DC-BD9C-B18BC7ADC1F5@delong.com>


On Apr 15, 2010, at 2:48 PM, Chris Engel wrote:

> 
> Gary T. Giesen wrote:
> 
>> As Owen has pointed out many times, the cost of supporting
>> NAT is rarely borne by the person implementing it. It's borne
>> by everyone else trying to sell services to the the NAT'd customer.
> 
> So let me get this straight, you're complaining that your customers demand support for X functionality (NAT or fill in whatever blank you want) in the services that you are trying to sell them and then assert how unfair it is that you have to carry the costs of meeting your own (potential) customers demand?
> 
I'm not sure what Gary is asserting. However, I suspect his assertion
is similar to mine...

I'm asserting that NAT creates the following costs borne by people
providing services to NON-NATTed customers who have nothing
whatsoever to do with NAT:

	1.	Additional troubleshooting difficulty/cost (web sites, services,
		network providers, network providers selling to web sites, etc.)
	2.	Additional software complexity (ISVs)
	3.	Decreased security (inability to correlate events/logs)
	4.	Increased legal costs (see 3)

> Let me introduce you to this concept called a "free market economy".
> 
Even in a free market economy, you're not supposed to dump toxic
chemicals in the river upstream from my water treatment plant.


Owen



From ggiesen at akn.ca  Thu Apr 15 18:01:50 2010
From: ggiesen at akn.ca (Gary T. Giesen)
Date: Thu, 15 Apr 2010 18:01:50 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA634@Skyhawk>
References: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA634@Skyhawk>
Message-ID: <1271368910.5224.114.camel@ggiesen-workstation.netsurf.net>




On Thu, 2010-04-15 at 17:48 -0400, Chris Engel wrote:
> Gary T. Giesen wrote:
> 
> > As Owen has pointed out many times, the cost of supporting
> > NAT is rarely borne by the person implementing it. It's borne
> > by everyone else trying to sell services to the the NAT'd customer.
> 
> So let me get this straight, you're complaining that your customers demand support for X functionality (NAT or fill in whatever blank you want) in the services that you are trying to sell them and then assert how unfair it is that you have to carry the costs of meeting your own (potential) customers demand?
> 
Actually what I'm really arguing for is for people to understand in IPv6
you don't generally need NAT (with the arguable exception of a few
corner cases, which even those can be resolved). 

I'm arguing for people not to take the same perceptions they have about
how things work in IPv4 and apply them to IPv6 just because it's
familiar and comfortable. I'm arguing for a new way to do things in IPv6
(and as the creators of IPv6 seem to have intended). 

I'm arguing that IPv6 is not just IPv4 with more addresses (although
that, in and of itself, changes things). They're getting used to a new
protocol anyways, let's go that extra step and educate them about what
IPv6 offers, and why they don't have to do things the old way (and why
the new way is better).

What I'm saying is that if we all agree the support costs for supporting
a customer who is NAT'd compared to one who is not (even if they're
using a stateful firewall) are greater, and that in IPv6 land I can show
there's no longer any useful reason for NAT (and we can eliminate the
arguable corner cases) then why would we pollute our nice shiny new
protocol with the ugly beast that is NAT.

> Let me introduce you to this concept called a "free market economy".
> 
There's never been a free market economy in IP allocations... Otherwise
I might be acquiring IPs from eBay rather than ARIN. 
> 
> 
> Christopher Engel
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From ggiesen at akn.ca  Thu Apr 15 18:04:48 2010
From: ggiesen at akn.ca (Gary T. Giesen)
Date: Thu, 15 Apr 2010 18:04:48 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <1271368910.5224.114.camel@ggiesen-workstation.netsurf.net>
References: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA634@Skyhawk>
	<1271368910.5224.114.camel@ggiesen-workstation.netsurf.net>
Message-ID: <1271369088.5224.117.camel@ggiesen-workstation.netsurf.net>

On Thu, 2010-04-15 at 18:01 -0400, Gary T. Giesen wrote:
> 
> 
> On Thu, 2010-04-15 at 17:48 -0400, Chris Engel wrote:
> > Gary T. Giesen wrote:
> > 
> > > As Owen has pointed out many times, the cost of supporting
> > > NAT is rarely borne by the person implementing it. It's borne
> > > by everyone else trying to sell services to the the NAT'd customer.
> > 
> > So let me get this straight, you're complaining that your customers demand support for X functionality (NAT or fill in whatever blank you want) in the services that you are trying to sell them and then assert how unfair it is that you have to carry the costs of meeting your own (potential) customers demand?
> > 
> Actually what I'm really arguing for is for people to understand in IPv6
> you don't generally need NAT (with the arguable exception of a few
> corner cases, which even those can be resolved). 
> 
> I'm arguing for people not to take the same perceptions they have about
> how things work in IPv4 and apply them to IPv6 just because it's
> familiar and comfortable. I'm arguing for a new way to do things in IPv6
> (and as the creators of IPv6 seem to have intended). 
> 
> I'm arguing that IPv6 is not just IPv4 with more addresses (although
> that, in and of itself, changes things). They're getting used to a new
> protocol anyways, let's go that extra step and educate them about what
> IPv6 offers, and why they don't have to do things the old way (and why
> the new way is better).
> 
> What I'm saying is that if we all agree the support costs for supporting
> a customer who is NAT'd compared to one who is not (even if they're
> using a stateful firewall) are greater, and that in IPv6 land I can show
> there's no longer any useful reason for NAT (and we can eliminate the
> arguable corner cases) then why would we pollute our nice shiny new
> protocol with the ugly beast that is NAT.
> 
> > Let me introduce you to this concept called a "free market economy".
> > 
> There's never been a free market economy in IP allocations... Otherwise
> I might be acquiring IPs from eBay rather than ARIN. 

And let me just follow up that last comment by saying if we make IP
policy in such a way that NAT is unattractive enough (because of ULA-C
address unavailability, which is the prime breeding ground for NAT; or
make GUA cheap and easy enough to get) then market economics will
dictate it dies with IPv4.
> > 
> > Christopher Engel
> > 
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From bill at herrin.us  Thu Apr 15 18:22:23 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 15 Apr 2010 18:22:23 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <1271358523.5224.95.camel@ggiesen-workstation.netsurf.net>
References: <21E4831D76704142BBAF6DC8F252904A0164AD6302@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
	<C7ECA0F5.923F%ggiesen@akn.ca>
	<21E4831D76704142BBAF6DC8F252904A0164AD6444@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
	<20100415183123.GA8802@dan.olp.net>
	<1271358523.5224.95.camel@ggiesen-workstation.netsurf.net>
Message-ID: <u2l3c3e3fca1004151522o8c7e0815q3096bd708576ee0c@mail.gmail.com>

On Thu, Apr 15, 2010 at 3:08 PM, Gary T. Giesen <ggiesen at akn.ca> wrote:
> If you think it's wrong to use IP allocation policy as a tool for a
> prescriptive approach to NAT in IPv6 (or lack thereof), we're already
> using it as a measure to constrain BGP table growth, which like NAT, is
> a cost shared mostly not by the route originator (read: NAT
> implementer), but by everyone else.

Respectfully Gary, that doesn't follow.

Route announcements have a direct, real cost. Your route announcement
consumes resources in tens of thousands of routers, compelling those
routers' owners to spend money. Use of NAT has, at worst, an
opportunity cost. Because someone uses NAT, you lose the opportunity
to vend an incompatible product or service.

Shall we use ARIN policy to require registrants to wear pink dresses
because you might have trouble selling them pink dresses if we don't?


> As Owen has pointed out many times, the cost of supporting NAT is rarely
> borne by the person implementing it. It's borne by everyone else trying
> to sell services to the the NAT'd customer.

The cost of your breathing is borne by everyone else who has to muddle
through with that much less oxygen. Shall I object? Perhaps you should
hold your breath.

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 ggiesen at akn.ca  Thu Apr 15 18:31:51 2010
From: ggiesen at akn.ca (Gary T. Giesen)
Date: Thu, 15 Apr 2010 18:31:51 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <BBFC01FA-DC9D-43DC-BD9C-B18BC7ADC1F5@delong.com>
References: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA634@Skyhawk>
	<BBFC01FA-DC9D-43DC-BD9C-B18BC7ADC1F5@delong.com>
Message-ID: <1271370711.5224.133.camel@ggiesen-workstation.netsurf.net>

Let's see if we can summarize the major reasons people are led to NAT:

1) Address scarcity - This is not an issue with IPv6, is the vast
majority of cases, and the reason NAT/PAT was created in the first place

2) Renumbering pain - Can be solved with relatively cheap,
readily-available GUA. Since every address is globally unique, you no
longer need to do 1:1 address translation. Since people can get their
allocations cheaply, it solves the renumbering pain/being tied to a
service provider. Some might argue this introduces a new cost through
the expansion of the DFZ and numbering of routing slots required, but
I'd argue the economic costs of NAT *far* outweigh this.

3) Regulatory requirements (HIPPA, PCI DSS) - This a policy obstacle,
not a technical one. Solving this involves no new implementations, just
educating regulators on what the realities of IPv6 are (or should be).
Yes, this one is the biggest obstacle, but not completely out of reach.
Isn't it our job as network operators to help both our customers and the
regulators understand that "IPv6 should work like this?"

If we can resolve all the reasons that lead people to NAT, we all
benefit. Through less complexity, lower deployment and support costs,
and better interoperability. Whether I'm a hardware vendor, ASP, ISP,
anything that touches IPv6 benefits. It shortens the time to market of
new products, and accelerates IPv6 deployment. 

I couldn't even fathom what NAT has cost anyone who product uses IP, but
it's *huge*. Getting rid of it is win-win.

GG

On Thu, 2010-04-15 at 17:59 -0400, Owen DeLong wrote:
> On Apr 15, 2010, at 2:48 PM, Chris Engel wrote:
> 
> > 
> > Gary T. Giesen wrote:
> > 
> >> As Owen has pointed out many times, the cost of supporting
> >> NAT is rarely borne by the person implementing it. It's borne
> >> by everyone else trying to sell services to the the NAT'd customer.
> > 
> > So let me get this straight, you're complaining that your customers demand support for X functionality (NAT or fill in whatever blank you want) in the services that you are trying to sell them and then assert how unfair it is that you have to carry the costs of meeting your own (potential) customers demand?
> > 
> I'm not sure what Gary is asserting. However, I suspect his assertion
> is similar to mine...
> 
> I'm asserting that NAT creates the following costs borne by people
> providing services to NON-NATTed customers who have nothing
> whatsoever to do with NAT:
> 
> 	1.	Additional troubleshooting difficulty/cost (web sites, services,
> 		network providers, network providers selling to web sites, etc.)
> 	2.	Additional software complexity (ISVs)
> 	3.	Decreased security (inability to correlate events/logs)
> 	4.	Increased legal costs (see 3)
> 
> > Let me introduce you to this concept called a "free market economy".
> > 
> Even in a free market economy, you're not supposed to dump toxic
> chemicals in the river upstream from my water treatment plant.
> 
> 
> Owen
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From ggiesen at akn.ca  Thu Apr 15 18:37:16 2010
From: ggiesen at akn.ca (Gary T. Giesen)
Date: Thu, 15 Apr 2010 18:37:16 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <u2l3c3e3fca1004151522o8c7e0815q3096bd708576ee0c@mail.gmail.com>
References: <21E4831D76704142BBAF6DC8F252904A0164AD6302@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
	<C7ECA0F5.923F%ggiesen@akn.ca>
	<21E4831D76704142BBAF6DC8F252904A0164AD6444@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
	<20100415183123.GA8802@dan.olp.net>
	<1271358523.5224.95.camel@ggiesen-workstation.netsurf.net>
	<u2l3c3e3fca1004151522o8c7e0815q3096bd708576ee0c@mail.gmail.com>
Message-ID: <1271371036.5224.138.camel@ggiesen-workstation.netsurf.net>

I'd argue that the collective costs of implementing and supporting NAT
far outweigh the costs of more routing slots (though neither is a small
number, I'd argue NAT is at least an order of magnitude higher).

Also, IPv6 adoption, despite my best optimism, will be rather slow, and
IPv4 will be with us for some time to come. That gives router vendors
time to increase the size of their TCAMs, and ISP's time to upgrade on
their normal refresh schedules.

Enterprises will be the last to adopt IPv6 regardless of what we do,
should we hold up the show for them? Or should we take a leadership
position, show them that IPv6 can be done without NAT (and more
effectively and cheaply)?

GG

On Thu, 2010-04-15 at 18:22 -0400, William Herrin wrote:
> On Thu, Apr 15, 2010 at 3:08 PM, Gary T. Giesen <ggiesen at akn.ca> wrote:
> > If you think it's wrong to use IP allocation policy as a tool for a
> > prescriptive approach to NAT in IPv6 (or lack thereof), we're already
> > using it as a measure to constrain BGP table growth, which like NAT, is
> > a cost shared mostly not by the route originator (read: NAT
> > implementer), but by everyone else.
> 
> Respectfully Gary, that doesn't follow.
> 
> Route announcements have a direct, real cost. Your route announcement
> consumes resources in tens of thousands of routers, compelling those
> routers' owners to spend money. Use of NAT has, at worst, an
> opportunity cost. Because someone uses NAT, you lose the opportunity
> to vend an incompatible product or service.
> 
> Shall we use ARIN policy to require registrants to wear pink dresses
> because you might have trouble selling them pink dresses if we don't?
> 
> 
> > As Owen has pointed out many times, the cost of supporting NAT is rarely
> > borne by the person implementing it. It's borne by everyone else trying
> > to sell services to the the NAT'd customer.
> 
> The cost of your breathing is borne by everyone else who has to muddle
> through with that much less oxygen. Shall I object? Perhaps you should
> hold your breath.
> 
> Regards,
> Bill Herrin
> 
> 
> 



From ggiesen at akn.ca  Thu Apr 15 18:51:00 2010
From: ggiesen at akn.ca (Gary T. Giesen)
Date: Thu, 15 Apr 2010 18:51:00 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <4BC797AA.2010901@actusa.net>
References: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA634@Skyhawk>
	<BBFC01FA-DC9D-43DC-BD9C-B18BC7ADC1F5@delong.com>
	<1271370711.5224.133.camel@ggiesen-workstation.netsurf.net>
	<4BC797AA.2010901@actusa.net>
Message-ID: <1271371860.5224.141.camel@ggiesen-workstation.netsurf.net>

On Thu, 2010-04-15 at 18:48 -0400, Stuart Sheldon wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> I have never seen anything in writing that states you must run NAT to
> maintain HIPAA, PCI, or DSS compliance. If such a rule actually exists,
> can someone please post a URL for reference?
> 

One of the arguments for NAT earlier in this thread stated that hiding
the topology of the network from hosts outside the network was a
requirement, which is most easily achievable with 1:many NAT. 


> And for what it's worth, I agree with Gary... It's our job to educate
> the less experienced about IPv6. It's not just IPv4 with more addresses,
> and for most of the built in security RFCs to work properly in IPv6, NAT
> is not a viable option...
> 
> Stu
> 
> 
> Gary T. Giesen wrote:
> > Let's see if we can summarize the major reasons people are led to NAT:
> > 
> > 1) Address scarcity - This is not an issue with IPv6, is the vast
> > majority of cases, and the reason NAT/PAT was created in the first place
> > 
> > 2) Renumbering pain - Can be solved with relatively cheap,
> > readily-available GUA. Since every address is globally unique, you no
> > longer need to do 1:1 address translation. Since people can get their
> > allocations cheaply, it solves the renumbering pain/being tied to a
> > service provider. Some might argue this introduces a new cost through
> > the expansion of the DFZ and numbering of routing slots required, but
> > I'd argue the economic costs of NAT *far* outweigh this.
> > 
> > 3) Regulatory requirements (HIPPA, PCI DSS) - This a policy obstacle,
> > not a technical one. Solving this involves no new implementations, just
> > educating regulators on what the realities of IPv6 are (or should be).
> > Yes, this one is the biggest obstacle, but not completely out of reach.
> > Isn't it our job as network operators to help both our customers and the
> > regulators understand that "IPv6 should work like this?"
> > 
> > If we can resolve all the reasons that lead people to NAT, we all
> > benefit. Through less complexity, lower deployment and support costs,
> > and better interoperability. Whether I'm a hardware vendor, ASP, ISP,
> > anything that touches IPv6 benefits. It shortens the time to market of
> > new products, and accelerates IPv6 deployment. 
> > 
> > I couldn't even fathom what NAT has cost anyone who product uses IP, but
> > it's *huge*. Getting rid of it is win-win.
> > 
> > GG
> > 
> > On Thu, 2010-04-15 at 17:59 -0400, Owen DeLong wrote:
> >> On Apr 15, 2010, at 2:48 PM, Chris Engel wrote:
> >>
> >>> Gary T. Giesen wrote:
> >>>
> >>>> As Owen has pointed out many times, the cost of supporting
> >>>> NAT is rarely borne by the person implementing it. It's borne
> >>>> by everyone else trying to sell services to the the NAT'd customer.
> >>> So let me get this straight, you're complaining that your customers demand support for X functionality (NAT or fill in whatever blank you want) in the services that you are trying to sell them and then assert how unfair it is that you have to carry the costs of meeting your own (potential) customers demand?
> >>>
> >> I'm not sure what Gary is asserting. However, I suspect his assertion
> >> is similar to mine...
> >>
> >> I'm asserting that NAT creates the following costs borne by people
> >> providing services to NON-NATTed customers who have nothing
> >> whatsoever to do with NAT:
> >>
> >> 	1.	Additional troubleshooting difficulty/cost (web sites, services,
> >> 		network providers, network providers selling to web sites, etc.)
> >> 	2.	Additional software complexity (ISVs)
> >> 	3.	Decreased security (inability to correlate events/logs)
> >> 	4.	Increased legal costs (see 3)
> >>
> >>> Let me introduce you to this concept called a "free market economy".
> >>>
> >> Even in a free market economy, you're not supposed to dump toxic
> >> chemicals in the river upstream from my water treatment plant.
> >>
> >>
> >> Owen
> >>
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed to
> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
> > 
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> > 
> 
> 
> - --
> Tambourines and elephants are playing in the band. Wont you take a
> ride on the flyin spoon? Doo, doo doo. Wondrous apparition provided
> by magician. Doo, doo, doo, lookin out my back door.
>         -- Creedence Clearwater Revival - "Looking out my back door"
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> 
> iQIcBAEBCAAGBQJLx5enAAoJEFKVLITDJSGSFn8QAJUkwfSrMJu8HR3xIRGB5d9j
> 0isjPJbhh3XDKYrb9AXzMc0L9r21h6rgZPT6qwdJ4wGJuFLi2wrKAYMeHatseXql
> GkP1vsMOK69JrG4vlAm+VqodCWscXDim/1YxGZIDAqYl17Bfdhfnw6KebSIr0Jz4
> PiZiGga0sD1AYQSGiIGZNf/4ockpIIEvd0RTBSFIig3h3eBECz7DUjqWBWGqmx8I
> 4ICX1aMLLCd6LwEj9wUuzZJscPXo7IeqNDhC4xju19rjQCxg9IWMIdvV5VmIwPFI
> vGfspIEZSeirYPvP23xYlb/DilsmLgZZFWzanoZ0O/KVfcddkVYY1ujILQrUyPpB
> uIOR7mDmSTV0AIwk5fPEbVL8QOj3RQaCM7hyzQNS/AghGuzS8xHYFzU2Pbfg/UXb
> hI9pXqAIpZjLNwzIqnf1+xqs6GwYOYMvxuo+GTFRi7NiAw0sLT6MrcqNJjPa5E/Z
> nj85NGHmZHyYJd8kqILjhRiTPWNFt/2EthHkostmJTnb3ppunO7l5wPzILXNFt9A
> x8u0b5bLFdpoOe1vK39gOTiQfOQhfO67W0yoQAnqUYcSS+XLuKmKKwUibKWmnBak
> cinIfgAu5fmqq9BZv42wNZ73y6b1qUJtV+hR7Pk1JszP2mWORdR/8F5nvTFZwxLG
> sl6C16FOS1u+vGrrc0OH
> =mje+
> -----END PGP SIGNATURE-----



From stu at actusa.net  Thu Apr 15 18:48:10 2010
From: stu at actusa.net (Stuart Sheldon)
Date: Thu, 15 Apr 2010 15:48:10 -0700
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <1271370711.5224.133.camel@ggiesen-workstation.netsurf.net>
References: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA634@Skyhawk>	<BBFC01FA-DC9D-43DC-BD9C-B18BC7ADC1F5@delong.com>
	<1271370711.5224.133.camel@ggiesen-workstation.netsurf.net>
Message-ID: <4BC797AA.2010901@actusa.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I have never seen anything in writing that states you must run NAT to
maintain HIPAA, PCI, or DSS compliance. If such a rule actually exists,
can someone please post a URL for reference?

And for what it's worth, I agree with Gary... It's our job to educate
the less experienced about IPv6. It's not just IPv4 with more addresses,
and for most of the built in security RFCs to work properly in IPv6, NAT
is not a viable option...

Stu


Gary T. Giesen wrote:
> Let's see if we can summarize the major reasons people are led to NAT:
> 
> 1) Address scarcity - This is not an issue with IPv6, is the vast
> majority of cases, and the reason NAT/PAT was created in the first place
> 
> 2) Renumbering pain - Can be solved with relatively cheap,
> readily-available GUA. Since every address is globally unique, you no
> longer need to do 1:1 address translation. Since people can get their
> allocations cheaply, it solves the renumbering pain/being tied to a
> service provider. Some might argue this introduces a new cost through
> the expansion of the DFZ and numbering of routing slots required, but
> I'd argue the economic costs of NAT *far* outweigh this.
> 
> 3) Regulatory requirements (HIPPA, PCI DSS) - This a policy obstacle,
> not a technical one. Solving this involves no new implementations, just
> educating regulators on what the realities of IPv6 are (or should be).
> Yes, this one is the biggest obstacle, but not completely out of reach.
> Isn't it our job as network operators to help both our customers and the
> regulators understand that "IPv6 should work like this?"
> 
> If we can resolve all the reasons that lead people to NAT, we all
> benefit. Through less complexity, lower deployment and support costs,
> and better interoperability. Whether I'm a hardware vendor, ASP, ISP,
> anything that touches IPv6 benefits. It shortens the time to market of
> new products, and accelerates IPv6 deployment. 
> 
> I couldn't even fathom what NAT has cost anyone who product uses IP, but
> it's *huge*. Getting rid of it is win-win.
> 
> GG
> 
> On Thu, 2010-04-15 at 17:59 -0400, Owen DeLong wrote:
>> On Apr 15, 2010, at 2:48 PM, Chris Engel wrote:
>>
>>> Gary T. Giesen wrote:
>>>
>>>> As Owen has pointed out many times, the cost of supporting
>>>> NAT is rarely borne by the person implementing it. It's borne
>>>> by everyone else trying to sell services to the the NAT'd customer.
>>> So let me get this straight, you're complaining that your customers demand support for X functionality (NAT or fill in whatever blank you want) in the services that you are trying to sell them and then assert how unfair it is that you have to carry the costs of meeting your own (potential) customers demand?
>>>
>> I'm not sure what Gary is asserting. However, I suspect his assertion
>> is similar to mine...
>>
>> I'm asserting that NAT creates the following costs borne by people
>> providing services to NON-NATTed customers who have nothing
>> whatsoever to do with NAT:
>>
>> 	1.	Additional troubleshooting difficulty/cost (web sites, services,
>> 		network providers, network providers selling to web sites, etc.)
>> 	2.	Additional software complexity (ISVs)
>> 	3.	Decreased security (inability to correlate events/logs)
>> 	4.	Increased legal costs (see 3)
>>
>>> Let me introduce you to this concept called a "free market economy".
>>>
>> Even in a free market economy, you're not supposed to dump toxic
>> chemicals in the river upstream from my water treatment plant.
>>
>>
>> Owen
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 


- --
Tambourines and elephants are playing in the band. Wont you take a
ride on the flyin spoon? Doo, doo doo. Wondrous apparition provided
by magician. Doo, doo, doo, lookin out my back door.
        -- Creedence Clearwater Revival - "Looking out my back door"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJLx5enAAoJEFKVLITDJSGSFn8QAJUkwfSrMJu8HR3xIRGB5d9j
0isjPJbhh3XDKYrb9AXzMc0L9r21h6rgZPT6qwdJ4wGJuFLi2wrKAYMeHatseXql
GkP1vsMOK69JrG4vlAm+VqodCWscXDim/1YxGZIDAqYl17Bfdhfnw6KebSIr0Jz4
PiZiGga0sD1AYQSGiIGZNf/4ockpIIEvd0RTBSFIig3h3eBECz7DUjqWBWGqmx8I
4ICX1aMLLCd6LwEj9wUuzZJscPXo7IeqNDhC4xju19rjQCxg9IWMIdvV5VmIwPFI
vGfspIEZSeirYPvP23xYlb/DilsmLgZZFWzanoZ0O/KVfcddkVYY1ujILQrUyPpB
uIOR7mDmSTV0AIwk5fPEbVL8QOj3RQaCM7hyzQNS/AghGuzS8xHYFzU2Pbfg/UXb
hI9pXqAIpZjLNwzIqnf1+xqs6GwYOYMvxuo+GTFRi7NiAw0sLT6MrcqNJjPa5E/Z
nj85NGHmZHyYJd8kqILjhRiTPWNFt/2EthHkostmJTnb3ppunO7l5wPzILXNFt9A
x8u0b5bLFdpoOe1vK39gOTiQfOQhfO67W0yoQAnqUYcSS+XLuKmKKwUibKWmnBak
cinIfgAu5fmqq9BZv42wNZ73y6b1qUJtV+hR7Pk1JszP2mWORdR/8F5nvTFZwxLG
sl6C16FOS1u+vGrrc0OH
=mje+
-----END PGP SIGNATURE-----


From bill at herrin.us  Thu Apr 15 19:04:21 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 15 Apr 2010 19:04:21 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <1271371036.5224.138.camel@ggiesen-workstation.netsurf.net>
References: <21E4831D76704142BBAF6DC8F252904A0164AD6302@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
	<C7ECA0F5.923F%ggiesen@akn.ca>
	<21E4831D76704142BBAF6DC8F252904A0164AD6444@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
	<20100415183123.GA8802@dan.olp.net>
	<1271358523.5224.95.camel@ggiesen-workstation.netsurf.net> 
	<u2l3c3e3fca1004151522o8c7e0815q3096bd708576ee0c@mail.gmail.com> 
	<1271371036.5224.138.camel@ggiesen-workstation.netsurf.net>
Message-ID: <w2v3c3e3fca1004151604ye2c8e5d7o7c4920e2e3761d95@mail.gmail.com>

On Thu, Apr 15, 2010 at 6:37 PM, Gary T. Giesen <ggiesen at akn.ca> wrote:
> I'd argue that the collective costs of implementing and supporting NAT
> far outweigh the costs of more routing slots (though neither is a small
> number, I'd argue NAT is at least an order of magnitude higher).

Gary,

It's entirely possible that more money is spent designing software
around NAT's limitations than is spent supporting routes in the DFZ.
Nevertheless, comparing the two is a logical fallacy.

In a free society it is perfectly OK for me to choose to buy something
whose use is incompatible with also choosing to buy and use your
product. That's called an "opportunity cost." It's quite unreasonable
to suggest that I shouldn't be allowed to buy the other product merely
because you will then have to spend money altering your product before
I'll be willing to buy it.

On the other hand, when I announce a route, I directly and immediately
consume resources on your router, whether or not I'm communicating
with your customers or taking any action that causes you to earn
revenue. I'm not merely declining to purchase your product, I'm
actively taking money out of your pocket. Since this otherwise
antisocial behavior turns out to be critical to the overall function
of the Internet, it makes sense to regulate it through an application
of public policy.

In summary: my declining to purchase your pink dress *is not* a valid
public policy concern. My taking your wallet *is* a valid public
policy concern. Try to understand the difference.

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 marquis at roble.com  Thu Apr 15 21:28:35 2010
From: marquis at roble.com (Roger Marquis)
Date: Thu, 15 Apr 2010 18:28:35 -0700 (PDT)
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <mailman.1148.1271369102.28982.arin-ppml@arin.net>
References: <mailman.1148.1271369102.28982.arin-ppml@arin.net>
Message-ID: <20100416012835.97F3A2B2121@mx5.roble.com>

Owen DeLong wrote:
> I'm asserting that NAT creates the following costs borne by people
> providing services to NON-NATTed customers who have nothing
> whatsoever to do with NAT:
>
> 	1.	Additional troubleshooting difficulty/cost (web sites, services,
> 		network providers, network providers selling to web sites, etc.)

You've detailed problems you have had Owen, configuring cheap CPE for
protocols like SIP, but consider that the rest of us might not have those
problems.  We spec capable gear where needed, or simply create static
mappings.

Some of us do this gladly as we recall the pre-NAT days, and how much
troubleshooting we had to do then.  Even with cheap CPE inbound
statefulness and ACLs are far easier to implement _with_ NAT.  They're also
more secure, as paranoids (i.e., security engineers) uniformly agree.

> 	2.	Additional software complexity (ISVs)

Pure FUD, and not even just when applied to protocols like SIP and SCTP,
or applications like torrents.  Weren't you just complaining about how
difficult and complex it was to implement ACLs for GUA route
announcements?  Are you really claiming now that your earlier point does
not applly to NAT?  Please explain this contradiction in your arguments.

> 	3.	Decreased security (inability to correlate events/logs)

Still waiting for you to float this opinion on firewall-wizards.  Good
luck wiht that.

> 	4.	Increased legal costs (see 3)

Give me a break.

The arguments being made against giving consumers the option of NATting
their internal networks are as specious as those once made against spam
filters.  They were rejected by the majority long ago, have never been
field tested, and are holding up the adoption of IPv6.

Follow the money and you'll see that the only good argument against NAT
in IPv6 is that it will limit the ability of IPv4 netblock holders and
hoarders to cash-in on the address shortage caused by further delays in
the roll-out of IPv6.

Roger Marquis


From farmer at umn.edu  Fri Apr 16 03:06:53 2010
From: farmer at umn.edu (David Farmer)
Date: Fri, 16 Apr 2010 02:06:53 -0500
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <4BC797AA.2010901@actusa.net>
References: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA634@Skyhawk>	<BBFC01FA-DC9D-43DC-BD9C-B18BC7ADC1F5@delong.com>	<1271370711.5224.133.camel@ggiesen-workstation.netsurf.net>
	<4BC797AA.2010901@actusa.net>
Message-ID: <4BC80C8D.3010500@umn.edu>

Stuart Sheldon wrote:
> I have never seen anything in writing that states you must run NAT to
> maintain HIPAA, PCI, or DSS compliance. If such a rule actually exists,
> can someone please post a URL for reference?

The PCI-DSS can be down loaded here;

https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml

There is a lot of nasty license agreement bla-bla-bla, that I just 
clicked through and have probably just violated to boot, but yes it does 
say NAT.

 From PCI DSS V1.2

------

PCI DSS Requirement

1.3.8 Implement IP masquerading to
prevent internal addresses from being
translated and revealed on the Internet,
using RFC 1918 address space. Use
network address translation (NAT)
technologies?for example, port address
translation (PAT).

Testing Procedures

1.3.8 For the sample of firewall and router components,
verify that NAT or other technology using RFC 1918
address space is used to restrict broadcast of IP
addresses from the internal network to the Internet (IP
masquerading).

------

Yes, you can provide Compensating Controls, but you will need to do more 
documentation and probably have to argue with auditors, managers, 
security consultants, etc... They will all point at this section, then 
you point to the Compensating Controls section, round and round and 
round you go....

We actually don't use NAT for PCI on our network, we document public 
addresses with stateful firewall as a Compensating Control.  However, we 
are tempted to switch to NAT because we are tired of arguing with people 
about it, we really do have better things to do you know.  Maybe like 
arguing with all of you on PPML, at least you all are more fun than the 
auditors. :)

HIPPA is a lot more complicated, and nowhere as clear cut either way, 
but since it has criminal penalties associated with it people get even 
more crazy.  I hope you have good heath insurance, because you are 
really going need therapy and good pharmaceuticals by the time you are 
done with those meetings. ;)

The real problem with all of this stuff is no one wants to be the nail 
standing tall or a field from everyone else, because you will get 
pounded down.

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


From cengel at sponsordirect.com  Fri Apr 16 11:33:36 2010
From: cengel at sponsordirect.com (Chris Engel)
Date: Fri, 16 Apr 2010 11:33:36 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <BBFC01FA-DC9D-43DC-BD9C-B18BC7ADC1F5@delong.com>
Message-ID: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA635@Skyhawk>



Owen Delong wrote:

>
>
> On Apr 15, 2010, at 2:48 PM, Chris Engel wrote:
>
> >
> > Gary T. Giesen wrote:
> >
> >> As Owen has pointed out many times, the cost of supporting NAT is
> >> rarely borne by the person implementing it. It's borne by everyone
> >> else trying to sell services to the the NAT'd customer.
> >
> > So let me get this straight, you're complaining that your customers
> > demand support for X functionality (NAT or fill in whatever
> blank you
> > want) in the services that you are trying to sell them and
> then assert
> > how unfair it is that you have to carry the costs of
> meeting your own
> > (potential) customers demand?
> >
> I'm not sure what Gary is asserting. However, I suspect his
> assertion is similar to mine...
>
> I'm asserting that NAT creates the following costs borne by
> people providing services to NON-NATTed customers who have
> nothing whatsoever to do with NAT:
>
>       1.      Additional troubleshooting difficulty/cost (web
> sites, services,
>               network providers, network providers selling to
> web sites, etc.)
>       2.      Additional software complexity (ISVs)
>       3.      Decreased security (inability to correlate events/logs)
>       4.      Increased legal costs (see 3)
>
> > Let me introduce you to this concept called a "free market economy".
> >
> Even in a free market economy, you're not supposed to dump
> toxic chemicals in the river upstream from my water treatment plant.
>
>
> Owen
>
>


Owen,

With all due respect, that is an entirely false analogy. Someone who dumps toxic chemicals into a stream is putting thier junk into a resource not owned by them without the consent of the owners of that resource.

In the case of NAT people are simply making a choice of how to configure thier OWN resources. No one else is FORCED to bare any of the costs of that choice. If they are, it is because they are choosing to do so... perhaps a reluctant choice...but still a CHOICE.

If you and Gary don't wish to bare the costs of dealing with NAT...the solution is simple...DON'T. You are in complete control of your own business...no one can force you to support NAT if you don't wish it.

You may not be able to sell your services to a broad array of customers but that is simply because many customers demand interopability with NAT as a feature of the services they purchase. That is no different then ANY other feature a customer might demand. If your customers demand written documentation and an SLA from you...do you complain that other vendors who offer such features as a standard are "toxic polluters" because they create an expectation among customers for such features?

I'm sure it would be far simpler for many vendors if there were only 1 desktop Operating System is existance in the world. They wouldn't have to write drivers or documentation for different systems, etc. Do we consider MicroSoft & Apple & whoever produces the dozens of different flavors of Unix "toxic polluters" for offering customers a choice in OS?

The bottom line is that people deploy NAT on thier OWN networks because they CHOOSE to do so. Other people interact with those networks because they CHOOSE to do so. Vendors offer NAT support in thier products and services because they CHOOSE to be marketable to all those customers.

There is no toxic polluter model at work here....what's at work is a free market model. Your complaints about having to bare the costs of NAT are about as valid as software vendors complaining that they had to bare the costs of switching over from Floppies to CD/DVD's.

Despite what you guys may think, NAT is an attractive solution to many people to address certain specific issues. If it wasn't, there would be no demand for it currently. As far as I can see it will CONTINUE TO BE SO in IPv6...because most of those issues still exist in an IPv6 world and to date none of the proposed alternatives meet those issues as effectively as NAT. If that isn't the case...then you won't need to worry about it...because then there won't be a demand for NAT.

If you guys want to climb up on your soapbox and preach about NAT being the devils own brew...by all means do so....just don't try to use public policy as a club to create false scarcity if your arguements proove unconvincing enough to sway the masses.



Christopher Engel



From michael.dillon at bt.com  Fri Apr 16 12:10:25 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 16 Apr 2010 17:10:25 +0100
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA635@Skyhawk>
Message-ID: <28E139F46D45AF49A31950F88C49745805C9DB6C@E03MVZ2-UKDY.domain1.systemhost.net>


> With all due respect, that is an entirely false analogy. 

You are wrong; Owen is right.

> The bottom line is that people deploy NAT on thier OWN 
> networks because they CHOOSE to do so. Other people interact 
> with those networks because they CHOOSE to do so. Vendors 
> offer NAT support in thier products and services because they 
> CHOOSE to be marketable to all those customers.

It is not their OWN network. If it really was their own network
then it would not have any use for NAT or any other kind
of Internet connectivity. The moment the network connects
to the Internet, it is no longer isolated and it's configuration
and operation can have potential global impacts.

> There is no toxic polluter model at work here....what's at 
> work is a free market model.

Sure, and if Ford decided to build all their cars with a fuel
tank that had an intake pipe 5mm smaller than current gasoline
fueled cars, with a patented screw connector with special
vapor release channel, and then only licenced Exxon to use
the special connectors on their fuel pumps, would it still
be a free market?

Putting NAT on Internet gateway boxes has limited the ability
of 3rd party suppliers to supply software and services to
NAT users, the most notable being telephony services which
require having some kind of phone set to which they can send
a ringing signal. NAT disallows incoming ring signals, so the
IETF has had to create all kinds of protocol workarounds for
this like STUN. And some of these workarounds only work for
a single phoneset behind the NAT, but cannot handle a PBX or
a situation in which there is the family phone, the teenagers'
phone upstairs, and mom's phone in the basement in-law suite.

With IPv6, we have the opportunity to separate NAT from firewall
features so that these can be implemented separately. In the IPv4
world, turning off NAT, opens up a host of security issues. But
if an IPv6 Internet gateway has an included firewall feature that
is on by default, then any NAT feature can be off by default.

In this kind of IPv6 world, simple Network Address Translation 
would be used only by a much smaller subset of people who actually
have real problems to solve with it; perhaps portability and 
renumbering. It will no longer be incorrectly considered to be
part of a security solution.

> Despite what you guys may think, NAT is an attractive 
> solution to many people to address certain specific issues. 

Sure. But NAT will be much rarer in IPv6 and mostly on 
corporate gateways, not the kind of standard feature
that it is today. In any case, are there any NAT implementations
available yet for IPv6?

--Michael Dillon


From mueller at syr.edu  Fri Apr 16 12:36:26 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Fri, 16 Apr 2010 12:36:26 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <4BC74C57.9010602@ipinc.net>
References: <20100413172714.M35473@fast-serv.com><4BC4B1B6.7060804@ipinc.net>
	<A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>
	<4BC62352.2090202@rollernet.us>
	<75822E125BCB994F8446858C4B19F0D701D5FCA511@SUEX07-MBX-04.ad.syr.edu>
	<4BC62E81.3040600@ipinc.net>
	<75822E125BCB994F8446858C4B19F0D701D5FCA516@SUEX07-MBX-04.ad.syr.edu>
	<4BC63FB7.5000404@umn.edu>
	<75822E125BCB994F8446858C4B19F0D701D5FCA522@SUEX07-MBX-04.ad.syr.edu>
	<4BC74C57.9010602@ipinc.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D701D5E0A146@SUEX07-MBX-04.ad.syr.edu>



> -----Original Message-----
> >
> > So the "every router" statement has now dwindled to "most large ISP
> routers and about half of small ISP routers, which together compose
> about 10% of the world's routers." 
> >
> 
> Ah, yes, but without the routers in that 10% we wouldn't have
> an Internet to even be discussing.  They are more important
> than the rest of the 90%.

Of course. But facts matter. If you mean "the world's most important routers" say that. Don't say, "every router." 



From Lee at Dilkie.com  Fri Apr 16 12:43:20 2010
From: Lee at Dilkie.com (Lee Dilkie)
Date: Fri, 16 Apr 2010 12:43:20 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA635@Skyhawk>
References: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA635@Skyhawk>
Message-ID: <4BC893A8.80000@Dilkie.com>


On 4/16/2010 11:33 AM, Chris Engel wrote:

.. snip..

> The bottom line is that people deploy NAT on thier OWN networks
> because they CHOOSE to do so. Other people interact with those
> networks because they CHOOSE to do so. Vendors offer NAT support in
> thier products and services because they CHOOSE to be marketable to
> all those customers.
>
and you, my dear friend, who choose to deploy a network without NAT and
without the cost burden placed on the vendor selling their product to
you... You end up paying for both the nat development the vendor had to
do and the ongoing support costs he has with his nat customers. It may
be that he *choose* to sell to natted customers, but it's you who ends
up paying for that nat guy's decision to both, deploy nat *and* have the
nerve to expect more than simple http to function.

that's the crux of the issue. Nat costs money, NRE and support, and
everyone pays. It's billions of dollars that could have been spent in
more useful pursuits.


-lee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100416/b94fb23b/attachment.htm>

From mueller at syr.edu  Fri Apr 16 12:48:46 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Fri, 16 Apr 2010 12:48:46 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <4BC765C1.3040601@ipinc.net>
References: <20100413172714.M35473@fast-serv.com>
	<4BC4B1B6.7060804@ipinc.net><A153ECC6B3414765B321340BCE7AFC16@changeip.com>
	<r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>
	<k2if65fb55e1004141335y1a73bda2n17dd4e42218ad45d@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D701D5FCA513@SUEX07-MBX-04.ad.syr.edu>
	<17838240D9A5544AAA5FF95F8D52031607EE0EA8@ad-exh01.adhost.lan>
	<75822E125BCB994F8446858C4B19F0D701D5FCA517@SUEX07-MBX-04.ad.syr.edu>
	<8692A26B68F04BC7A404E3579E7B0171@changeip.com>
	<1271282125.5224.80.camel@ggiesen-workstation.netsurf.net>
	<75822E125BCB994F8446858C4B19F0D701D5FCA520@SUEX07-MBX-04.ad.syr.edu>
	<4BC765C1.3040601@ipinc.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D701D5E0A148@SUEX07-MBX-04.ad.syr.edu>

> -----Original Message-----
> >
> > What's wrong with offering the smaller ISP something smaller than a
> >/32 at a lower price?
> 
> 
> I for one would prefer to NOT modify minimum allocation policy, if
> for no other reason that I can do a "show ipv6" in my router and know
> immediately that if a particular IPv6 address is within a /32
> advertisement, then there's an ISP involved.

I understand the motivation, but then you are using the size of an address block to convey semantic meaning ("this is an ISP"). Seems like a odd combination of functions to me. Shouldn't those two things be separated and how difficult can it be to separate them? Also, is the distinction between ISP and organization that clear in all cases?

> And it's unnecessary.  IPv6 does not use the economics of a
> scarce resource, like IPv4 does.  We have plenty of it.

For now. If we continue to waste billions of addresses in order to perform an unrelated identification function, maybe not after a decade or so. 

> I'd support a fee waiver to small ISP's who have an active and
> utilized sub- /20 of IPv4.  Ultimately, when IPv4 becomes obsolete
> and the RIR ceases to track it, and the entire issue of who owns
> what IPv4 block becomes nothing more than historical interest,
> the waiver will naturally disappear.
 
Not a bad idea in the short term but if the small ISP screeches about paying those fees now, won't they do the same then? 



From owen at delong.com  Fri Apr 16 13:01:38 2010
From: owen at delong.com (Owen DeLong)
Date: Fri, 16 Apr 2010 10:01:38 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5E0A148@SUEX07-MBX-04.ad.syr.edu>
References: <20100413172714.M35473@fast-serv.com>
	<4BC4B1B6.7060804@ipinc.net><A153ECC6B3414765B321340BCE7AFC16@changeip.com>
	<r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>
	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>
	<k2if65fb55e1004141335y1a73bda2n17dd4e42218ad45d@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D701D5FCA513@SUEX07-MBX-04.ad.syr.edu>
	<17838240D9A5544AAA5FF95F8D52031607EE0EA8@ad-exh01.adhost.lan>
	<75822E125BCB994F8446858C4B19F0D701D5FCA517@SUEX07-MBX-04.ad.syr.edu>
	<8692A26B68F04BC7A404E3579E7B0171@changeip.com>
	<1271282125.5224.80.camel@ggiesen-workstation.netsurf.net>
	<75822E125BCB994F8446858C4B19F0D701D5FCA520@SUEX07-MBX-04.ad.syr.edu>
	<4BC765C1.3040601@ipinc.net>
	<75822E125BCB994F8446858C4B19F0D701D5E0A148@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <09575063-0276-4EDF-A011-F29D318F14D7@delong.com>


On Apr 16, 2010, at 9:48 AM, Milton L Mueller wrote:

>> -----Original Message-----
>>> 
>>> What's wrong with offering the smaller ISP something smaller than a
>>> /32 at a lower price?
>> 
>> 
>> I for one would prefer to NOT modify minimum allocation policy, if
>> for no other reason that I can do a "show ipv6" in my router and know
>> immediately that if a particular IPv6 address is within a /32
>> advertisement, then there's an ISP involved.
> 
> I understand the motivation, but then you are using the size of an address block to convey semantic meaning ("this is an ISP"). Seems like a odd combination of functions to me. Shouldn't those two things be separated and how difficult can it be to separate them? Also, is the distinction between ISP and organization that clear in all cases?
> 
This doesn't make sense, actually.  Nothing prevents an end user with a large number of sites or a large network from getting a /32.

Now, if what he's really trying to say is that any prefix longer than a /32 is an end-user or an ISP doing something less than ideal, that's actually true as things stand now, but, I think that's the only valid conclusion from prefix size with current policy.  Of course a policy change can only reduce the conclusions that can be drawn since it won't affect past allocations or assignments.

>> I'd support a fee waiver to small ISP's who have an active and
>> utilized sub- /20 of IPv4.  Ultimately, when IPv4 becomes obsolete
>> and the RIR ceases to track it, and the entire issue of who owns
>> what IPv4 block becomes nothing more than historical interest,
>> the waiver will naturally disappear.
> 
> Not a bad idea in the short term but if the small ISP screeches about paying those fees now, won't they do the same then? 
> 
More than likely, but, I do think this would be a good short term solution while we have a longer discussion about the best way to address the issue in the long run.

I will point out, however, that a fee discussion belongs on arin-discuss as fees are a member topic and not a policy topic.


Owen



From jmaimon at chl.com  Fri Apr 16 13:03:43 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Fri, 16 Apr 2010 13:03:43 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5E0A146@SUEX07-MBX-04.ad.syr.edu>
References: <20100413172714.M35473@fast-serv.com><4BC4B1B6.7060804@ipinc.net>	<A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>	<4BC62352.2090202@rollernet.us>	<75822E125BCB994F8446858C4B19F0D701D5FCA511@SUEX07-MBX-04.ad.syr.edu>	<4BC62E81.3040600@ipinc.net>	<75822E125BCB994F8446858C4B19F0D701D5FCA516@SUEX07-MBX-04.ad.syr.edu>	<4BC63FB7.5000404@umn.edu>	<75822E125BCB994F8446858C4B19F0D701D5FCA522@SUEX07-MBX-04.ad.syr.edu>	<4BC74C57.9010602@ipinc.net>
	<75822E125BCB994F8446858C4B19F0D701D5E0A146@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4BC8986F.5080807@chl.com>



Milton L Mueller wrote:
>
>
>> -----Original Message-----
>>>
>>> So the "every router" statement has now dwindled to "most large ISP
>> routers and about half of small ISP routers, which together compose
>> about 10% of the world's routers."
>>>
>>
>> Ah, yes, but without the routers in that 10% we wouldn't have
>> an Internet to even be discussing.  They are more important
>> than the rest of the 90%.
>
> Of course. But facts matter. If you mean "the world's most important routers" say that. Don't say, "every router."
>

If you view it in dollars, it may also work out to most, as in most 
dollars spent for routers intended to hold full tables from time of 
purchase until depreciation.

I would expect this casts things in sufficient economic terms to render 
it fit for academic study.

Joe





From jmaimon at chl.com  Fri Apr 16 12:59:03 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Fri, 16 Apr 2010 12:59:03 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <28E139F46D45AF49A31950F88C49745805C9DB6C@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745805C9DB6C@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4BC89757.8050108@chl.com>



michael.dillon at bt.com wrote:
>

>> Despite what you guys may think, NAT is an attractive
>> solution to many people to address certain specific issues.
>
> Sure. But NAT will be much rarer in IPv6 and mostly on
> corporate gateways, not the kind of standard feature
> that it is today. In any case, are there any NAT implementations
> available yet for IPv6?
>
> --Michael Dillon

nat = napt66;

I am unconvinced that stub/end/residential/consumer user deployment via 
DHCP-PD or whatever iteration of the solution to the problem of 
extending routing to these classes of user's device(s) (which to be 
precise is a form of inter-autonomous system routing) will prove more 
satisfactory and successful when compared to the complete workaround to 
the problem (while creating others) that nat allows for.

The market, consisting of users, providers, manufactures and default 
"default settings" will decide this one, as they did for IPv4.

Eventually.

However, it is a fact that there are many people who continue to assert 
that nat has positive security implications for them.

And others have posted still other motivations for nat that even readily 
available globally unique addresses may not obviate to the complete 
satisfaction of potential nat users.

So while I expect that nat utilization will almost certainly lessen from 
its current state of near universal presence, perhaps to the point of 
rarity (at least for the end user masses), I neither believe it is fated 
for extinction, nor do I believe behaviors assuming or intending 
extinction are prudent.

I do believe it is worthwhile to invest in policies and technologies 
that remove or lessen motivations for nat. I do not consider my views 
contradictory.

Joe





From bill at herrin.us  Fri Apr 16 13:35:01 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 16 Apr 2010 13:35:01 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5E0A146@SUEX07-MBX-04.ad.syr.edu>
References: <20100413172714.M35473@fast-serv.com>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>
	<4BC62352.2090202@rollernet.us>
	<75822E125BCB994F8446858C4B19F0D701D5FCA511@SUEX07-MBX-04.ad.syr.edu>
	<4BC62E81.3040600@ipinc.net>
	<75822E125BCB994F8446858C4B19F0D701D5FCA516@SUEX07-MBX-04.ad.syr.edu>
	<4BC63FB7.5000404@umn.edu>
	<75822E125BCB994F8446858C4B19F0D701D5FCA522@SUEX07-MBX-04.ad.syr.edu>
	<4BC74C57.9010602@ipinc.net>
	<75822E125BCB994F8446858C4B19F0D701D5E0A146@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <z2s3c3e3fca1004161035yfa9de1e8oe5ee17c247860627@mail.gmail.com>

On Fri, Apr 16, 2010 at 12:36 PM, Milton L Mueller <mueller at syr.edu> wrote:
>> > So the "every router" statement has now dwindled to "most large ISP
>> routers and about half of small ISP routers, which together compose
>> about 10% of the world's routers."
>> Ah, yes, but without the routers in that 10% we wouldn't have
>> an Internet to even be discussing. ?They are more important
>> than the rest of the 90%.
> Of course. But facts matter. If you mean "the world's most important routers" say that. Don't say, "every router."

Milton,

IIRC, the phrase used was "everyone else's BGP router," where "BGP
router" is slightly sloppy but commonly understood shorthand for a
member of the specific set of routers we're concerned with - those
which carry all the routes announced into the public Internet via
eBGP.

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 mueller at syr.edu  Fri Apr 16 15:52:17 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Fri, 16 Apr 2010 15:52:17 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <z2s3c3e3fca1004161035yfa9de1e8oe5ee17c247860627@mail.gmail.com>
References: <20100413172714.M35473@fast-serv.com>
	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>
	<4BC62352.2090202@rollernet.us>
	<75822E125BCB994F8446858C4B19F0D701D5FCA511@SUEX07-MBX-04.ad.syr.edu>
	<4BC62E81.3040600@ipinc.net>
	<75822E125BCB994F8446858C4B19F0D701D5FCA516@SUEX07-MBX-04.ad.syr.edu>
	<4BC63FB7.5000404@umn.edu>
	<75822E125BCB994F8446858C4B19F0D701D5FCA522@SUEX07-MBX-04.ad.syr.edu>
	<4BC74C57.9010602@ipinc.net>
	<75822E125BCB994F8446858C4B19F0D701D5E0A146@SUEX07-MBX-04.ad.syr.edu>
	<z2s3c3e3fca1004161035yfa9de1e8oe5ee17c247860627@mail.gmail.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D701D5FCA538@SUEX07-MBX-04.ad.syr.edu>

> -----Original Message-----
> 
> Milton,
> 
> IIRC, the phrase used was "everyone else's BGP router," where "BGP
> router" is slightly sloppy but commonly understood shorthand for a
> member of the specific set of routers we're concerned with - those
> which carry all the routes announced into the public Internet via
> eBGP.
> 

Regards to you for clarifying. Assumptions about what is "commonly understood" only go so far when one is dealing with global public policy and an expanding base of constituents and participants. I think it's good for everyone involved when these forms of "shorthand", whether they are only "slightly" or "very" sloppy, are probed and made more explicit. And (Mr. Woodcock), the person who reveals and even deliberately probes at these assumptions is not necessarily wasting time. He may be making it possible for the discourse to be broadened and more inclusive, and more connected to analogous conversations in other policy domains. 

--MM


From woody at pch.net  Fri Apr 16 13:34:44 2010
From: woody at pch.net (Bill Woodcock)
Date: Fri, 16 Apr 2010 10:34:44 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <20281658-8F97-4BFC-90D1-49DF6F639237@delong.com>
References: <20100413172714.M35473@fast-serv.com>
	<4BC4B1B6.7060804@ipinc.net><A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu><1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry><75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu><k2if65fb55e1004141335y1a73bda2n17dd4e42218ad45d@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA513@SUEX07-MBX-04.ad.syr.edu>
	<1665735650-1271281000-cardhu_decombobulator_blackberry.rim.net-452158009-@bda040.bisx.prod.on.blackberry>
	<75822E125BCB994F8446858C4B19F0D701D5FCA51B@SUEX07-MBX-04.ad.syr.edu>
	<20281658-8F97-4BFC-90D1-49DF6F639237@delong.com>
Message-ID: <763F5F2A-D0BC-4E82-8007-381AD3A3D666@pch.net>

On Apr 14, 2010, at 2:47 PM, Milton L Mueller wrote:
> Bill, your hostility is wearisome and pointless.

Milton, with the benefit of the perspective of a few hours' sleep, my reply was very ill-considered.  You have my unqualified apology.

                                -Bill




-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100416/5df00892/attachment.sig>

From cengel at sponsordirect.com  Fri Apr 16 17:55:18 2010
From: cengel at sponsordirect.com (Chris Engel)
Date: Fri, 16 Apr 2010 17:55:18 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <mailman.1150.1271372183.28982.arin-ppml@arin.net>
Message-ID: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA639@Skyhawk>


As I see it, the debate over NAT is largely unresolvable because the people in either camp have mutualy exclusive/contradictory goals and values.

Those who value NAT, outside of it's role in address conservation (which is no longer applicable in IPv6), value it expressly because it provides a layer of abstraction and obfuscation between thier internal and external network archtecture.

Those who find NAT harmful and objectionable do so specificaly because it retards transparency into internal archetectures.

These are competing goals. Though I think they both have thier values, but you can't impliment both at the same time in the same space.

I believe that whichever goal has greater value is HIGHLY dependant upon the specific situation it applied to....and that is best left upto the individual directly responsible for that situation to determine...... and I believe that it's important that we have a net and address policy which is flexible enough to support such individuals REGARDLESS of which path they choose.

I think that is the gist of the wisdom which David Farmer brought to this discussion here.... having policy that can support a diverse community of users.

I have no problem with anyone drafting policies, protocols, rfc's or technologies designed to reduce the NECCESSITY for deploying NAT.... but I have a HUGE problem when people start talking about measures aimed toward retarding the ABILITY to deploy NAT for those who value it. I don't believe the later has any proper place in address policy discussion. My 2 cents.


Christopher Engel




From farmer at umn.edu  Fri Apr 16 18:43:01 2010
From: farmer at umn.edu (David Farmer)
Date: Fri, 16 Apr 2010 17:43:01 -0500
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <4BC89757.8050108@chl.com>
References: <28E139F46D45AF49A31950F88C49745805C9DB6C@E03MVZ2-UKDY.domain1.systemhost.net>
	<4BC89757.8050108@chl.com>
Message-ID: <4BC8E7F5.1050405@umn.edu>

Thank you Joe,

I believe this is a much more appropriate attitude to base address 
policy regarding NAT and IPv6 on.

Joe Maimon wrote:

> nat = napt66;
> 
> I am unconvinced that stub/end/residential/consumer user deployment via 
> DHCP-PD or whatever iteration of the solution to the problem of 
> extending routing to these classes of user's device(s) (which to be 
> precise is a form of inter-autonomous system routing) will prove more 
> satisfactory and successful when compared to the complete workaround to 
> the problem (while creating others) that nat allows for.
>
> The market, consisting of users, providers, manufactures and default 
> "default settings" will decide this one, as they did for IPv4.
> 
> Eventually.

Yes, the market should decide this, not a policy fiat from ARIN or even 
the IETF.

I think a NAT66 device, requesting via DHCP-PD or being statically 
assigned at least a /64 or maybe in some cases a larger block and doing 
NAT addresses to address translation, not NAPT, could be very 
interesting.  Such a solution could be useful in a number of situation, 
and in that case the use of NAT has nothing to do with address conservation.

Embracing NAT as a possible solution, rather than treating it as 
something to be exterminated, could lead to some interesting solutions.

> However, it is a fact that there are many people who continue to assert 
> that nat has positive security implications for them.
> 
> And others have posted still other motivations for nat that even readily 
> available globally unique addresses may not obviate to the complete 
> satisfaction of potential nat users.
> 
> So while I expect that nat utilization will almost certainly lessen from 
> its current state of near universal presence, perhaps to the point of 
> rarity (at least for the end user masses), I neither believe it is fated 
> for extinction, nor do I believe behaviors assuming or intending 
> extinction are prudent.

Yes, one can hope that since IPv6 no longer has a need to conserve 
addresses, that the near universal presence of NAT will fade.  And, only 
those that have some other motivations to use NAT will inflect its costs 
on themselves and the rest of us.

> I do believe it is worthwhile to invest in policies and technologies 
> that remove or lessen motivations for nat. I do not consider my views 
> contradictory.

I agree it is a worthy policy goal to actively encourage non-NAT 
solutions.  However, it is important for that be done through true 
incentives for non-NAT solutions and not by creating artificial 
disincentives in policy for NAT solutions, because a majority dislikes 
NAT.

Again, thank you.

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


From tedm at ipinc.net  Fri Apr 16 19:00:32 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 16 Apr 2010 16:00:32 -0700
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA639@Skyhawk>
References: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA639@Skyhawk>
Message-ID: <4BC8EC10.1040100@ipinc.net>

Cris (and the pro-IPv6 NAT supporters out there)

I deployed IPv4 NAT back in 1996 (or earlier, I forget) in a production 
environment.  The way I did it - and the ONLY way that ANYONE could do 
it at that time - was by applying a very large, convoluted set of 
patches to the FreeBSD 3 kernel and compiling the nat daemon.

At that time I'd estimate the sum total number of sites on the
Internet that had NAT deployed were probably under 200.  Cisco didn't
have it, even Linux didn't have it.  Hardly anyone used FreeBSD or
even Linux servers as routers at leaf-node sites.

As cool as it was, as problem-solving as it was, and despite the
fact that it was completely free, because of the difficulty of building
a NAT device, NAT was beyond the reach of the average administrator.

Once Cisco added NAT code into IOS 11.2  (only on VERY few platforms,
the 2501 was one of them, and we had one) this brought it within reach 
of a few more admins.

Once Linksys start building their devices and selling them for under
$100, then it brought it to within the reach of the masses.

The point here is that the masses out there can ONLY implement 
solutions, and that INCLUDES nat, that are "black box" solutions
built and sold by people who know a lot more than they do.

Sooner or later all ISP's will supply IPv6 to their customers.  Their
customers will utilize IPv6 with black boxes built and sold by
Cisco, Linksys, Netgear, Dlink and so on.

If those networking companies unilaterally reject IPv6 NAT, then your
average admin WILL NOT deploy it.  And I think this will certainly 
happen unless the major networking standards bodies support it.

14 years ago your average network admin who wanted to get "online"
thought RFC was a misspelling of the initials of Colonel Sanders's
restaurant chain.  They couldn't care less that whatever black box
they used wasn't RFC compliant.  Today, it's a lot different.  Unless
IPv6 NAT is accepted by IETF and standardized, none of these networking
companies will touch it because then when things break, they will
lose their shirt on taking the returns.  Besides the returns, the 
companies I named who ARE selling those solutions all have their fingers 
in networking applications that users run that would work
BETTER on a NAT-less IPv6 Internet.

They will certainly sell IPv6 firewall boxes.  Those boxes will 
certainly provide a layer of abstraction and obfuscation between their 
internal and external network architecture WITHOUT using IPv6 NAT.
And the vast unwashed masses of network admins out there won't give
a tinker's damn that this layer isn't provided by IPv6 NAT.  And
because those boxes won't be running IPv6 NAT, this will relegate
the status of IPv6 NAT implementations into that of qmail - a piece
of software that has a core group of fanatics who cannot understand
why after a decade the rest of the Internet hasn't come to it's
senses and seen how wonderful their program is.

Ted


On 4/16/2010 2:55 PM, Chris Engel wrote:
>
> As I see it, the debate over NAT is largely unresolvable because the people in either camp have mutualy exclusive/contradictory goals and values.
>
> Those who value NAT, outside of it's role in address conservation (which is no longer applicable in IPv6), value it expressly because it provides a layer of abstraction and obfuscation between thier internal and external network archtecture.
>
> Those who find NAT harmful and objectionable do so specificaly because it retards transparency into internal archetectures.
>
> These are competing goals. Though I think they both have thier values, but you can't impliment both at the same time in the same space.
>
> I believe that whichever goal has greater value is HIGHLY dependant upon the specific situation it applied to....and that is best left upto the individual directly responsible for that situation to determine...... and I believe that it's important that we have a net and address policy which is flexible enough to support such individuals REGARDLESS of which path they choose.
>
> I think that is the gist of the wisdom which David Farmer brought to this discussion here.... having policy that can support a diverse community of users.
>
> I have no problem with anyone drafting policies, protocols, rfc's or technologies designed to reduce the NECCESSITY for deploying NAT.... but I have a HUGE problem when people start talking about measures aimed toward retarding the ABILITY to deploy NAT for those who value it. I don't believe the later has any proper place in address policy discussion. My 2 cents.
>
>
> Christopher Engel
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From marquis at roble.com  Sat Apr 17 13:07:24 2010
From: marquis at roble.com (Roger Marquis)
Date: Sat, 17 Apr 2010 10:07:24 -0700 (PDT)
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <mailman.5.1271520002.5489.arin-ppml@arin.net>
References: <mailman.5.1271520002.5489.arin-ppml@arin.net>
Message-ID: <20100417170724.9618B2B2121@mx5.roble.com>

Ted Mittelstaedt wrote:
> The point here is that the masses out there can ONLY implement
> solutions, and that INCLUDES nat, that are "black box" solutions
> built and sold by people who know a lot more than they do.

Good point.

> If those networking companies unilaterally reject IPv6 NAT, then your
> average admin WILL NOT deploy it.  And I think this will certainly
> happen unless the major networking standards bodies support it.

The "customer is always wrong" model hasn't proven successful to-date.  What are you
proposing that might change that equation?

> Besides the returns, the companies I named who ARE selling those solutions
> all have their fingers in networking applications that users run that would
> work BETTER on a NAT-less IPv6 Internet.

A majority of security professionals I've encountered over the years (not the same as
network professionals) are of the opinion that the statefulness required to secure
SIP-like protocols is essential, and, if absence of a NAT option enables and/or
encourages:

  1) less robust stateful inspection (as expected of cheap CPE),
  2) or it enables disabling or mis-configuration of stateful inspection
     (as we've already seen is not uncommon)

then, from a security perspective, lack of a standardized NAT in IPv6 will result in
less security.  Fewer options, less security, not a recipie for success.

> They will certainly sell IPv6 firewall boxes.  Those boxes will
> certainly provide a layer of abstraction and obfuscation between their
> internal and external network architecture WITHOUT using IPv6 NAT.

That's an opinion of course, and one clearly made without taking note of field
testing.  We have had 10 years of field testing, however, and the results are
unequivocal i.e., IPv6 adoption is being held up by the lack of a NAT standard.  In
considering why we have no standardized NAT it is important to note that the
arguments against NAT are characterized by:

  1) lack of concern that theories regarding the usefulness of NAT in IPv6 have not
  been supported by field testing,

  2) lack of concern that theories regarding the usefulness of NAT in IPv6 are not
  supported by IT security professionals,

  3) are notable by the repetition of general and non-technical statements like "a piece
  of software that has a core group of fanatics who cannot understand",

  4) are also notable by avoidance of discussions regarding low-level dissection of
  the mechanisms by which NAT and stateful inspection are inseparable.

All of which indicates NAT-detraction is strongly driven by profit motives of those
holding and hoarding IPv4 addresses.

Roger Marquis


From scottleibrand at gmail.com  Sat Apr 17 14:45:52 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Sat, 17 Apr 2010 14:45:52 -0400
Subject: [arin-ppml] [arin-discuss] IPv4 allocation conundrum
In-Reply-To: <466726541.23031.1271515991616.JavaMail.root@zimbra.network1.net>
References: <466726541.23031.1271515991616.JavaMail.root@zimbra.network1.net>
Message-ID: <89BBE721-9373-4C98-B904-013997F4E0DC@gmail.com>

Randy,

This seems like a legitimate problem that could be addressed via a  
policy change, but given how close we are to depletion, any viable  
solution for IPv4 would need to work in a post-depletion transfer- 
market world. Do you have any specific suggestions for changes to the  
NRPM that would fix this?

If so, please go ahead and submit a policy proposal, and the AC will  
be happy to work with you to make sure it does what you want without  
too many unintended side effects. Or, if you don't really know where  
to start, we can work with you to draft it. I'll be happy to assist.

Will you be participating (in person or remotely) at the ARIN Public  
Policy meeting in Toronto this week? I'd encourage you to take a look  
at the draft policies under discussion with an eye toward how this  
kind of thing should work in IPv6.

Thanks,
Scott

On Apr 17, 2010, at 10:53 AM, Randy Carpenter <rcarpen at network1.net>  
wrote:

>
> I think the fact that ARIN policy states that we need to renumber  
> from private to public, and then renumber again is completely  
> stupid. Allocations from ARIN should be on a *needs* basis only.
>
>
>
> -Randy
>
> --
> | Randy Carpenter
> | V.P., IT Services
> | First Network Group, Inc.
> | Wapakoneta, OH
> | (419)739-9240, x1
> --
>
>
> ----- "Lee Howard" <spiffnolee at yahoo.com> wrote:
>
>> Thanks to you both for bringing this to the mailing list.  If we need
>> to make
>> policy changes, we should move it to the PPML.
>>
>> Randy, I'm interested to understand if the upstream providers told  
>> you
>> any
>> reason for not providing address space?  In North America, that's
>> unusual.
>>
>> Jacob, I'm interested in your topology.  I don't understand your need
>> for
>> /23 and /24.
>>
>> Generally, renumbering needs to be easier.  It's a major point in  
>> this
>> thread,
>> in the IPv6 NAT thread, and in many proposals for smaller
>> Provider-Independent
>> allocations.  I see a business opportunity for someone to write an
>> address
>> management system that will provide updated configuration files for
>> common
>> firewalls, DNS servers (forward and reverse), ACLs, VPN consoles, and
>> monitoring systems.
>>
>> Lee
>>
>>
>>
>> ----- Original Message ----
>>> From: Jacob Epstein <jake at recol.com>
>>> To: Randy Carpenter <rcarpen at network1.net>
>>> Cc: arin-discuss at arin.net
>>> Sent: Sat, April 17, 2010 5:28:26 AM
>>> Subject: Re: [arin-discuss] IPv4 allocation conundrum
>>>
>>> Hi Randy,
>>
>> I am in a similar situation, but already have a /20 allocation.
>>> I can use more public space, but due to our applications which need
>> large blocks
>>> (/23 and /24) we end up with open space that we can not chop up and
>> reallocate.
>>> For example our broadband Static IP Space or hosting space which are
>> flat and
>>> not subnetted. Although we have returned /21 of space to our
>> upstreames since
>>> our first allocation in 2003, we have been denied based on the 80%
>> use of all IP
>>> space versus allocations based on routing and application.
>>
>> FYI, we
>>> orginally applied for a /19 but were advised to return /21 of space
>> and reaply
>>> which we did but we denied due to change in policies. So is life!
>>
>> My
>>> understanding is that your client should be able qualify for their
>> first Arin
>>> allocation. They should then work on moving upstream provided IP
>> over to the
>>> Allocation so that they can return upstream space. I haven't seen a
>> rule on
>>> this, but its is wise to do so in case you lose or want to change
>> upstream
>>> providers. Many of us change upstream providers to get better deals
>> or move into
>>> an Exchange Point (IX) peering arrangement.
>>
>> Has your customer looked at
>>> the end user allocation process. Here is a link
>>
>>
>>>
>> href="https://www.arin.net/resources/request/ 
>> ipv4_initial_assign.html"
>>
>>> target=_blank
>>>> https://www.arin.net/resources/request/ipv4_initial_assign.html
>>
>> I
>>> did try this in order to open a new datacenter with a /23, and could
>> not get
>>> that based on utilization of the current /20. It seems the process
>> doesn't care
>>> about the need. So to get us going, I requested a /23 from a new
>> upstream
>>> provider to get our business. Later on after we are operational, we
>> will migrate
>>> some of our /20 allocation, but its not going to be easy on current
>> customers
>>> that will have to be assigned new IP addresses. (DNS Changes, VPN
>> Changes,
>>> Security (Access Control) changes. One customer has 80 remote
>>> offices!
>>
>> But it seems to me that there has to be a way for smaller
>>> providers with no allocations to obtain blocks and then retun
>> upstream blocks as
>>> part of the process.
>>
>> Seems that if not, smaller providers starting up or
>>> in our case focused on conservation should go away while the large
>> telcos and
>>> broadband provides either "suck the pool dry" or rest on large
>> allocations they
>>> got years ago.
>>
>> So something sounds strange since need upstream blocks to
>>> get into the business. The Arin contact seems to be saying no one
>> gets their
>>> first allocation based on your customer's scenario as I read it
>> which is to get
>>> the first allocation. Maybe they do not qualify for /19 but could
>> for /20 or
>>> /21.
>>
>> FYI, we have been working on IPv6. The new data center will be
>>> native IPv6.
>>
>> Good Luck,
>>
>>
>> Jake
>>
>> -- Jacob Epstein, Chief 
>>> Technology Officer
>> RECOL, LLC - An Internet Solutions Provider
>> web:
>>> http://www.recol.net
>> email:
>>> href="mailto:jake at recol.com">jake at recol.com
>>
>>
>>
>> Randy Carpenter
>>> wrote:
>>> I am working with a new customer who is in a bit of a
>>> pickle...
>>>
>>> They are an ISP and VoIP provider whose upstream
>>> provider wouldn't (or couldn't) give them many addresses.
>>> They resorted
>>> to using NATed private IPs for most of their network, which is
>> causing problems
>>> for their end user customers.
>>>
>>> Now that we are working with
>>> them, I am trying to find a solution to get them public IPs. They
>> are also soon
>>> to be multi-homed (They have 2 connections, but no BGP yet). As an
>> ISP, it would
>>> be best for them to have PI space.
>>>
>>> The issue is that one of the
>>> requirements for getting PI space from ARIN is that you are already
>> using Public
>>> space that was assigned to you from an upstream provider. I spoke
>> with someone
>>> from ARIN who says there is no way around this. The need around a
>> /19 of space,
>>> and I cannot find any way to get it for them. The upstream providers
>> refuse to
>>> give them any.
>>>
>>> What can be done about this?  Would would
>>> there be a requirement of already using someone else's IP space to
>> get your own?
>>> That seems like a complete waste of time, effort, money, and IPs!
>>>
>>>
>>> -Randy
>>>
>>> --
>>> | Randy Carpenter
>>> | V.P., IT
>>> Services
>>> | First Network Group, Inc.
>>> | RHCE
>>> |
>>> (419)739-9240, x1
>>> --
>>>
>>>
>>> _______________________________________________
>>> ARIN-Discuss
>>> You
>>> are receiving this message because you are subscribed to
>>> the ARIN
>>> Discussion Mailing List (
>>> href="mailto:ARIN-discuss at arin.net">ARIN-discuss at arin.net).
>>>
>>> Unsubscribe or manage your mailing list subscription at:
>>>
>>> http://lists.arin.net/mailman/listinfo/arin-discuss
>>> Please contact
>>> ymailto="mailto:info at arin.net"
>> href="mailto:info at arin.net">info at arin.net if
>>> you experience any issues.
>>>
>>>
>>
>>
>> _______________________________________________
>> ARIN-Discuss
>> You
>>> are receiving this message because you are subscribed to
>> the ARIN Discussion
>>> Mailing List (
>>> href="mailto:ARIN-discuss at arin.net">ARIN-discuss at arin.net).
>> Unsubscribe
>>> or manage your mailing list subscription at:
>>
>>> href="http://lists.arin.net/mailman/listinfo/arin-discuss"
>> target=_blank
>>>> http://lists.arin.net/mailman/listinfo/arin-discuss
>> Please contact
>>> ymailto="mailto:info at arin.net"
>> href="mailto:info at arin.net">info at arin.net if
>>> you experience any issues.
> _______________________________________________
> ARIN-Discuss
> You are receiving this message because you are subscribed to
> the ARIN Discussion Mailing List (ARIN-discuss at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-discuss
> Please contact info at arin.net if you experience any issues.


From michael.dillon at bt.com  Sat Apr 17 16:36:39 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Sat, 17 Apr 2010 21:36:39 +0100
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <4BC8EC10.1040100@ipinc.net>
Message-ID: <28E139F46D45AF49A31950F88C49745805C9DC0C@E03MVZ2-UKDY.domain1.systemhost.net>


> I deployed IPv4 NAT back in 1996 (or earlier, I forget) in a 
> production environment.  The way I did it - and the ONLY way 
> that ANYONE could do it at that time - was by applying a very 
> large, convoluted set of patches to the FreeBSD 3 kernel and 
> compiling the nat daemon.

At that time I was running TIS firewalls toolkit on a FreeBSD 2
system. It was not NAT, but to the outside world, the application
layer proxies did present multiple machines inside the network
on a single IP address, just like NAT did. And an external machine
could not pass packets to an internal one, unless a proxy was
specifically configured to allow it, just like on a NAT box.

--Michael Dillon




From steve at ibctech.ca  Sat Apr 17 14:50:16 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Sat, 17 Apr 2010 14:50:16 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <763F5F2A-D0BC-4E82-8007-381AD3A3D666@pch.net>
References: <20100413172714.M35473@fast-serv.com>	<4BC4B1B6.7060804@ipinc.net><A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu><1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry><75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu><k2if65fb55e1004141335y1a73bda2n17dd4e42218ad45d@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA513@SUEX07-MBX-04.ad.syr.edu>	<1665735650-1271281000-cardhu_decombobulator_blackberry.rim.net-452158009-@bda040.bisx.prod.on.blackberry>	<75822E125BCB994F8446858C4B19F0D701D5FCA51B@SUEX07-MBX-04.ad.syr.edu>	<20281658-8F97-4BFC-90D1-49DF6F639237@delong.com>
	<763F5F2A-D0BC-4E82-8007-381AD3A3D666@pch.net>
Message-ID: <4BCA02E8.30304@ibctech.ca>

On 2010.04.16 13:34, Bill Woodcock wrote:
> On Apr 14, 2010, at 2:47 PM, Milton L Mueller wrote:
>> Bill, your hostility is wearisome and pointless.
> 
> Milton, with the benefit of the perspective of a few hours' sleep, my reply was very ill-considered.  You have my unqualified apology.

...wow. Way to man up.

I've had days like that too.

It's always nice to see someone deal with an issue in this manner and
give themselves time to reflect, than to try to further an argument.

My respect.

Steve


From bill at herrin.us  Sat Apr 17 17:15:18 2010
From: bill at herrin.us (William Herrin)
Date: Sat, 17 Apr 2010 17:15:18 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <20100417170724.9618B2B2121@mx5.roble.com>
References: <mailman.5.1271520002.5489.arin-ppml@arin.net> 
	<20100417170724.9618B2B2121@mx5.roble.com>
Message-ID: <n2i3c3e3fca1004171415x74c0c09bx34998397b607baf2@mail.gmail.com>

On Sat, Apr 17, 2010 at 1:07 PM, Roger Marquis <marquis at roble.com> wrote:
> Ted Mittelstaedt wrote:
>> If those networking companies unilaterally reject IPv6 NAT, then your
>> average admin WILL NOT deploy it. ?And I think this will certainly
>> happen unless the major networking standards bodies support it.
>
> The "customer is always wrong" model hasn't proven successful to-date. ?What
> are you proposing that might change that equation?

Snirk. The customer isn't wrong Roger, merely uneducated. As Ted
knows, an enlightened customer will discard his phony needs for the
one true network plan. It's our job help these poor souls learn.

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 bill at herrin.us  Sat Apr 17 18:06:46 2010
From: bill at herrin.us (William Herrin)
Date: Sat, 17 Apr 2010 18:06:46 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5FCA538@SUEX07-MBX-04.ad.syr.edu>
References: <20100413172714.M35473@fast-serv.com>
	<75822E125BCB994F8446858C4B19F0D701D5FCA511@SUEX07-MBX-04.ad.syr.edu>
	<4BC62E81.3040600@ipinc.net>
	<75822E125BCB994F8446858C4B19F0D701D5FCA516@SUEX07-MBX-04.ad.syr.edu>
	<4BC63FB7.5000404@umn.edu>
	<75822E125BCB994F8446858C4B19F0D701D5FCA522@SUEX07-MBX-04.ad.syr.edu>
	<4BC74C57.9010602@ipinc.net>
	<75822E125BCB994F8446858C4B19F0D701D5E0A146@SUEX07-MBX-04.ad.syr.edu>
	<z2s3c3e3fca1004161035yfa9de1e8oe5ee17c247860627@mail.gmail.com> 
	<75822E125BCB994F8446858C4B19F0D701D5FCA538@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <m2q3c3e3fca1004171506p351f7914p97cba840853d2343@mail.gmail.com>

On Fri, Apr 16, 2010 at 3:52 PM, Milton L Mueller <mueller at syr.edu> wrote:
>> IIRC, the phrase used was "everyone else's BGP router," where "BGP
>> router" is slightly sloppy but commonly understood shorthand for a
>> member of the specific set of routers we're concerned with - those
>> which carry all the routes announced into the public Internet via
>> eBGP.
>
> Regards to you for clarifying. Assumptions about what is "commonly
> understood" only go so far when one is dealing with global public
> policy and an expanding base of constituents and participants.
> I think it's good for everyone involved when these forms of
> "shorthand", whether they are only "slightly" or "very" sloppy, are
> probed and made more explicit.

Hi Milton,

I find that clarifying a bit of jargon is often a welcome activity,
particularly if the jargon is confusing. The difference between
"allocation" and "assignment," for example, trips up almost everybody
at least once.

On the other hand, arguing for the banishment of jargon in a
discussion between knowledge domain experts is generally less than
effective -- it's too often impossible for the writer to determine
ahead of time just when two words of jargon would be helpfully
replaced with a dozen paragraphs of explanation with which the person
to whom he's directly responding is likely already familiar.

Nor is precision always helpful. We have at least three distinct
definitions floating around here as to exactly which "BGP routers" are
relevant. In each version, though, there are a large number of such
routers, they're owned by many organizations and collectively they
cost a ferocious amount of money.

There was no need to reopen that tired debate. Only the generality was
important to Ted's reminder that when providing ARIN allocations to
ISPs that find $2250/year challenging, "you consume the same amount of
routing resources on everyone else's BGP router on the Internet,"
regardless of the range of each address block announcement.

Regards,
Bill




-- 
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 bill at herrin.us  Sat Apr 17 18:19:05 2010
From: bill at herrin.us (William Herrin)
Date: Sat, 17 Apr 2010 18:19:05 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <m2q3c3e3fca1004171506p351f7914p97cba840853d2343@mail.gmail.com>
References: <20100413172714.M35473@fast-serv.com> <4BC62E81.3040600@ipinc.net>
	<75822E125BCB994F8446858C4B19F0D701D5FCA516@SUEX07-MBX-04.ad.syr.edu> 
	<4BC63FB7.5000404@umn.edu>
	<75822E125BCB994F8446858C4B19F0D701D5FCA522@SUEX07-MBX-04.ad.syr.edu>
	<4BC74C57.9010602@ipinc.net>
	<75822E125BCB994F8446858C4B19F0D701D5E0A146@SUEX07-MBX-04.ad.syr.edu>
	<z2s3c3e3fca1004161035yfa9de1e8oe5ee17c247860627@mail.gmail.com> 
	<75822E125BCB994F8446858C4B19F0D701D5FCA538@SUEX07-MBX-04.ad.syr.edu> 
	<m2q3c3e3fca1004171506p351f7914p97cba840853d2343@mail.gmail.com>
Message-ID: <z2u3c3e3fca1004171519i46dfc6b7y8ad32ee894ea71d4@mail.gmail.com>

On Sat, Apr 17, 2010 at 6:06 PM, William Herrin <bill at herrin.us> wrote:
> Only the generality was
> important to Ted's reminder that when providing ARIN allocations to
> ISPs that find $2250/year challenging, "you consume the same amount of
> routing resources on everyone else's BGP router on the Internet,"
> regardless of the range of each address block announcement.

That having been said, I have no objection to a policy change that
allows ISPs to request the same block sizes as end users, so long as
it's done in a way that doesn't make IPv6's TE (disaggregation)
filterability worse that it already is.

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 steve at ibctech.ca  Sat Apr 17 18:41:09 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Sat, 17 Apr 2010 18:41:09 -0400 (EDT)
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
Message-ID: <4719.69.49.38.10.1271544069.squirrel@webmail.ibctech.ca>

> On Sat, Apr 17, 2010 at 6:06 PM, William Herrin <bill at herrin.us> wrote:
>> Only the generality was
>> important to Ted's reminder that when providing ARIN allocations to
>> ISPs that find $2250/year challenging, "you consume the same amount of
>> routing resources on everyone else's BGP router on the Internet,"
>> regardless of the range of each address block announcement.
>
> That having been said, I have no objection to a policy change that
> allows ISPs to request the same block sizes as end users, so long as
> it's done in a way that doesn't make IPv6's TE (disaggregation)
> filterability worse that it already is.

...Amen. iow +1.

Steve


From bill at herrin.us  Sat Apr 17 19:11:55 2010
From: bill at herrin.us (William Herrin)
Date: Sat, 17 Apr 2010 19:11:55 -0400
Subject: [arin-ppml] Support proposal 2010-7
Message-ID: <j2q3c3e3fca1004171611u4d1933aaj2409c91ca871d5e1@mail.gmail.com>

Hi Folks,

I remind you that proposal 2010-7 will make it technologically -and-
organizationally possible for ISPs to prevent the bloated,
disaggregate mess that the IPv4 BGP table has become from spreading to
IPv6 even while mildly expanding the range of organizations which
qualify for IPv6 addresses direct from ARIN. By acting early, acting
now, 2010-7's smart grouping of address assignments can prevent the
formation of an unrestrained North American IPv6 "swamp."

When 2010-7 is brought to the floor Tuesday morning, I strongly
encourage you to stand in support.

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 JOHN at egh.com  Sat Apr 17 19:29:56 2010
From: JOHN at egh.com (John Santos)
Date: Sat, 17 Apr 2010 19:29:56 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <z2u3c3e3fca1004171519i46dfc6b7y8ad32ee894ea71d4@mail.gmail.com>
Message-ID: <1100417185325.9390A-100000@Ives.egh.com>

On Sat, 17 Apr 2010, William Herrin wrote:

> On Sat, Apr 17, 2010 at 6:06 PM, William Herrin <bill at herrin.us> wrote:
> > Only the generality was
> > important to Ted's reminder that when providing ARIN allocations to
> > ISPs that find $2250/year challenging, "you consume the same amount of
> > routing resources on everyone else's BGP router on the Internet,"
> > regardless of the range of each address block announcement.
> 
> That having been said, I have no objection to a policy change that
> allows ISPs to request the same block sizes as end users, so long as
> it's done in a way that doesn't make IPv6's TE (disaggregation)
> filterability worse that it already is.
> 
> Regards,
> Bill Herrin

Can we count on the RSA to enforce allocations?  How about policy
to allow ARIN to allocate at /40 to an extra-small ISP at the
same price as it would for a /40 PI assignment (Hope I've got
"allocation" and "assignment" right :-), although it is really
allocating a /32 from it's reserved space (such that the other
255 /40's in that /32 will never get allocated/assigned to anyone
else), and tell the recipient ISP 1) We've allocated a /32 for
you, but you are only allowed to use the 1st /48 of it.  2) Although
you may get away will routing the entire /32, some peers may
filter everything but the 1st /48 of it, so it won't be reliable.
3) If we catch you using any of the extra space, you are violating
the RSA and we'll come after you with a big stick and 4) if you
want more than the first /48, come back, upgrade from extra-small
to small, and we'll give you the rest of the /32 at the current
"small" rate, and -- cool -- you'll get 255 times the addresses
at four (?) times the cost and NO RENUMBERING!

This would pretty much rely on the honor system to get small
ISPs not to claim to be extra small, but the cost of getting
caught cheating would be very high.  Also, if you are in general
bad guy, you would be calling attention to yourself.  (I
think the guy stashing the 2nd getaway car for a bank robbery
would be pretty careful not to park it in front of a fire
hydrant.  His accomplices would probably be miffed if it got
booted or towed.)

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539



From bill at herrin.us  Sat Apr 17 19:46:04 2010
From: bill at herrin.us (William Herrin)
Date: Sat, 17 Apr 2010 19:46:04 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <1100417185325.9390A-100000@Ives.egh.com>
References: <z2u3c3e3fca1004171519i46dfc6b7y8ad32ee894ea71d4@mail.gmail.com> 
	<1100417185325.9390A-100000@Ives.egh.com>
Message-ID: <u2i3c3e3fca1004171646z5c8e070fpd8be3a3699230502@mail.gmail.com>

On Sat, Apr 17, 2010 at 7:29 PM, John Santos <JOHN at egh.com> wrote:
> On Sat, 17 Apr 2010, William Herrin wrote:
>
>> On Sat, Apr 17, 2010 at 6:06 PM, William Herrin <bill at herrin.us> wrote:
>> > Only the generality was
>> > important to Ted's reminder that when providing ARIN allocations to
>> > ISPs that find $2250/year challenging, "you consume the same amount of
>> > routing resources on everyone else's BGP router on the Internet,"
>> > regardless of the range of each address block announcement.
>>
>> That having been said, I have no objection to a policy change that
>> allows ISPs to request the same block sizes as end users, so long as
>> it's done in a way that doesn't make IPv6's TE (disaggregation)
>> filterability worse that it already is.
>
> Can we count on the RSA to enforce allocations? ?How about policy
> to allow ARIN to allocate at /40 to an extra-small ISP at the
> same price as it would for a /40 PI assignment (Hope I've got
> "allocation" and "assignment" right :-),

Actually, I'm a fan of proposal 2010-7 which is being offered at the
meeting next Tuesday. It would solve both problems articulated above.

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 bill at herrin.us  Sat Apr 17 20:04:49 2010
From: bill at herrin.us (William Herrin)
Date: Sat, 17 Apr 2010 20:04:49 -0400
Subject: [arin-ppml] Support proposal 2010-2: /24 end-user assignments
Message-ID: <p2j3c3e3fca1004171704hfdbab5bdgf7b01f6eb42088a4@mail.gmail.com>

Hi Folks,

Yesteryear's attempt to restrain the mess the IPv4 BGP table has
become by setting RIR minimums to /19 or /20 within particular /8's
utterly failed, largely because small multihomed end users had no
choice but to get /24's from their ISP -- in the middle of the
restricted /8's. Though late in the day, proposal 2010-2 largely
corrects this grave mistake for new assignments -without- expanding
who can introduce BGP routes into the table or how many IP addresses
anyone qualifies for. It is a major step forward and I strongly
encourage you to stand in support of it at the ARIN meeting next
Monday.

For your reference: https://www.arin.net/policy/proposals/2010_2.html

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 angellee at microsoft.com  Sat Apr 17 20:09:28 2010
From: angellee at microsoft.com (Angeline Lee (LCA))
Date: Sun, 18 Apr 2010 00:09:28 +0000
Subject: [arin-ppml] Microsoft Comments on ARIN Draft Proposal 2010-3
In-Reply-To: <6C681419CD870D4AAEBC9BFE60E72C653339FA10@TK5EX14MBXC122.redmond.corp.microsoft.com>
References: <6C681419CD870D4AAEBC9BFE60E72C653339FA10@TK5EX14MBXC122.redmond.corp.microsoft.com>
Message-ID: <6C681419CD870D4AAEBC9BFE60E72C65333A0492@TK5EX14MBXC122.redmond.corp.microsoft.com>

The Digital Crimes Unit within Microsoft investigates cybercrime attacks against our customers and services.  We rely on information from the ARIN database to correlate and identify the source of nefarious online activities.  As such, we oppose any policy change that would lessen the quantity and quality of information in the ARIN database.  While we recognize the importance of data privacy, we strongly believe that the proposed changes would only hamper the security community's ability to investigate and mitigate cybercrime.



Restricting access to the WHOIS data has the potential to slow or bottleneck investigations and security initiatives because customer addresses and phone numbers are critical to anti-abuse investigations. Although the current WHOIS data is not wholly reliable, further anonymizing and restricting the available data would only serve to weaken security and anti-abuse efforts.  At best, requiring anti-abuse researchers and investigators to formally request needed customer data from ARIN will delay progress on time sensitive investigations and incur additional costs for both ARIN and the security community.  At worst, the policy, as written, could seriously obstruct investigations if the policy were to be construed as conferring on ARIN a duty to shield that information.



That ambiguity itself raises serious concerns about how the policy changes would be implemented in practice. According to the proposal language, "the customer's actual information must be provided to ARIN on request and will be held in the strictest confidence." This leaves open the question of when and under what circumstance this data would or could be shared with investigators, with the likely outcome being uncertain and inconsistent standards for both withholding and disclosing data.



Given these serious concerns, we urge that this policy change not be adopted and we thank you for considering this feedback on Draft Policy 2010-3.



Richard Boscovich

T.J. Campana

Angeline Lee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100418/320eaf41/attachment.htm>

From JOHN at egh.com  Sat Apr 17 20:26:05 2010
From: JOHN at egh.com (John Santos)
Date: Sat, 17 Apr 2010 20:26:05 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <u2i3c3e3fca1004171646z5c8e070fpd8be3a3699230502@mail.gmail.com>
Message-ID: <1100417195327.9390A-100000@Ives.egh.com>

On Sat, 17 Apr 2010, William Herrin wrote:

> On Sat, Apr 17, 2010 at 7:29 PM, John Santos <JOHN at egh.com> wrote:
> > On Sat, 17 Apr 2010, William Herrin wrote:
> >
> >> On Sat, Apr 17, 2010 at 6:06 PM, William Herrin <bill at herrin.us> wrote:
> >> > Only the generality was
> >> > important to Ted's reminder that when providing ARIN allocations to
> >> > ISPs that find $2250/year challenging, "you consume the same amount of
> >> > routing resources on everyone else's BGP router on the Internet,"
> >> > regardless of the range of each address block announcement.
> >>
> >> That having been said, I have no objection to a policy change that
> >> allows ISPs to request the same block sizes as end users, so long as
> >> it's done in a way that doesn't make IPv6's TE (disaggregation)
> >> filterability worse that it already is.
> >
> > Can we count on the RSA to enforce allocations? ?How about policy
> > to allow ARIN to allocate at /40 to an extra-small ISP at the
> > same price as it would for a /40 PI assignment (Hope I've got
> > "allocation" and "assignment" right :-),

Still a little confused here, though I don't think it matters...

The subject of this thread is "IPv6 /32 minimum..." which is where
I got the /32 & /40 in my example, but at least by 2010-7, it should
be /40 and /48...  Or maybe I'm still confused..

> 
> Actually, I'm a fan of proposal 2010-7 which is being offered at the
> meeting next Tuesday. It would solve both problems articulated above.
> 

It looks like this redefines an extra-small as a /48 and a small as
/40 and /32 is now a medium...  I think Randy originally said he
was an X-small v4 and an X-small (/48?) would suffice, but he was
forced to justify a /32 due to the /32 minimum in the current
terms.  I agree that 2010-7 would fix this, as far as I understand it.



> Regards,
> Bill Herrin
> 






-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539



From mysidia at gmail.com  Sat Apr 17 20:46:01 2010
From: mysidia at gmail.com (James Hess)
Date: Sat, 17 Apr 2010 19:46:01 -0500
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <u2i3c3e3fca1004171646z5c8e070fpd8be3a3699230502@mail.gmail.com>
References: <z2u3c3e3fca1004171519i46dfc6b7y8ad32ee894ea71d4@mail.gmail.com>
	<1100417185325.9390A-100000@Ives.egh.com>
	<u2i3c3e3fca1004171646z5c8e070fpd8be3a3699230502@mail.gmail.com>
Message-ID: <l2r6eb799ab1004171746t17a55ad7jfbf512e9cf2db59f@mail.gmail.com>

On Sat, Apr 17, 2010 at 6:46 PM, William Herrin <bill at herrin.us> wrote:
> Actually, I'm a fan of proposal 2010-7 which is being offered at the
> meeting next Tuesday. It would solve both problems articulated above.
> Regards,
> Bill Herrin

+1
2010-7  seems to contain some much needed improvements in regards to
IPv6 addressing policy,  in regards to solving many of the problems...


--
-Mysid


From owen at delong.com  Sat Apr 17 23:11:10 2010
From: owen at delong.com (Owen DeLong)
Date: Sat, 17 Apr 2010 20:11:10 -0700
Subject: [arin-ppml] [arin-discuss] IPv4 allocation conundrum
In-Reply-To: <89BBE721-9373-4C98-B904-013997F4E0DC@gmail.com>
References: <466726541.23031.1271515991616.JavaMail.root@zimbra.network1.net>
	<89BBE721-9373-4C98-B904-013997F4E0DC@gmail.com>
Message-ID: <E7759604-6DE5-4174-9C5D-E53C4490BAB7@delong.com>

I'm actually already working on this.  I didn't want to clutter the list with it so close to the PPM. Also, I expect that this topic may be discussed as part of the Policy Experience report.

Owen

On Apr 17, 2010, at 11:45 AM, Scott Leibrand wrote:

> Randy,
> 
> This seems like a legitimate problem that could be addressed via a policy change, but given how close we are to depletion, any viable solution for IPv4 would need to work in a post-depletion transfer-market world. Do you have any specific suggestions for changes to the NRPM that would fix this?
> 
> If so, please go ahead and submit a policy proposal, and the AC will be happy to work with you to make sure it does what you want without too many unintended side effects. Or, if you don't really know where to start, we can work with you to draft it. I'll be happy to assist.
> 
> Will you be participating (in person or remotely) at the ARIN Public Policy meeting in Toronto this week? I'd encourage you to take a look at the draft policies under discussion with an eye toward how this kind of thing should work in IPv6.
> 
> Thanks,
> Scott
> 
> On Apr 17, 2010, at 10:53 AM, Randy Carpenter <rcarpen at network1.net> wrote:
> 
>> 
>> I think the fact that ARIN policy states that we need to renumber from private to public, and then renumber again is completely stupid. Allocations from ARIN should be on a *needs* basis only.
>> 
>> 
>> 
>> -Randy
>> 
>> --
>> | Randy Carpenter
>> | V.P., IT Services
>> | First Network Group, Inc.
>> | Wapakoneta, OH
>> | (419)739-9240, x1
>> --
>> 
>> 
>> ----- "Lee Howard" <spiffnolee at yahoo.com> wrote:
>> 
>>> Thanks to you both for bringing this to the mailing list.  If we need
>>> to make
>>> policy changes, we should move it to the PPML.
>>> 
>>> Randy, I'm interested to understand if the upstream providers told you
>>> any
>>> reason for not providing address space?  In North America, that's
>>> unusual.
>>> 
>>> Jacob, I'm interested in your topology.  I don't understand your need
>>> for
>>> /23 and /24.
>>> 
>>> Generally, renumbering needs to be easier.  It's a major point in this
>>> thread,
>>> in the IPv6 NAT thread, and in many proposals for smaller
>>> Provider-Independent
>>> allocations.  I see a business opportunity for someone to write an
>>> address
>>> management system that will provide updated configuration files for
>>> common
>>> firewalls, DNS servers (forward and reverse), ACLs, VPN consoles, and
>>> monitoring systems.
>>> 
>>> Lee
>>> 
>>> 
>>> 
>>> ----- Original Message ----
>>>> From: Jacob Epstein <jake at recol.com>
>>>> To: Randy Carpenter <rcarpen at network1.net>
>>>> Cc: arin-discuss at arin.net
>>>> Sent: Sat, April 17, 2010 5:28:26 AM
>>>> Subject: Re: [arin-discuss] IPv4 allocation conundrum
>>>> 
>>>> Hi Randy,
>>> 
>>> I am in a similar situation, but already have a /20 allocation.
>>>> I can use more public space, but due to our applications which need
>>> large blocks
>>>> (/23 and /24) we end up with open space that we can not chop up and
>>> reallocate.
>>>> For example our broadband Static IP Space or hosting space which are
>>> flat and
>>>> not subnetted. Although we have returned /21 of space to our
>>> upstreames since
>>>> our first allocation in 2003, we have been denied based on the 80%
>>> use of all IP
>>>> space versus allocations based on routing and application.
>>> 
>>> FYI, we
>>>> orginally applied for a /19 but were advised to return /21 of space
>>> and reaply
>>>> which we did but we denied due to change in policies. So is life!
>>> 
>>> My
>>>> understanding is that your client should be able qualify for their
>>> first Arin
>>>> allocation. They should then work on moving upstream provided IP
>>> over to the
>>>> Allocation so that they can return upstream space. I haven't seen a
>>> rule on
>>>> this, but its is wise to do so in case you lose or want to change
>>> upstream
>>>> providers. Many of us change upstream providers to get better deals
>>> or move into
>>>> an Exchange Point (IX) peering arrangement.
>>> 
>>> Has your customer looked at
>>>> the end user allocation process. Here is a link
>>> 
>>> 
>>>> 
>>> href="https://www.arin.net/resources/request/ipv4_initial_assign.html"
>>> 
>>>> target=_blank
>>>>> https://www.arin.net/resources/request/ipv4_initial_assign.html
>>> 
>>> I
>>>> did try this in order to open a new datacenter with a /23, and could
>>> not get
>>>> that based on utilization of the current /20. It seems the process
>>> doesn't care
>>>> about the need. So to get us going, I requested a /23 from a new
>>> upstream
>>>> provider to get our business. Later on after we are operational, we
>>> will migrate
>>>> some of our /20 allocation, but its not going to be easy on current
>>> customers
>>>> that will have to be assigned new IP addresses. (DNS Changes, VPN
>>> Changes,
>>>> Security (Access Control) changes. One customer has 80 remote
>>>> offices!
>>> 
>>> But it seems to me that there has to be a way for smaller
>>>> providers with no allocations to obtain blocks and then retun
>>> upstream blocks as
>>>> part of the process.
>>> 
>>> Seems that if not, smaller providers starting up or
>>>> in our case focused on conservation should go away while the large
>>> telcos and
>>>> broadband provides either "suck the pool dry" or rest on large
>>> allocations they
>>>> got years ago.
>>> 
>>> So something sounds strange since need upstream blocks to
>>>> get into the business. The Arin contact seems to be saying no one
>>> gets their
>>>> first allocation based on your customer's scenario as I read it
>>> which is to get
>>>> the first allocation. Maybe they do not qualify for /19 but could
>>> for /20 or
>>>> /21.
>>> 
>>> FYI, we have been working on IPv6. The new data center will be
>>>> native IPv6.
>>> 
>>> Good Luck,
>>> 
>>> 
>>> Jake
>>> 
>>> -- Jacob Epstein, Chief
>>>> Technology Officer
>>> RECOL, LLC - An Internet Solutions Provider
>>> web:
>>>> http://www.recol.net
>>> email:
>>>> href="mailto:jake at recol.com">jake at recol.com
>>> 
>>> 
>>> 
>>> Randy Carpenter
>>>> wrote:
>>>> I am working with a new customer who is in a bit of a
>>>> pickle...
>>>> 
>>>> They are an ISP and VoIP provider whose upstream
>>>> provider wouldn't (or couldn't) give them many addresses.
>>>> They resorted
>>>> to using NATed private IPs for most of their network, which is
>>> causing problems
>>>> for their end user customers.
>>>> 
>>>> Now that we are working with
>>>> them, I am trying to find a solution to get them public IPs. They
>>> are also soon
>>>> to be multi-homed (They have 2 connections, but no BGP yet). As an
>>> ISP, it would
>>>> be best for them to have PI space.
>>>> 
>>>> The issue is that one of the
>>>> requirements for getting PI space from ARIN is that you are already
>>> using Public
>>>> space that was assigned to you from an upstream provider. I spoke
>>> with someone
>>>> from ARIN who says there is no way around this. The need around a
>>> /19 of space,
>>>> and I cannot find any way to get it for them. The upstream providers
>>> refuse to
>>>> give them any.
>>>> 
>>>> What can be done about this?  Would would
>>>> there be a requirement of already using someone else's IP space to
>>> get your own?
>>>> That seems like a complete waste of time, effort, money, and IPs!
>>>> 
>>>> 
>>>> -Randy
>>>> 
>>>> --
>>>> | Randy Carpenter
>>>> | V.P., IT
>>>> Services
>>>> | First Network Group, Inc.
>>>> | RHCE
>>>> |
>>>> (419)739-9240, x1
>>>> --
>>>> 
>>>> 
>>>> _______________________________________________
>>>> ARIN-Discuss
>>>> You
>>>> are receiving this message because you are subscribed to
>>>> the ARIN
>>>> Discussion Mailing List (
>>>> href="mailto:ARIN-discuss at arin.net">ARIN-discuss at arin.net).
>>>> 
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> 
>>>> http://lists.arin.net/mailman/listinfo/arin-discuss
>>>> Please contact
>>>> ymailto="mailto:info at arin.net"
>>> href="mailto:info at arin.net">info at arin.net if
>>>> you experience any issues.
>>>> 
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> ARIN-Discuss
>>> You
>>>> are receiving this message because you are subscribed to
>>> the ARIN Discussion
>>>> Mailing List (
>>>> href="mailto:ARIN-discuss at arin.net">ARIN-discuss at arin.net).
>>> Unsubscribe
>>>> or manage your mailing list subscription at:
>>> 
>>>> href="http://lists.arin.net/mailman/listinfo/arin-discuss"
>>> target=_blank
>>>>> http://lists.arin.net/mailman/listinfo/arin-discuss
>>> Please contact
>>>> ymailto="mailto:info at arin.net"
>>> href="mailto:info at arin.net">info at arin.net if
>>>> you experience any issues.
>> _______________________________________________
>> ARIN-Discuss
>> You are receiving this message because you are subscribed to
>> the ARIN Discussion Mailing List (ARIN-discuss at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-discuss
>> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From rudi.daniel at gmail.com  Sat Apr 17 23:57:50 2010
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Sat, 17 Apr 2010 23:57:50 -0400
Subject: [arin-ppml] ARIN-PPML Digest, Vol 58, Issue 49
In-Reply-To: <mailman.1197.1271549381.28982.arin-ppml@arin.net>
References: <mailman.1197.1271549381.28982.arin-ppml@arin.net>
Message-ID: <o2p8aeeaff61004172057t9d559b58hc61565e65597044c@mail.gmail.com>

Having shown some support for 2010-3 in the past; all the comments I have
read to date on both sides leads me to reconsider and  I would therefore not
support policy change 2010-3 as written. However I could  never
imagine *" policy
were (can) to be construed as conferring on ARIN a duty to shield that
information"*  from anti-abuse researchers and investigators.

RD


> The Digital Crimes Unit within Microsoft investigates cybercrime attacks
> against our customers and services.  We rely on information from the ARIN
> database to correlate and identify the source of nefarious online
> activities.  As such, we oppose any policy change that would lessen the
> quantity and quality of information in the ARIN database.  While we
> recognize the importance of data privacy, we strongly believe that the
> proposed changes would only hamper the security community's ability to
> investigate and mitigate cybercrime.
>
>
>
> Restricting access to the WHOIS data has the potential to slow or
> bottleneck investigations and security initiatives because customer
> addresses and phone numbers are critical to anti-abuse investigations.
> Although the current WHOIS data is not wholly reliable, further anonymizing
> and restricting the available data would only serve to weaken security and
> anti-abuse efforts.  At best, requiring anti-abuse researchers and
> investigators to formally request needed customer data from ARIN will delay
> progress on time sensitive investigations and incur additional costs for
> both ARIN and the security community.  At worst, the policy, as written,
> could seriously obstruct investigations if the policy were to be construed
> as conferring on ARIN a duty to shield that information.
>
>
>
> That ambiguity itself raises serious concerns about how the policy changes
> would be implemented in practice. According to the proposal language, "the
> customer's actual information must be provided to ARIN on request and will
> be held in the strictest confidence." This leaves open the question of when
> and under what circumstance this data would or could be shared with
> investigators, with the likely outcome being uncertain and inconsistent
> standards for both withholding and disclosing data.
>
>
>
> Given these serious concerns, we urge that this policy change not be
> adopted and we thank you for considering this feedback on Draft Policy
> 2010-3.
>
>
>
> Richard Boscovich
>
> T.J. Campana
>
> Angeline Lee
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100417/ab827c71/attachment.htm>

From kenneth.odem at virpusnetworks.net  Sun Apr 18 00:05:01 2010
From: kenneth.odem at virpusnetworks.net (Kenneth Odem)
Date: Sat, 17 Apr 2010 23:05:01 -0500
Subject: [arin-ppml] Regarding draft policy 2010-3
Message-ID: <FCD64EDE35B84FB7801C4874219C5863@virpus3b443eed>

In response to draft policy 2010-3, I agree that customer information of ISP's needs to be protected by the ISP, and not published to the public; not only for privacy reasons of said company's customers, but also to run an effective business model which does not involve giving a competitor knowledge of who your customers are, and their contact information.

This is needed to avoid solicitations, which it has been shown that competitors can and do use information available to the public to solicit to said company's customers.  

I stand by draft policy 2010-3 and hope that it takes effect immediately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100417/e87d6155/attachment.htm>

From joelja at bogus.com  Sun Apr 18 01:01:37 2010
From: joelja at bogus.com (Joel Jaeggli)
Date: Sat, 17 Apr 2010 22:01:37 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <09575063-0276-4EDF-A011-F29D318F14D7@delong.com>
References: <20100413172714.M35473@fast-serv.com>	<r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com>	<75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu>	<1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry>	<75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu>	<k2if65fb55e1004141335y1a73bda2n17dd4e42218ad45d@mail.gmail.com>	<75822E125BCB994F8446858C4B19F0D701D5FCA513@SUEX07-MBX-04.ad.syr.edu>	<17838240D9A5544AAA5FF95F8D52031607EE0EA8@ad-exh01.adhost.lan>	<75822E125BCB994F8446858C4B19F0D701D5FCA517@SUEX07-MBX-04.ad.syr.edu>	<8692A26B68F04BC7A404E3579E7B0171@changeip.com>	<1271282125.5224.80.camel@ggiesen-workstation.netsurf.net>	<75822E125BCB994F8446858C4B19F0D701D5FCA520@SUEX07-MBX-04.ad.syr.edu>	<4BC765C1.3040601@ipinc.net>	<75822E125BCB994F8446858C4B19F0D701D5E0A148@SUEX07-MBX-04.ad.syr.edu>
	<09575063-0276-4EDF-A011-F29D318F14D7@delong.com>
Message-ID: <4BCA9231.3010602@bogus.com>

On 04/16/2010 10:01 AM, Owen DeLong wrote:
> 
> On Apr 16, 2010, at 9:48 AM, Milton L Mueller wrote:
> 
>>> -----Original Message-----
>>>> 
>>>> What's wrong with offering the smaller ISP something smaller 
>>>> than a /32 at a lower price?
>>> 
>>> 
>>> I for one would prefer to NOT modify minimum allocation policy, 
>>> if for no other reason that I can do a "show ipv6" in my router 
>>> and know immediately that if a particular IPv6 address is within 
>>> a /32 advertisement, then there's an ISP involved.

Rxcept of course that won't last forever, and in fact isn't the case
now, e.g. there are more specific from /32s and in face autonomous
systems advertising more specifics carved out of another ASes short
prefix just like in v4.

>> I understand the motivation, but then you are using the size of an 
>> address block to convey semantic meaning ("this is an ISP"). Seems 
>> like a odd combination of functions to me. Shouldn't those two 
>> things be separated and how difficult can it be to separate them? 
>> Also, is the distinction between ISP and organization that clear
>> in all cases?
>> 
> This doesn't make sense, actually.  Nothing prevents an end user
> with a large number of sites or a large network from getting a /32.

There are entities that are nominally end users with /32s.

> Now, if what he's really trying to say is that any prefix longer
> than a /32 is an end-user or an ISP doing something less than ideal, 
> that's actually true as things stand now, but, I think that's the 
> only valid conclusion from prefix size with current policy.  Of 
> course a policy change can only reduce the conclusions that can be 
> drawn since it won't affect past allocations or assignments.
> 
>>> I'd support a fee waiver to small ISP's who have an active and 
>>> utilized sub- /20 of IPv4.  Ultimately, when IPv4 becomes 
>>> obsolete and the RIR ceases to track it, and the entire issue of 
>>> who owns what IPv4 block becomes nothing more than historical 
>>> interest, the waiver will naturally disappear.
>> 
>> Not a bad idea in the short term but if the small ISP screeches 
>> about paying those fees now, won't they do the same then?

I'd like to pay less income tax too but I don't think that's in the
cards, if the fee structure has some glaring flaw then that should be
fixed but the fact that allocating small quantities and maintaining
records has a fee associated with it should surprise no-one whose been
to the DMV.

> More than likely, but, I do think this would be a good short term 
> solution while we have a longer discussion about the best way to 
> address the issue in the long run.
> 
> I will point out, however, that a fee discussion belongs on 
> arin-discuss as fees are a member topic and not a policy topic.
> 
> 
> Owen
> 
> _______________________________________________ PPML You are 
> receiving this message because you are subscribed to the ARIN Public 
> Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your 
> mailing list subscription at: 
> http://lists.arin.net/mailman/listinfo/arin-ppml Please contact 
> info at arin.net if you experience any issues.
> 


From daved at lightwave.net  Sun Apr 18 01:58:51 2010
From: daved at lightwave.net (Daved Daly)
Date: Sat, 17 Apr 2010 22:58:51 -0700
Subject: [arin-ppml] Regarding draft policy 2010-3
In-Reply-To: <FCD64EDE35B84FB7801C4874219C5863@virpus3b443eed>
References: <FCD64EDE35B84FB7801C4874219C5863@virpus3b443eed>
Message-ID: <h2rcfbf63f61004172258q91d0e619vf43f66622e27f5f9@mail.gmail.com>

I support the policy for reassignments.  I do not support the policy
for reallocations.

I do take issue with some of the wording of the policy.
"ISPs may choose to enter the customer's name along with the ISP's
address and phone number in reassignments and reallocations in lieu of
the customer's address and phone number."

The customer's phone number is not necessarily information that is
gathered or provided in the reassignment process. The only reason
phone number information would be published is if the ISP has chosen
to use a detailed reassignment template.  In general (afaik) the main
reason the ISP would likely do that would be at the direction of the
customer (because the customer likely has their own support/networking
agents who wish to be in the loop about potential issues).  So, the
wording of the policy seems to makes people believe they will be
losing access to the phone number of every customer's reassignment,
when they likely don't have it to begin with.

I do believe there is importance in providing valid contact
information for network operators.  That is why I do not support the
policy for reallocations.

-Daved Daly


On Sat, Apr 17, 2010 at 9:05 PM, Kenneth Odem
<kenneth.odem at virpusnetworks.net> wrote:
> In response to draft policy 2010-3, I agree that customer information of
> ISP's needs to be protected by the ISP, and not published to the public; not
> only for privacy reasons?of said company's customers, but also?to run an
> effective business model which does not involve giving a
> competitor?knowledge of who your customers are, and their contact
> information.
>
> This is needed to avoid solicitations, which it has been shown that
> competitors can and do use information available to the public to solicit to
> said company's customers.
>
> I stand by draft policy 2010-3 and hope that it takes effect immediately.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>


From mysidia at gmail.com  Sun Apr 18 05:12:53 2010
From: mysidia at gmail.com (James Hess)
Date: Sun, 18 Apr 2010 04:12:53 -0500
Subject: [arin-ppml] Regarding draft policy 2010-3
In-Reply-To: <FCD64EDE35B84FB7801C4874219C5863@virpus3b443eed>
References: <FCD64EDE35B84FB7801C4874219C5863@virpus3b443eed>
Message-ID: <v2r6eb799ab1004180212k4ed9737brccbd305a3036067e@mail.gmail.com>

On Sat, Apr 17, 2010 at 11:05 PM, Kenneth Odem
<kenneth.odem at virpusnetworks.net> wrote:
> This is needed to avoid solicitations, which it has been shown that
> competitors can and do use information available to the public to solicit to
> said company's customers.
[snip]
I would say it's not a valid basis for ISPs to be allowed to hide
re-assignment information.  It only potentially serves self-interests
of some providers at huge expense to the community.  Also, if
competitors want to market services to a provider's customers, there
are more effective means to do that than  trying ad-hoc queries
against the WHOIS directory.

So hiding information from WHOIS actually does not accomplish or aid
the objective of "avoiding solicitations"  in any way that has been
quantified; it _might_, but I consider it to be very unlikely.

   The contacts listed in WHOIS are normally technical contacts, who
are likely to report such spam and abuse of the WHOIS service if they
receive such unwanted mail, and unlikely to respond favorably to
solicitation.

Almost every company today lists business contact information on their
web site, which is more likely to be directly responsive to a sales
pitch.


Soliciters are much more likely  to scan the ISP's   IP ranges,
perform RDNS lookups,  and harvest information from web servers.

They do not have to do this themselves,  there are services they can
buy all this information from.

Removal of  information from the WHOIS directory doesn't really stop them,
unless the downstream customer has neither a website nor a mail
server, nor any RDNS, in their re-assigned IP space.

--
-J


From mcr at sandelman.ca  Sun Apr 18 12:39:06 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Sun, 18 Apr 2010 12:39:06 -0400
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <28E139F46D45AF49A31950F88C49745805C9DC0C@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745805C9DC0C@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <8589.1271608746@marajade.sandelman.ca>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "michael" == michael dillon <michael.dillon at bt.com> writes:
    >> I deployed IPv4 NAT back in 1996 (or earlier, I forget) in a
    >> production environment.  The way I did it - and the ONLY way that
    >> ANYONE could do it at that time - was by applying a very large,
    >> convoluted set of patches to the FreeBSD 3 kernel and compiling
    >> the nat daemon.

    michael> At that time I was running TIS firewalls toolkit on a
    michael> FreeBSD 2 system. It was not NAT, but to the outside world,
    michael> the application layer proxies did present multiple machines
    michael> inside the network on a single IP address, just like NAT
    michael> did. And an external machine could not pass packets to an
    michael> internal one, unless a proxy was specifically configured to
    michael> allow it, just like on a NAT box.

  Between 1994 and 1996 (when I left), I shipped hundreds of Milkyway
Blackhole firewalls.   In their default configuration, they did
transparent proxy via application layer firewalling, which effectively
is NAPT, but it occurs at layer-5+.

  We had a configuration we called "Whitehole", which essentially was
application layer firewall, but it revealed the internal IPs. Or more
precisely, it was 1:1 NAT, with an identity function for the mapping.
(All of the protection, none of the calories...)
  Of course, you could mix and match what you wanted, on a per-rule basis.

  My opinion is that it was all a mistake from a security point of view
- --- what we (the firewall industry) did was permit microsoft to ship
win95 with major bugs, many of which are still not fixed. (Many are
considered "features") 

  A significant number of (technical) people have never actually been on
the "bare" Internet...  You can see them at ARIN, NANOG or IETF meetings
- --- those are the people re-installing their laptop system in the
"terminal room". 

  NAPT has been a major negative --- it causes networks to be too
complex to manage, and many PHBs can't understand it at all.

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



 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS8s1qICLcPvd0N1lAQLyXgf5AT2Tj3VupefYHzPf6u82C1x1ZzV+OFy0
4RasBeUXycNDotq6WGVYQAB3f+sd7xrU5JDJMmKqEywDChKlfclSiCsx9Yiy/INM
Sh+A1a+Xkv7m3i/A1tXgOhMfvovMqs5kiWYJbIZD0Isn8TGAmUdZkYjbl7tIifeZ
BmJiIQLEowlxF8bvMPa9qquKk23vF0k8Vi7G5JzntDdGEFzrsFIk2gxEGjut8asP
KAwce4r88frPt3VlzRe4MrnQZD6LdFUa02njg6iMM93nxqpEmv0Nuyi26mml5LN3
8SheKcDewSxjIAuPeIW5ezSu2rodFQu5jRsIPmoZhLD8lLl1Ja4DWQ==
=fvyb
-----END PGP SIGNATURE-----


From mueller at syr.edu  Sun Apr 18 13:57:07 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Sun, 18 Apr 2010 13:57:07 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <763F5F2A-D0BC-4E82-8007-381AD3A3D666@pch.net>
References: <20100413172714.M35473@fast-serv.com>
	<4BC4B1B6.7060804@ipinc.net><A153ECC6B3414765B321340BCE7AFC16@changeip.com><r2z6eb799ab1004132104n635af94bv880c32b5b0c0d66b@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA50D@SUEX07-MBX-04.ad.syr.edu><1398283752-1271275479-cardhu_decombobulator_blackberry.rim.net-1558713100-@bda040.bisx.prod.on.blackberry><75822E125BCB994F8446858C4B19F0D701D5FCA50E@SUEX07-MBX-04.ad.syr.edu><k2if65fb55e1004141335y1a73bda2n17dd4e42218ad45d@mail.gmail.com><75822E125BCB994F8446858C4B19F0D701D5FCA513@SUEX07-MBX-04.ad.syr.edu>
	<1665735650-1271281000-cardhu_decombobulator_blackberry.rim.net-452158009-@bda040.bisx.prod.on.blackberry>
	<75822E125BCB994F8446858C4B19F0D701D5FCA51B@SUEX07-MBX-04.ad.syr.edu>
	<20281658-8F97-4BFC-90D1-49DF6F639237@delong.com>
	<763F5F2A-D0BC-4E82-8007-381AD3A3D666@pch.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D701D5E0A190@SUEX07-MBX-04.ad.syr.edu>

I just saw this, sorry I didn't respond sooner. Been driving to Toronto.
Well, thanks! Let's talk in Toronto. Maybe I can understand better what it is I do that irritates you so. 

--MM

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Bill Woodcock
> Sent: Friday, April 16, 2010 1:35 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] IPv6 /32 minimum for extra-small ISP
> 
> On Apr 14, 2010, at 2:47 PM, Milton L Mueller wrote:
> > Bill, your hostility is wearisome and pointless.
> 
> Milton, with the benefit of the perspective of a few hours' sleep, my
> reply was very ill-considered.  You have my unqualified apology.
> 
>                                 -Bill
> 
> 
> 



From mueller at syr.edu  Sun Apr 18 13:57:05 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Sun, 18 Apr 2010 13:57:05 -0400
Subject: [arin-ppml] Support proposal 2010-2: /24 end-user assignments
In-Reply-To: <p2j3c3e3fca1004171704hfdbab5bdgf7b01f6eb42088a4@mail.gmail.com>
References: <p2j3c3e3fca1004171704hfdbab5bdgf7b01f6eb42088a4@mail.gmail.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D701D5E0A18E@SUEX07-MBX-04.ad.syr.edu>

Bill,
I have a question about the anticipated time horizon for the beneficial effects of 2010-2.  This policy is about cleaning up the ipv4 space by consolidating smaller assignments for multihomers and involves returning and in some cases renumbering. For renumbering cases a one-year cycle of dual assignments is involved. The question: how many years do you think it would take for this policy to have an appreciable effect on aggregation? And do you think would that effect be one of slowing table growth or actually reducing its size? Please note: I am not questioning the beneficial effects, just interested in their anticipated magnitude and the speed with which they would happen.

Milton Mueller
Professor, Syracuse University School of Information Studies
XS4All Professor, Delft University of Technology
------------------------------
Internet Governance Project:
http://internetgovernance.org


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of William Herrin
> Sent: Saturday, April 17, 2010 8:05 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Support proposal 2010-2: /24 end-user assignments
> 
> Hi Folks,
> 
> Yesteryear's attempt to restrain the mess the IPv4 BGP table has
> become by setting RIR minimums to /19 or /20 within particular /8's
> utterly failed, largely because small multihomed end users had no
> choice but to get /24's from their ISP -- in the middle of the
> restricted /8's. Though late in the day, proposal 2010-2 largely
> corrects this grave mistake for new assignments -without- expanding
> who can introduce BGP routes into the table or how many IP addresses
> anyone qualifies for. It is a major step forward and I strongly
> encourage you to stand in support of it at the ARIN meeting next
> Monday.
> 
> For your reference: https://www.arin.net/policy/proposals/2010_2.html
> 
> Regards,
> Bill Herrin
> 


From owen at delong.com  Sun Apr 18 14:20:56 2010
From: owen at delong.com (Owen DeLong)
Date: Sun, 18 Apr 2010 11:20:56 -0700
Subject: [arin-ppml] Support proposal 2010-2: /24 end-user assignments
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5E0A18E@SUEX07-MBX-04.ad.syr.edu>
References: <p2j3c3e3fca1004171704hfdbab5bdgf7b01f6eb42088a4@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D701D5E0A18E@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <30EF552C-C236-43FA-A5E2-D4BF96D01857@delong.com>

Milton,
	In toto, this policy probably won't increase aggregation much, but, it certainly won't increase deaggregation and does provide for increased aggregation potential vs. the way things are now. I think the magnitude of these beneficial effects is small, but, these are a side-effect of the policy.

	The primary benefit of the policy is for small multihomers to be able to get space directly from ARIN rather than from one of their upstream providers. It offers them the chance at a different set of tradeoffs as follows:

Current									2010-2
======================				=========================
Renumber if you change ISP				Renumber if you grow out of your /24 or /23

Just keep adding more /24s to grow		Renumber (up to /22), then, additional
										assignments as needed.

Every /24 == More routes					One route per ARIN prefix, one route to /22,
										possibly additional ones once you're larger.

ISP controls your destiny					Control your own destiny

Hope that helps you understand the intent and tradeoffs around 2010-2.

Owen

On Apr 18, 2010, at 10:57 AM, Milton L Mueller wrote:

> Bill,
> I have a question about the anticipated time horizon for the beneficial effects of 2010-2.  This policy is about cleaning up the ipv4 space by consolidating smaller assignments for multihomers and involves returning and in some cases renumbering. For renumbering cases a one-year cycle of dual assignments is involved. The question: how many years do you think it would take for this policy to have an appreciable effect on aggregation? And do you think would that effect be one of slowing table growth or actually reducing its size? Please note: I am not questioning the beneficial effects, just interested in their anticipated magnitude and the speed with which they would happen.
> 
> Milton Mueller
> Professor, Syracuse University School of Information Studies
> XS4All Professor, Delft University of Technology
> ------------------------------
> Internet Governance Project:
> http://internetgovernance.org
> 
> 
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of William Herrin
>> Sent: Saturday, April 17, 2010 8:05 PM
>> To: arin-ppml at arin.net
>> Subject: [arin-ppml] Support proposal 2010-2: /24 end-user assignments
>> 
>> Hi Folks,
>> 
>> Yesteryear's attempt to restrain the mess the IPv4 BGP table has
>> become by setting RIR minimums to /19 or /20 within particular /8's
>> utterly failed, largely because small multihomed end users had no
>> choice but to get /24's from their ISP -- in the middle of the
>> restricted /8's. Though late in the day, proposal 2010-2 largely
>> corrects this grave mistake for new assignments -without- expanding
>> who can introduce BGP routes into the table or how many IP addresses
>> anyone qualifies for. It is a major step forward and I strongly
>> encourage you to stand in support of it at the ARIN meeting next
>> Monday.
>> 
>> For your reference: https://www.arin.net/policy/proposals/2010_2.html
>> 
>> Regards,
>> Bill Herrin
>> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From sethm at rollernet.us  Mon Apr 19 02:55:04 2010
From: sethm at rollernet.us (Seth Mattinen)
Date: Sun, 18 Apr 2010 23:55:04 -0700
Subject: [arin-ppml] Regarding draft policy 2010-3
In-Reply-To: <h2rcfbf63f61004172258q91d0e619vf43f66622e27f5f9@mail.gmail.com>
References: <FCD64EDE35B84FB7801C4874219C5863@virpus3b443eed>
	<h2rcfbf63f61004172258q91d0e619vf43f66622e27f5f9@mail.gmail.com>
Message-ID: <4BCBFE48.2070604@rollernet.us>

On 4/17/10 10:58 PM, Daved Daly wrote:
> I support the policy for reassignments.  I do not support the policy
> for reallocations.
> 


Strongly agree. If you have a reallocation, you are operating a network,
and you get to be public. No exceptions.

I would oppose draft policy 2010-3 without this distinction.

~Seth


From info at arin.net  Mon Apr 19 08:55:46 2010
From: info at arin.net (Member Services)
Date: Mon, 19 Apr 2010 08:55:46 -0400
Subject: [arin-ppml] ARIN XXV Start Message
Message-ID: <4BCC52D2.5020205@arin.net>

The ARIN XXV Public Policy and Members Meeting begins today in Toronto, 
Ontario.

For those who are unable to be in Toronto, ARIN is offering a webcast 
and live transcript of the proceedings. The times of the broadcast are 
as follows:

Public Policy Meeting (policy and technical discussions)
Monday, 19 April 9AM - 5PM
Tuesday, 20 April 9AM - 5PM

Members Meeting (ARIN reports, Board of Trustees and Advisory Council 
reports)
Wednesday, 21 April 9AM - 12PM

All times are Eastern Daylight Time (EDT), (UTC/GMT -4 hours)

You may register as a remote participant at any time throughout the 
meeting, and registered remote participants are invited to join in the 
meeting chat to vote in straw polls and submit questions or comments 
during the times listed above. Pre-register your Jabber Identifier (JID) 
to have full chat room access from the start of the meeting. You can 
register a JID at any time, but we will only be adding new participants 
during scheduled breaks in the meeting. The full agenda is available at:

https://www.arin.net/ARIN-XXV/agenda.html

You can also follow us on Twitter @TeamARIN for schedule updates. Be 
sure to use the #arin25 tag for your own tweets about the meeting.

For details about how to connect to the webcast, chat, and live 
transcript, or to refer to the
Remote Participation Acceptable Use Policy, please see:

http://www.arin.net/ARIN-XXV/remote.html

For the first time, all community members are invited to participate in 
the Daily Meeting surveys! Share their thoughts with ARIN on today?s 
topic, ?Doing business with ARIN?; take a few moments and answer five 
questions to be entered in a raffle drawing for a Freeloader Pico Solar 
Charger. Entries will be accepted between 8:00 AM and 6:00 PM EDT, and 
the winner will be selected at the opening of tomorrow?s meeting.

Follow the link to the survey for your chance to win:

https://www.arin.net/ARIN-XXV/survey.html


Regards,

Member Services
American Registry for Internet Numbers (ARIN)







From jaitken at aitken.com  Mon Apr 19 09:00:17 2010
From: jaitken at aitken.com (Jeff Aitken)
Date: Mon, 19 Apr 2010 13:00:17 +0000
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <4BC80C8D.3010500@umn.edu>
References: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA634@Skyhawk>
	<BBFC01FA-DC9D-43DC-BD9C-B18BC7ADC1F5@delong.com>
	<1271370711.5224.133.camel@ggiesen-workstation.netsurf.net>
	<4BC797AA.2010901@actusa.net> <4BC80C8D.3010500@umn.edu>
Message-ID: <20100419130017.GA16555@eagle.aitken.com>

On Fri, Apr 16, 2010 at 02:06:53AM -0500, David Farmer wrote:
> https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml
> 
> [...] yes it does say NAT.

David,

The PCI DSS references both NAT and RFC1918, which is obviously specific to
IPv4.  Do you know what requirements are coming re: IPv6?  Looks like the
PCI folks are in the middle of the 24-month review process for v1.2.  If
"the industry" feels that there should be more than one acceptable
configuration, then perhaps "we" should find a way to work with the PCI
folks to eliminate the need to handle that via the compensating controls
exercise.  E.g., 1.3.8 could be amended to state that internal addresses
must be unrouteable, but not explicitly reference RFC1918 (or RFC4193, in a
v6 context).  This seems like a good example of "education and outreach"
that benefits the membership.

Note that I am blissfully ignorant of any potential political or religious 
implications here.  If this idea is stupid or otherwise impractical, or if
we've BTDT already, then I apologize for the noise. :-)


--Jeff



From owen at delong.com  Mon Apr 19 09:25:38 2010
From: owen at delong.com (Owen DeLong)
Date: Mon, 19 Apr 2010 06:25:38 -0700
Subject: [arin-ppml] The role of NAT in IPv6
In-Reply-To: <20100419130017.GA16555@eagle.aitken.com>
References: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA634@Skyhawk>
	<BBFC01FA-DC9D-43DC-BD9C-B18BC7ADC1F5@delong.com>
	<1271370711.5224.133.camel@ggiesen-workstation.netsurf.net>
	<4BC797AA.2010901@actusa.net> <4BC80C8D.3010500@umn.edu>
	<20100419130017.GA16555@eagle.aitken.com>
Message-ID: <1F438021-97B0-473F-81FF-C0DCC081925B@delong.com>


On Apr 19, 2010, at 6:00 AM, Jeff Aitken wrote:

> On Fri, Apr 16, 2010 at 02:06:53AM -0500, David Farmer wrote:
>> https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml
>> 
>> [...] yes it does say NAT.
> 
> David,
> 
> The PCI DSS references both NAT and RFC1918, which is obviously specific to
> IPv4.  Do you know what requirements are coming re: IPv6?  Looks like the
> PCI folks are in the middle of the 24-month review process for v1.2.  If
> "the industry" feels that there should be more than one acceptable
> configuration, then perhaps "we" should find a way to work with the PCI
> folks to eliminate the need to handle that via the compensating controls
> exercise.  E.g., 1.3.8 could be amended to state that internal addresses
> must be unrouteable, but not explicitly reference RFC1918 (or RFC4193, in a
> v6 context).  This seems like a good example of "education and outreach"
> that benefits the membership.
> 
A better phrase would be "unreachable" rather than "unroutable".

I agree.

> Note that I am blissfully ignorant of any potential political or religious 
> implications here.  If this idea is stupid or otherwise impractical, or if
> we've BTDT already, then I apologize for the noise. :-)
> 
Nope, I think it's right on track.

Owen



From tedm at ipinc.net  Mon Apr 19 13:53:34 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 19 Apr 2010 10:53:34 -0700
Subject: [arin-ppml] Support proposal 2010-2: /24 end-user assignments
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701D5E0A18E@SUEX07-MBX-04.ad.syr.edu>
References: <p2j3c3e3fca1004171704hfdbab5bdgf7b01f6eb42088a4@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D701D5E0A18E@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4BCC989E.9010203@ipinc.net>


Are you sure your not referring to 2010-5 since it uses the same 
return-and-renumber criteria?

I can't speak for 2010-2 since I wasn't involved in that one but I did
author policy proposal 102 in conjunction with Chris Grundemann which
was reworked into 2010-5

Neither Chris or I considered the issue of the time horizon for the
beneficial effects for the simple reason that the return-and-renumber
requirement is a moral obligation more than an attempt to clean the
dfz.  In the case of 2010-5 it would be a wash anyway, because that
opens the door to small ISPs who currently DON'T qualify to obtain
numbering - thus it's kind of, well this year we will allow extra
fragmentation but next year when your bigger we will take it back.

For 2010-2, even though the goal, is to defragment
the dfz, I feel that a much more overriding issue is that the community 
has a moral obligation to Do The Right Thing, as it were.

 From a forest-vs-tree perspective, it may not result in a
few additional percent of fragmentation in the dfz to allow small 
holders to make non-contiguous, fragmented advertisements.  I think
what your getting at here is the argument that this polity institutes
a rule (return-and-renumber) that costs a few members greatly, but
saves the vast majority nothing.

But from a tree perspective this is the same argument that well we
should just go ahead and allow all families with 13 or more children 
free admission to Disneyland since families that large are cash-tight
and there's so few of them that this won't increase ticket pricing.

It isn't morally right to allow a small ISP to "get away" with
fragmented advertising of multiple small blocks, when that ISP, with
a bit of discipline, and a bit of work, could renumber into a single
larger block.  It doesen't matter that there's so few of them in
this criteria that you can make a macro economic argument that it's
not worth the trouble to the community to enforce this.

My personal view is that this should have been done a decade ago
for that reason.  The fact that it wasn't shouldn't be used as a
justification that well we let them "get away" with this for
so long, it's futile now to close the barn door, the horse was
stolen a decade ago and has gone to the glue factory by now.  I
also don't see that renumbering is that much of a burden - I've
done it with a far larger network than what is being discussed
by this proposal and it's just like eating an Elephant.  It's no
problem if you do it a bit at a time.

Ted



On 4/18/2010 10:57 AM, Milton L Mueller wrote:
> Bill,
> I have a question about the anticipated time horizon for the beneficial effects of 2010-2.  This policy is about cleaning up the ipv4 space by consolidating smaller assignments for multihomers and involves returning and in some cases renumbering. For renumbering cases a one-year cycle of dual assignments is involved. The question: how many years do you think it would take for this policy to have an appreciable effect on aggregation? And do you think would that effect be one of slowing table growth or actually reducing its size? Please note: I am not questioning the beneficial effects, just interested in their anticipated magnitude and the speed with which they would happen.
>
> Milton Mueller
> Professor, Syracuse University School of Information Studies
> XS4All Professor, Delft University of Technology
> ------------------------------
> Internet Governance Project:
> http://internetgovernance.org
>
>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of William Herrin
>> Sent: Saturday, April 17, 2010 8:05 PM
>> To: arin-ppml at arin.net
>> Subject: [arin-ppml] Support proposal 2010-2: /24 end-user assignments
>>
>> Hi Folks,
>>
>> Yesteryear's attempt to restrain the mess the IPv4 BGP table has
>> become by setting RIR minimums to /19 or /20 within particular /8's
>> utterly failed, largely because small multihomed end users had no
>> choice but to get /24's from their ISP -- in the middle of the
>> restricted /8's. Though late in the day, proposal 2010-2 largely
>> corrects this grave mistake for new assignments -without- expanding
>> who can introduce BGP routes into the table or how many IP addresses
>> anyone qualifies for. It is a major step forward and I strongly
>> encourage you to stand in support of it at the ARIN meeting next
>> Monday.
>>
>> For your reference: https://www.arin.net/policy/proposals/2010_2.html
>>
>> Regards,
>> Bill Herrin
>>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From info at arin.net  Thu Apr 22 14:46:39 2010
From: info at arin.net (Member Services)
Date: Thu, 22 Apr 2010 14:46:39 -0400
Subject: [arin-ppml] Policy Proposal 110: Preservation of minimal IPv4
 Resources for New and Small Organizations and for IPv6 Transition
Message-ID: <4BD0998F.60900@arin.net>

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

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

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

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

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

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

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal: Preservation of minimal IPv4 Resources for New and
Small Organizations and for IPv6 Transition

1. Proposal Originator: Joe Maimon

3. Proposal Version: 1

4. Date: 22 April 2010

5. Proposal type: New, Modify

6. Policy term: Permanent

7. Policy statement:

[Replace 4.10 in whole with the following.]

4.10 Minimum Allocations or Assignments from Reserved Pools

Upon execution of 10.4.2, ARIN will reserve pools of addresses
unavailable to fulfill any requests except as detailed in this section.
These pools will be utilized only for the minimal sized allocations or
assignments for properly justified requests, regardless of the size of
the request, under the following provisions, and only if ARIN is
otherwise unable to fulfill the request in entirety.

4.10.1 Affiliation of Organizations

To qualify under these sections organizations may be required to
demonstrate to reasonable satisfaction that they are not affiliated with
any other organizations for the intended purpose of qualifying under
these sections where they would not otherwise. All other aspects of
organization affiliations are not of specific concern to section

4.10.

4.10.2 Qualifying Organizations Request Fulfillment

Upon approval of an otherwise unfulfillable request, ARIN will determine
and notify the requester of section 4.10 applicability. Qualifying
organization may receive only one request fulfillment per three month
window from any of the pools defined in this section. Organizations may
decline to receive resources for their requests under these sections
without negating the request. Organizations who do receive resources
under these sections will have their request considered fully fulfilled
and completed.

4.10.3 Additional Efficiency Requirements

Additional to all policy requirements for request justification and
approval, the organization must not have inefficient utilization of
resources equivalent in aggregate to the resource otherwise available to
them via section 4.10 and all prior resources received under section
4.10 must continue to meet justification and initial requirements.

4.10.4 (Un)availability of Transfers

Resources granted under section 4.10 will not be available for transfer
under 8.3 and may be subject to additional scrutiny for transfers under
8.2 to ensure that the use of the resources continue to meet initial
policy requirements.

4.10.5 Reserved Pools creation and Replenishment

The following Pools will be created for reserved resources. Upon
complete consumption of any defined pool resources, it will be
replenished, if or when resources to do so become available, at the same
ratio of initial reservation from the resources available via 10.4.2,
but not to exceed the initial sizes. ARIN is encouraged to manage
resources as they become available to anticipate this need and to
attempt for maximum aggregation. Each of the pools, and preferably all,
must be contained within a single prefix.

4.10.5.1 New Entrants Pool

A pool, initially sized at /10, available for organizations who do not
hold any Direct ARIN or Legacy IPv4 resources.

4.10.5.2 Small Organization Growth Pool

A pool, initially sized at /11, available for organizations that are
current holders of Direct ARIN or Legacy IPv4 resources, but no larger
in total than 16 times the minimal allocations size.

4.10.5.3 Pools for IPv6 Migration

These pools, described in 4.10.5.3.1 and 4.10.5.3.2, are for allocations
and assignments which must be justified by immediate IPv6 deployment
requirements.

Allocations and assignments will have a minimal unit of /28 and a
maximum unit of /24 without any concern for prevailing normative routing
policies.

4.10.5.3.1 Small Organization IPv6 Migration Pool

A pool, initially sized at /12, available for organization that are
current holders of  Direct ARIN or Legacy IPv4 resources, but no larger
in total than 64 times the minimal allocation size.

4.10.5.3.2 Multihomed Organization IPv6 Migration Pool

A pool, initially sized at /12, available only for multihomed
organizations who would not otherwise qualify for any resources except
as per 4.10.5.3 and could not otherwise meet their need with any other
PI resources available.

4.10.5.3.3 Examples of Immediate IPv6 Deployment Requirements

Examples of such needs include IPv4 addresses for dual stacking key
servers such as DNS, content load balancers, firewalls, key routers and
gateways, or for translators such as NAT-PT or NAT464 and for similar
published standard purposes.

4.10.5.3.4 Subsequent Allocations from Migration to IPv6 Pools

Organizations receiving resources from these pools must not hold more
than two prefixes from these pools at any time. ARIN should size the
subsequent resource to permit the organization to renumber out of the
previous resources from this pool, if prefix expansion is unavailable.
To minimize the need for renumbering, ARIN should use sparse allocation
strategies for the 4.10.5.3 pools.

4.10.6 Reserved Pools Usage Reporting

Annual statistics and reporting will be available on the utilization of
these pools, including but not limited to, total utilization, requests
fulfilled, declined requests, requests refused by category of rejection
cause and number of organizations who have received multiple allocations
under any portion of this section.

4.10.7 Policy Duration

No part of 4.10 will be active before execution of 10.4.2, after which
time and upon ARIN determination that there is no longer any significant
use of any of the pools for a period of two years,  this section will
cease to be active and may be removed, aside from 4.10.8. ARIN may
remove any pool defined by this section if there is no activity for that
pool for any period of four years following activation. No portion of
Section 4.10, other than 4.10.8,  will apply to allocations from a pool
subsequent to the pool's removal.

4.10.8 Pool Prefix List Publication

ARIN will publish a list of all pool prefixes with active resources,
with the minimum and maximum prefix size allocated from the pool.


##### Rationale: #####

This proposal is intended to apply both to ISP's and to End Users and
only for IPv4 resources. This proposal intends to expand upon the
concepts originally introduced into policy section 4.10 by merging
sections 4.10 requirements and intended uses, with some modifications,
along with additional pool definitions. It can coexist with other
proposals, providing the availability of the requested sizes for the
reserved pools are preserved in combination with any other policy. Other
proposals that modify minimum allocation sizes and justification
requirements will have indirect effects on the clauses of this section.
This is intentional.

The rationale has a short and long version.

Short Version:

As per data currently available, a /9 would fuel current burn rate for
approximately two months which is ridiculously short. This burn time
could be exchanged as a reasonable and small price to pay to receive in
return a number of years of access for new organizations and lifeblood
for organizations on their way to migration to IPv6.

This proposal believes it is incumbent on ARIN and its community, as an
integral portion of its stewardship duties, to make its best good faith
effort to lessen the impact depletion will have on all, but especially
on the under-served.

Long Version:

The long version is divided into two sections. One section will provide
rationale for the entire proposal as a whole. The other will provide
rationale for each individual sub-section.

The rationale is intentionally overly verbose.

A) Rationale for the Proposal as a Whole:

This proposal is founded on the belief that there is a strong likelihood
that IPv4 service and interoperability will remain of critical
importance for new or growing small organizations, as well as large
established organizations, for quite some time after IANA free pool
depletion.

It is expected that those who believe otherwise should have no
objections to this proposal, since it would effectively be a no-op.

The pools in total will comprise /9, which is half of the /8 allocated
under 10.4.2, which represents the end of IPv4 availability based solely
on need.

A /9 burn rate is less than two months according to current statistics.
This proposal believes we can make better use of a /9 other than two
months additional burn.

With a minimal allocation of /22 or /20 this proposal should provide
some years of space available for the organizations described under 4.10

A /9 would not suffice the needs of organizations not described under
4.10 and it is expected that the minimal resources available under 4.10
are easily obtainable by the categories of organizations who do not
qualify under 4.10, either from existing resources or from transfers
allowed under section 8.3 These resources are not intended for use by an
organization attempting to grow any existing IPv4 customer base to the
exclusion of IPv6. It is unlikely that they will get very far by
attempting to do so.

These resources are not intended for use by an organization with sizable
direct allocations or legacy IPv4 resources. Non ARIN RIR resources are
not addressed by policy, but perhaps should be excluded as well.

The proposal is structured in such a way as to reduce some potential
unfair advantages larger incumbents will have post IANA free pool
runout, while not subjecting them to overly unfair unavailability of
resources.

This proposal is not specifically targeted as to address any historical
imbalance, perceived or otherwise, between large and small organizations.

ARIN staff is requested to provide some estimated projections numbers,
with the intention being to be able to answer questions of this nature
in order to obtain a clear view as to the alternatives to the proposal
and the effect the proposal may have.

- How many Xlarge member organizations not qualifying under section 4.10
would have their requests satisfied by a /9 and for how long?

- How many Large member organizations not qualifying under section 4.10
would have their requests satisfied by a /9 and for how long?

- How many Medium member organizations not qualifying under section 4.10
would have their requests satisfied by a /9 and for how long?

- How many Small member organizations not qualifying under section 4.10
would have their requests satisfied by a /9 and for how long?

- To how many organizations and for how long could section 4.10.5.1 apply?

- To how many organizations and for how long could section 4.10.5.2 apply?

- To how many organizations and for how long could section 4.10.5.3.1 apply?

- To how many organizations and for how long could section 4.10.5.3.2 apply?

The size of the pools, the three month window and the size of existing
resource relative to the requested resources are semi-arbitrarily
chosen, the goal is to obtain 5 years or more of resources under these
policies, while not consuming more than a /9. ARIN staff
projections/estimated would be very helpful in refining those numbers.

Other than the 4.10.5.3 pools, these numbers are also very dependent on
the governing minimal allocation sizes, which can be as small as /22.
For example, that would provide for 4000 new organizations under 4.10.5.1

It is expected that opposition to this proposal can fall into one of
many categories, indication of which category opposition falls into will
be welcome, such as the following.

- Opposition to size of pools, length of windows, size of existing
resources.

- Opposition to the number of pools or any of the specific pools purposes.

- Opposition towards any of the specific details and restrictions of
this proposed policy.

- Opposition in general towards changing ARIN policies with regards to
allocation of IPv4 resources in response to IANA free pool depletion.

- Opposition in general towards changing ARIN policies specifically in
this manner.

Any and all feedback is welcome.


B) Rationale per Individual Sub-Section:

4.10 Minimum Allocations or Assignments from Reserved Pools

Free pool runout spells the end of needs based allocation available for
all. This proposal refines the idea of need to include those who need it
more than others, and attempts to preserve needs based allocation
availability for as long as possible for as many organizations with
acute need as possible.

Excluding the possibility of huge returns of IPv4 resources to ARIN,
this is the only way that needs-based allocation remains directly
relevant for any extended degree of time following IANA free pool runout
along with subsequent RIR depletion, and the end of general availability
of IPv4 resources.

The resources described as available under these sections are trivial in
size to any organization not meeting these sections definitions.

As further justification for this proposal, these pools will dissuade
hoarding and artificial scarcity which could otherwise arise if the only
other  availability of any IPv4 resources was under section 8 transfer
mechanisms or other non policy mechanisms.

4.10.1 Affiliation of Organizations

This provision is designed to give ARIN the power to prevent
organizations who otherwise would not qualify, from constructing
relationships with organizations for the purposes of taking advantage of
the resources those organizations would now qualify and receive under
section 4.10

It would be ARIN responsibility to tailor its threshold of reasonable
demonstration of un-affiliation as they see fit to conform with the
intent of this provision.

4.10.2 Qualifying Organizations Request Fulfillment

Organizations will not be forced to accept allocations from these pools,
but instead can take advantage of any other policy mechanism available,
such as waiting lists or transfers. However, if they do accept
fulfillment of the request under 4.10, the request is considered over
and done with and they must create a new one for any further need.

This section makes it ARIN's responsibility to perform a first pass on
the request and to extend the opportunity to the organization to request
fulfillment of their otherwise unfulfillable request from pools defined
under section 4.10

Only at that point will the organization need to show qualifications and
conformance with the provisions of 4.10

The goal here is to minimize the complexity involved in the application
process for organizations, since ARIN should be able to form a decent
impression on the likelihood of successful application of section 4.10
without the organization specifically requesting it.

The window is designed to prevent organizations from collecting from all
pools at once or in rapid succession.

4.10.3 Additional Efficiency Requirements

Organizations are to be prevented from taking advantage of these
sections if their utilization, while otherwise justified,  is
inefficient enough that equivalent resources are internally available.

4.10.4 (Un)availability of Transfers

Transfers of resources obtained under 4.10 without the accompanying
services utilizing them is incompatible with the goals as described, and
should be strongly discouraged.

4.10.5 Reserved Pools creation and Replenishment

If it works well ARIN should do more of it, if it possibly can.

4.10.5.1 New Entrants Pool

It is part of ARIN obligations of  IPv4 stewardship to attempt to
preserve the ability for new organizations to enter the IPv4 marketplace
for as long as it exists. If IPv4 resources are no longer generally
available, either from ARIN or otherwise, existing large resource
holders could be viewed as a cartel or consortium of incumbents
passively or actively preventing entrance to new organizations. ARIN
could also be viewed as a contributing cause for this undesirable situation.

There is no more acute need for IPv4 resources than those of an
organization who has none and still needs to provide critical services
for interoperability with an IPv4 internet even while focusing on the
more available IPv6. This assumes that for the general market, an IPv6
only provider may not be applicable for quite some time.

Inaction on good stewardship objectives creates non technical liabilities.

4.10.5.2 Small Organization Growth Pool

Organizations of very small size will have limited ability to stay in
business long enough to migrate to IPv6 if they cannot meet even a
limited portion of growth of their

IPv4 population. As an example, a minimal allocation under this policy
of /20 to /22 to an organization with a total of /16 to /18 allows them
6 percent growth.

Percentages smaller than that are not likely to be of much benefit.

For this size organization, there is very little likelyhood that
internal scavenging or other mechanisms will be practical and available
for them to otherwise continue to survive the migration to IPv6.

These organizations may also not be prepared enough to qualify under
4.10.5.3

Larger sized organizations growth objectives could not be met by ARIN at
this point for any significant percentage point no matter what, and they
would be more likely to have mechanisms available to obtain the
equivalent resources available under this policy, whereas the new or
small organizations may not.

ARIN stewardship responsibilities include all reasonable attempts to
address the upcoming scenario where large organizations can take
advantage of the crunch time between IPv4 and IPv6 wider utilization to
drive smaller competitors out of business by passively denying them
number resources available to the larger organization trivially from
other sources than ARIN, internal or external to the organization.

4.10.5.3 Pools for IPv6 Migration

The needs of an organization for IPv4 resources to migrate to IPv6
should take precedence over the needs of an organization trying to grow
their IPv4 utilization regardless of the industries need to migrate to IPv6.

Smaller organizations may feel particularly unable to proceed with IPv6
migration at any faster pace than the larger incumbent organizations.

This is consistent with ARIN goals of encouraging migration to IPv6 and
it is proper stewardship of IPv4 resources to prefer to satisify the
needs of the organization who are doing this activity than the needs of
the organizations who are not.

The size restriction is based on the assumption that organizations who
are the holders of that much more resources can obtain the limited
resources available via this section through other means . For example
if the minimal allocation is a /22 section this restriction limits
organizations who hold a /16. If the minimum allocation is /20,
organizations with more than /14 are restricted.

With either size allocated space, it should not be all that difficult
for an organization to scavenge up a /22 or /20.

ARIN encouragement of successful migration to IPv6 can result in return
of IPv4 resources available for all, so everybody wins.

As operators insist that ARIN does not set routing policies, applicants
who can only justify the minimum space /28 will get that, and routing it
is up to them. It is expected that no organization will be requesting
/28 unless it is actually routable and unobtainable anyother way, so
this clause is for a doomsday scenario.

4.10.5.3.1 Small Organization IPv6 Migration Pool

This pool is restricted to small organizations who are unlikely to have
the resources available otherwise.

4.10.5.3.2 Multihomed Organization IPv6 Migration Pool

This pool is explicitly available to any multihomed organization who
cannot otherwise qualify for resources. If an organization was only able
to claim that they need IPv4 to migrate and that they had no space, they
would automatically qualify for a minimal allocation of /28, if they
wanted it. The intent is to eliminate any concern that there is barrier
to entry and allows organizations to be able get something no matter how
small.

4.10.5.3.4 Subsequent Allocations from Migration to IPv6 Pools

This contains some examples of migration uses. This is not intended to
be exhaustive. ARIN staff may exercise their discretion. It is not
expected that there should be any need for them to be zealous, the small
size of the resources available should be dissuasive enough.

4.10.5.3.4 Subsequent Allocations from Migration to IPv6 Pools

This sections requires that subsequent allocations from this policy
require a renumber and return.

4.10.6 Reserved Pools Usage Reporting

The reporting that ARIN performs is critically important to help ARIN
members and policy participants to understand the effect of policy and
to identify problematic patterns. The report data may reveal that pools
are being underutilized or overutilized or misutilized and could prompt
policy action to correct the utilization  patterns.

This will allow the community as a whole to perform reviews on this policy.

4.10.7 Policy Duration

This policy is fairly complex and places burden on ARIN staff. If IPv6
transition or other factors combine to cause this pools defined to be
unused for an extended period of time, ARIN should be able to remove it.
If all of them are inactive, then this policy is obsolete and should be
removable. It is intended that pools continue to be documented
historically for route filter assistance.

4.10.8 Pool Prefix List Publication

While ARIN refrains from directly influencing or controlling routing
policy, ARIN should be encouraged to take steps to allow routing
operators to make informed decisions with their routing policies. This
section puts into writing something that ARIN performs normally.


Timetable for implementation: Simultaneously with execution of 10.4.2








From michael.dillon at bt.com  Thu Apr 22 15:05:43 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 22 Apr 2010 20:05:43 +0100
Subject: [arin-ppml] Policy Proposal 110: Preservation of minimal IPv4
	Resources for New and Small Organizations and for IPv6 Transition
In-Reply-To: <4BD0998F.60900@arin.net>
Message-ID: <28E139F46D45AF49A31950F88C49745805D9CBAC@E03MVZ2-UKDY.domain1.systemhost.net>

> Policy Proposal: Preservation of minimal IPv4 Resources for 
> New and Small Organizations and for IPv6 Transition

I am opposed to creating or enabling ghettoes for those who
don't fully understand what they are getting themselves into.

Any small or new organization can always get access to the 
IPv4 Internet either by buying an IPv4 Internet service or
by buying an IPv6 Internet service from an ISP who operates
a good set of proxy services.

When IPv4 resources get scarce, helping small groups throw
good money after bad, is not a nice thing to do. Far better
to practice tough love and point out that the cupboard is
bare, but the IPv6 soup kitchen down the street serves
tasty and nutritious meals that will keep them alive and
help them thrive in the future.

--Michael Dillon


From farmer at umn.edu  Fri Apr 23 09:35:15 2010
From: farmer at umn.edu (David Farmer)
Date: Fri, 23 Apr 2010 08:35:15 -0500
Subject: [arin-ppml] Policy Proposal 110: Preservation of minimal IPv4
 Resources for New and Small Organizations and for IPv6 Transition
In-Reply-To: <28E139F46D45AF49A31950F88C49745805D9CBAC@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745805D9CBAC@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4BD1A213.1060304@umn.edu>

michael.dillon at bt.com wrote:
>> Policy Proposal: Preservation of minimal IPv4 Resources for 
>> New and Small Organizations and for IPv6 Transition
> 
> I am opposed to creating or enabling ghettoes for those who
> don't fully understand what they are getting themselves into.
> 
> Any small or new organization can always get access to the 
> IPv4 Internet either by buying an IPv4 Internet service or
> by buying an IPv6 Internet service from an ISP who operates
> a good set of proxy services.
> 
> When IPv4 resources get scarce, helping small groups throw
> good money after bad, is not a nice thing to do. Far better
> to practice tough love and point out that the cupboard is
> bare, but the IPv6 soup kitchen down the street serves
> tasty and nutritious meals that will keep them alive and
> help them thrive in the future.
>
> --Michael Dillon

My initial reaction to this proposal was similar to Micheal's.

However, taking a little closer look, if you eliminated the following 
two sections most of the rest of the proposal I believe is within the 
original intent of 2008-5.

4.10.5.1 New Entrants Pool

4.10.5.2 Small Organization Growth Pool

While I'm willing to be convinced otherwise, but I believe I would need 
to see overwhelming support from most of the community, in order to even 
think about creating these two additional pools.

To review 2008-5, see the following;

https://www.arin.net/policy/proposals/2008_5.html

Eliminating those two sections, probably changing the title, and maybe 
some other minor edits, I believe would mostly eliminate my personal 
objections to this proposal.

That would leave this proposal with what looks to me, like a good start 
at some well needed additional guidance for ARIN staff in doling out the 
/10 that has been reserved for IPv6 transition by 2008-5.  Including 
what looks like some reasonable additional protections to prevent abuse 
of this pool and preserve it for its intended purpose.

So, if this were limited to providing additional guidance for the IPv6 
transition pool already reserved, I think this could be a useful policy.

But, if you think those two pools are a good idea please let me and the 
rest of AC know that.

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


From jmaimon at chl.com  Fri Apr 23 11:42:09 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Fri, 23 Apr 2010 11:42:09 -0400
Subject: [arin-ppml] Policy Proposal 110: Preservation of minimal IPv4
 Resources for New and Small Organizations and for IPv6 Transition
In-Reply-To: <4BD1A213.1060304@umn.edu>
References: <28E139F46D45AF49A31950F88C49745805D9CBAC@E03MVZ2-UKDY.domain1.systemhost.net>
	<4BD1A213.1060304@umn.edu>
Message-ID: <4BD1BFD1.3010706@chl.com>



David Farmer wrote:
> michael.dillon at bt.com wrote:
>>> Policy Proposal: Preservation of minimal IPv4 Resources for New and
>>> Small Organizations and for IPv6 Transition

>> Far better
>> to practice tough love and point out that the cupboard is
>> bare, but the IPv6 soup kitchen down the street serves
>> tasty and nutritious meals that will keep them alive and
>> help them thrive in the future.
>>
>> --Michael Dillon
>
> My initial reaction to this proposal was similar to Micheal's.


I find it absurd to behave as if IPv6 is so toxic the only way it will 
take hold is if ipv4 cant be had for money or love.

We should consider the cost of failure, of being wrong, that the ipv6 
soup is stone soup with just the stone.

I dont believe it is defensible to stand up and say that we knew this 
was coming and we still could not agree to spare a bit of space to try 
and protect those likely to be most vulnerable.

What you might call tough love may be interpreted quite differently by 
others.

And if it comes to pass that everyone joyfully switches to ipv6 without 
a backwards glance, what was the harm?

>
> So, if this were limited to providing additional guidance for the IPv6
> transition pool already reserved, I think this could be a useful policy.
>

I appreciate all the feedback.

Joe


From cgrundemann at gmail.com  Fri Apr 23 12:36:29 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Fri, 23 Apr 2010 10:36:29 -0600
Subject: [arin-ppml] Policy Proposal 110: Preservation of minimal IPv4
	Resources for New and Small Organizations and for IPv6 Transition
In-Reply-To: <4BD0998F.60900@arin.net>
References: <4BD0998F.60900@arin.net>
Message-ID: <l2l443de7ad1004230936wa5972c12k5ecc3bf4b3cfa6a3@mail.gmail.com>

On Thu, Apr 22, 2010 at 12:46, Member Services <info at arin.net> wrote:
<snip>
> ##### Rationale: #####
>
> This proposal is intended to apply both to ISP's and to End Users and
> only for IPv4 resources. This proposal intends to expand upon the
> concepts originally introduced into policy section 4.10 by merging
> sections 4.10 requirements and intended uses, with some modifications,
> along with additional pool definitions. It can coexist with other
> proposals, providing the availability of the requested sizes for the
> reserved pools are preserved in combination with any other policy. Other
> proposals that modify minimum allocation sizes and justification
> requirements will have indirect effects on the clauses of this section.
> This is intentional.
<snip>

I oppose this proposal.

IMVHO: This proposal takes two possibly good ideas, throws them in a
blender and adds unnecessary complication to the mix.

Let me explain:

I see the two primary ideas presented as:
1) Modify section 4.10 (which reserves IPv4 space for IPv6 migrations).
2) Reserve an IPv4 block for new entrants.

My first piece of advice to the author is to acknowledge that these
goals are almost completely unrelated to each other; they do not need
to be part of the same policy and probably should not be part of the
same proposal if you wish to ever gain consensus. Separating them into
two distinct proposals will make the details of what and why you are
proposing them much more clearly understandable.

As far as the two ideas themselves, let me start with the second. I
could possibly be convinced that we need a block reserved from the
last /8 specifically for new entrants (those w/out any current ARIN
resources). I am unlikely to be convinced that this requires a change
to section 4.10 though. A much better approach IMO would be to add a
section 4.11 for this new purpose and to reserve a block (another /10
perhaps) specifically for this new purpose.

To the first idea of modifying the current "Dedicated IPv4 block to
facilitate IPv6 Deployment," I am again open to improvements but I am
not sure that what is being proposed here is an improvement, partly
because of the seemingly unnecessary complications being introduced.

If this proposal were separated into two distinct (and clear)
proposals I would be happy to entertain them both individually and
discuss them on their own merits. As it stands I will very likely
remain opposed to this incarnation and thus more detailed analysis is
withheld.

$0.02
~Chris


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


-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From michael.dillon at bt.com  Fri Apr 23 13:24:41 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 23 Apr 2010 18:24:41 +0100
Subject: [arin-ppml] Policy Proposal 110: Preservation of minimal IPv4
	Resources for New and Small Organizations and for IPv6 Transition
In-Reply-To: <4BD1BFD1.3010706@chl.com>
Message-ID: <28E139F46D45AF49A31950F88C49745805E1498D@E03MVZ2-UKDY.domain1.systemhost.net>

> We should consider the cost of failure, of being wrong, that 
> the ipv6 soup is stone soup with just the stone.

Quite a low risk of that considering how widely deployed IPv6 is
currently, carrying the same level of traffic as the entire IPv4
Internet in 1999.

> I dont believe it is defensible to stand up and say that we 
> knew this was coming and we still could not agree to spare a 
> bit of space to try and protect those likely to be most vulnerable.

In another thread it was clear that it is possible to set up
IPv6 only services with a little bit of help from DNS service
providers and email service providers that already have IPv4
addresses.

> What you might call tough love may be interpreted quite 
> differently by others.

Everything is interpreted differently by other people.

I have yet to see a concrete example of a scenario in which
ARIN could make things better by giving out small amounts of
IPv4 address space, after everyone else has been FORCED into
IPv6 deployment by IPv4 exhaustion. 

It is too late to do this kind of thing. IPv4 exhaustion will
happen in your next fiscal year. There could be a run on addresses
at any moment that would pull that date closer to us by several
months. Even passing this policy proposal would pull the date closer.

When the police order people out of a hurricane strike zone, ahead
of landfall, they are willfully damaging small businesses that
might be able to continue operating during the hurricane. They
do this on two counts, first by forcing the owners and staff
to evacuate, and secondly by forcing their potential customers
to evacuate. Nobody seriously takes the police to task for
being unfair to small business while the Macdonalds' restaurants
away from the landfall zone do extra business.

This is a similar situation. The global IPv4 address supply 
HAS RUN OUT! The last few dregs are still being distributed for
the next 18 months or so, but many of us won't be able to get
any of those addresses. Most ISPs are already in a position
where their supply has ceased. It's like a force of nature
that we can't control, and nobody is going to seriously sue
ARIN because they didn't reserve a few addresses for foolish
little organizations and startups.

The smart money is now betting on IPv6.

--Michael Dillon


From Wesley.E.George at sprint.com  Fri Apr 23 13:59:03 2010
From: Wesley.E.George at sprint.com (George, Wes E [NTK])
Date: Fri, 23 Apr 2010 12:59:03 -0500
Subject: [arin-ppml] Policy Proposal 110: Preservation of minimal IPv4
 Resources for New and Small Organizations and for IPv6 Transition
In-Reply-To: <4BD0998F.60900@arin.net>
References: <4BD0998F.60900@arin.net>
Message-ID: <F7EB0A7C707E39409A73CD0353242551A8921B3FBC@PLSWM01C.ad.sprint.com>

I'm opposed to this proposal, and many of my reasons have already been articulated by others, especially Chris.

I think that the existing text of 4.10 stands on its own. When we're down to 1 /8 in the global pool, if any new orgs are attempting to offer services without IPv6 in a way that doesn't qualify them for space under 4.10 already, then we have every right to expect them to fail on account of their own short-sightedness. The lack of IPv4 space is going to be a barrier to entry for all sorts of business plans until IPv6 really has ubiquitous deployment, and I see no reason to try to give people false hope against that reality. As it is, we have 4.10, the pending 2010-1, and the transfer listings all to help cushion runout, as well as the potential of getting PA space from those that still have some.

Thanks,
Wes

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services
Sent: Thursday, April 22, 2010 2:47 PM
To: arin-ppml at arin.net
Subject: [arin-ppml] Policy Proposal 110: Preservation of minimal IPv4 Resources for New and Small Organizations and for IPv6 Transition

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

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

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

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

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

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

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal: Preservation of minimal IPv4 Resources for New and
Small Organizations and for IPv6 Transition

1. Proposal Originator: Joe Maimon

3. Proposal Version: 1

4. Date: 22 April 2010

5. Proposal type: New, Modify

6. Policy term: Permanent

7. Policy statement:

[Replace 4.10 in whole with the following.]

4.10 Minimum Allocations or Assignments from Reserved Pools

Upon execution of 10.4.2, ARIN will reserve pools of addresses
unavailable to fulfill any requests except as detailed in this section.
These pools will be utilized only for the minimal sized allocations or
assignments for properly justified requests, regardless of the size of
the request, under the following provisions, and only if ARIN is
otherwise unable to fulfill the request in entirety.

4.10.1 Affiliation of Organizations

To qualify under these sections organizations may be required to
demonstrate to reasonable satisfaction that they are not affiliated with
any other organizations for the intended purpose of qualifying under
these sections where they would not otherwise. All other aspects of
organization affiliations are not of specific concern to section

4.10.

4.10.2 Qualifying Organizations Request Fulfillment

Upon approval of an otherwise unfulfillable request, ARIN will determine
and notify the requester of section 4.10 applicability. Qualifying
organization may receive only one request fulfillment per three month
window from any of the pools defined in this section. Organizations may
decline to receive resources for their requests under these sections
without negating the request. Organizations who do receive resources
under these sections will have their request considered fully fulfilled
and completed.

4.10.3 Additional Efficiency Requirements

Additional to all policy requirements for request justification and
approval, the organization must not have inefficient utilization of
resources equivalent in aggregate to the resource otherwise available to
them via section 4.10 and all prior resources received under section
4.10 must continue to meet justification and initial requirements.

4.10.4 (Un)availability of Transfers

Resources granted under section 4.10 will not be available for transfer
under 8.3 and may be subject to additional scrutiny for transfers under
8.2 to ensure that the use of the resources continue to meet initial
policy requirements.

4.10.5 Reserved Pools creation and Replenishment

The following Pools will be created for reserved resources. Upon
complete consumption of any defined pool resources, it will be
replenished, if or when resources to do so become available, at the same
ratio of initial reservation from the resources available via 10.4.2,
but not to exceed the initial sizes. ARIN is encouraged to manage
resources as they become available to anticipate this need and to
attempt for maximum aggregation. Each of the pools, and preferably all,
must be contained within a single prefix.

4.10.5.1 New Entrants Pool

A pool, initially sized at /10, available for organizations who do not
hold any Direct ARIN or Legacy IPv4 resources.

4.10.5.2 Small Organization Growth Pool

A pool, initially sized at /11, available for organizations that are
current holders of Direct ARIN or Legacy IPv4 resources, but no larger
in total than 16 times the minimal allocations size.

4.10.5.3 Pools for IPv6 Migration

These pools, described in 4.10.5.3.1 and 4.10.5.3.2, are for allocations
and assignments which must be justified by immediate IPv6 deployment
requirements.

Allocations and assignments will have a minimal unit of /28 and a
maximum unit of /24 without any concern for prevailing normative routing
policies.

4.10.5.3.1 Small Organization IPv6 Migration Pool

A pool, initially sized at /12, available for organization that are
current holders of  Direct ARIN or Legacy IPv4 resources, but no larger
in total than 64 times the minimal allocation size.

4.10.5.3.2 Multihomed Organization IPv6 Migration Pool

A pool, initially sized at /12, available only for multihomed
organizations who would not otherwise qualify for any resources except
as per 4.10.5.3 and could not otherwise meet their need with any other
PI resources available.

4.10.5.3.3 Examples of Immediate IPv6 Deployment Requirements

Examples of such needs include IPv4 addresses for dual stacking key
servers such as DNS, content load balancers, firewalls, key routers and
gateways, or for translators such as NAT-PT or NAT464 and for similar
published standard purposes.

4.10.5.3.4 Subsequent Allocations from Migration to IPv6 Pools

Organizations receiving resources from these pools must not hold more
than two prefixes from these pools at any time. ARIN should size the
subsequent resource to permit the organization to renumber out of the
previous resources from this pool, if prefix expansion is unavailable.
To minimize the need for renumbering, ARIN should use sparse allocation
strategies for the 4.10.5.3 pools.

4.10.6 Reserved Pools Usage Reporting

Annual statistics and reporting will be available on the utilization of
these pools, including but not limited to, total utilization, requests
fulfilled, declined requests, requests refused by category of rejection
cause and number of organizations who have received multiple allocations
under any portion of this section.

4.10.7 Policy Duration

No part of 4.10 will be active before execution of 10.4.2, after which
time and upon ARIN determination that there is no longer any significant
use of any of the pools for a period of two years,  this section will
cease to be active and may be removed, aside from 4.10.8. ARIN may
remove any pool defined by this section if there is no activity for that
pool for any period of four years following activation. No portion of
Section 4.10, other than 4.10.8,  will apply to allocations from a pool
subsequent to the pool's removal.

4.10.8 Pool Prefix List Publication

ARIN will publish a list of all pool prefixes with active resources,
with the minimum and maximum prefix size allocated from the pool.


##### Rationale: #####

This proposal is intended to apply both to ISP's and to End Users and
only for IPv4 resources. This proposal intends to expand upon the
concepts originally introduced into policy section 4.10 by merging
sections 4.10 requirements and intended uses, with some modifications,
along with additional pool definitions. It can coexist with other
proposals, providing the availability of the requested sizes for the
reserved pools are preserved in combination with any other policy. Other
proposals that modify minimum allocation sizes and justification
requirements will have indirect effects on the clauses of this section.
This is intentional.

The rationale has a short and long version.

Short Version:

As per data currently available, a /9 would fuel current burn rate for
approximately two months which is ridiculously short. This burn time
could be exchanged as a reasonable and small price to pay to receive in
return a number of years of access for new organizations and lifeblood
for organizations on their way to migration to IPv6.

This proposal believes it is incumbent on ARIN and its community, as an
integral portion of its stewardship duties, to make its best good faith
effort to lessen the impact depletion will have on all, but especially
on the under-served.

Long Version:

The long version is divided into two sections. One section will provide
rationale for the entire proposal as a whole. The other will provide
rationale for each individual sub-section.

The rationale is intentionally overly verbose.

A) Rationale for the Proposal as a Whole:

This proposal is founded on the belief that there is a strong likelihood
that IPv4 service and interoperability will remain of critical
importance for new or growing small organizations, as well as large
established organizations, for quite some time after IANA free pool
depletion.

It is expected that those who believe otherwise should have no
objections to this proposal, since it would effectively be a no-op.

The pools in total will comprise /9, which is half of the /8 allocated
under 10.4.2, which represents the end of IPv4 availability based solely
on need.

A /9 burn rate is less than two months according to current statistics.
This proposal believes we can make better use of a /9 other than two
months additional burn.

With a minimal allocation of /22 or /20 this proposal should provide
some years of space available for the organizations described under 4.10

A /9 would not suffice the needs of organizations not described under
4.10 and it is expected that the minimal resources available under 4.10
are easily obtainable by the categories of organizations who do not
qualify under 4.10, either from existing resources or from transfers
allowed under section 8.3 These resources are not intended for use by an
organization attempting to grow any existing IPv4 customer base to the
exclusion of IPv6. It is unlikely that they will get very far by
attempting to do so.

These resources are not intended for use by an organization with sizable
direct allocations or legacy IPv4 resources. Non ARIN RIR resources are
not addressed by policy, but perhaps should be excluded as well.

The proposal is structured in such a way as to reduce some potential
unfair advantages larger incumbents will have post IANA free pool
runout, while not subjecting them to overly unfair unavailability of
resources.

This proposal is not specifically targeted as to address any historical
imbalance, perceived or otherwise, between large and small organizations.

ARIN staff is requested to provide some estimated projections numbers,
with the intention being to be able to answer questions of this nature
in order to obtain a clear view as to the alternatives to the proposal
and the effect the proposal may have.

- How many Xlarge member organizations not qualifying under section 4.10
would have their requests satisfied by a /9 and for how long?

- How many Large member organizations not qualifying under section 4.10
would have their requests satisfied by a /9 and for how long?

- How many Medium member organizations not qualifying under section 4.10
would have their requests satisfied by a /9 and for how long?

- How many Small member organizations not qualifying under section 4.10
would have their requests satisfied by a /9 and for how long?

- To how many organizations and for how long could section 4.10.5.1 apply?

- To how many organizations and for how long could section 4.10.5.2 apply?

- To how many organizations and for how long could section 4.10.5.3.1 apply?

- To how many organizations and for how long could section 4.10.5.3.2 apply?

The size of the pools, the three month window and the size of existing
resource relative to the requested resources are semi-arbitrarily
chosen, the goal is to obtain 5 years or more of resources under these
policies, while not consuming more than a /9. ARIN staff
projections/estimated would be very helpful in refining those numbers.

Other than the 4.10.5.3 pools, these numbers are also very dependent on
the governing minimal allocation sizes, which can be as small as /22.
For example, that would provide for 4000 new organizations under 4.10.5.1

It is expected that opposition to this proposal can fall into one of
many categories, indication of which category opposition falls into will
be welcome, such as the following.

- Opposition to size of pools, length of windows, size of existing
resources.

- Opposition to the number of pools or any of the specific pools purposes.

- Opposition towards any of the specific details and restrictions of
this proposed policy.

- Opposition in general towards changing ARIN policies with regards to
allocation of IPv4 resources in response to IANA free pool depletion.

- Opposition in general towards changing ARIN policies specifically in
this manner.

Any and all feedback is welcome.


B) Rationale per Individual Sub-Section:

4.10 Minimum Allocations or Assignments from Reserved Pools

Free pool runout spells the end of needs based allocation available for
all. This proposal refines the idea of need to include those who need it
more than others, and attempts to preserve needs based allocation
availability for as long as possible for as many organizations with
acute need as possible.

Excluding the possibility of huge returns of IPv4 resources to ARIN,
this is the only way that needs-based allocation remains directly
relevant for any extended degree of time following IANA free pool runout
along with subsequent RIR depletion, and the end of general availability
of IPv4 resources.

The resources described as available under these sections are trivial in
size to any organization not meeting these sections definitions.

As further justification for this proposal, these pools will dissuade
hoarding and artificial scarcity which could otherwise arise if the only
other  availability of any IPv4 resources was under section 8 transfer
mechanisms or other non policy mechanisms.

4.10.1 Affiliation of Organizations

This provision is designed to give ARIN the power to prevent
organizations who otherwise would not qualify, from constructing
relationships with organizations for the purposes of taking advantage of
the resources those organizations would now qualify and receive under
section 4.10

It would be ARIN responsibility to tailor its threshold of reasonable
demonstration of un-affiliation as they see fit to conform with the
intent of this provision.

4.10.2 Qualifying Organizations Request Fulfillment

Organizations will not be forced to accept allocations from these pools,
but instead can take advantage of any other policy mechanism available,
such as waiting lists or transfers. However, if they do accept
fulfillment of the request under 4.10, the request is considered over
and done with and they must create a new one for any further need.

This section makes it ARIN's responsibility to perform a first pass on
the request and to extend the opportunity to the organization to request
fulfillment of their otherwise unfulfillable request from pools defined
under section 4.10

Only at that point will the organization need to show qualifications and
conformance with the provisions of 4.10

The goal here is to minimize the complexity involved in the application
process for organizations, since ARIN should be able to form a decent
impression on the likelihood of successful application of section 4.10
without the organization specifically requesting it.

The window is designed to prevent organizations from collecting from all
pools at once or in rapid succession.

4.10.3 Additional Efficiency Requirements

Organizations are to be prevented from taking advantage of these
sections if their utilization, while otherwise justified,  is
inefficient enough that equivalent resources are internally available.

4.10.4 (Un)availability of Transfers

Transfers of resources obtained under 4.10 without the accompanying
services utilizing them is incompatible with the goals as described, and
should be strongly discouraged.

4.10.5 Reserved Pools creation and Replenishment

If it works well ARIN should do more of it, if it possibly can.

4.10.5.1 New Entrants Pool

It is part of ARIN obligations of  IPv4 stewardship to attempt to
preserve the ability for new organizations to enter the IPv4 marketplace
for as long as it exists. If IPv4 resources are no longer generally
available, either from ARIN or otherwise, existing large resource
holders could be viewed as a cartel or consortium of incumbents
passively or actively preventing entrance to new organizations. ARIN
could also be viewed as a contributing cause for this undesirable situation.

There is no more acute need for IPv4 resources than those of an
organization who has none and still needs to provide critical services
for interoperability with an IPv4 internet even while focusing on the
more available IPv6. This assumes that for the general market, an IPv6
only provider may not be applicable for quite some time.

Inaction on good stewardship objectives creates non technical liabilities.

4.10.5.2 Small Organization Growth Pool

Organizations of very small size will have limited ability to stay in
business long enough to migrate to IPv6 if they cannot meet even a
limited portion of growth of their

IPv4 population. As an example, a minimal allocation under this policy
of /20 to /22 to an organization with a total of /16 to /18 allows them
6 percent growth.

Percentages smaller than that are not likely to be of much benefit.

For this size organization, there is very little likelyhood that
internal scavenging or other mechanisms will be practical and available
for them to otherwise continue to survive the migration to IPv6.

These organizations may also not be prepared enough to qualify under
4.10.5.3

Larger sized organizations growth objectives could not be met by ARIN at
this point for any significant percentage point no matter what, and they
would be more likely to have mechanisms available to obtain the
equivalent resources available under this policy, whereas the new or
small organizations may not.

ARIN stewardship responsibilities include all reasonable attempts to
address the upcoming scenario where large organizations can take
advantage of the crunch time between IPv4 and IPv6 wider utilization to
drive smaller competitors out of business by passively denying them
number resources available to the larger organization trivially from
other sources than ARIN, internal or external to the organization.

4.10.5.3 Pools for IPv6 Migration

The needs of an organization for IPv4 resources to migrate to IPv6
should take precedence over the needs of an organization trying to grow
their IPv4 utilization regardless of the industries need to migrate to IPv6.

Smaller organizations may feel particularly unable to proceed with IPv6
migration at any faster pace than the larger incumbent organizations.

This is consistent with ARIN goals of encouraging migration to IPv6 and
it is proper stewardship of IPv4 resources to prefer to satisify the
needs of the organization who are doing this activity than the needs of
the organizations who are not.

The size restriction is based on the assumption that organizations who
are the holders of that much more resources can obtain the limited
resources available via this section through other means . For example
if the minimal allocation is a /22 section this restriction limits
organizations who hold a /16. If the minimum allocation is /20,
organizations with more than /14 are restricted.

With either size allocated space, it should not be all that difficult
for an organization to scavenge up a /22 or /20.

ARIN encouragement of successful migration to IPv6 can result in return
of IPv4 resources available for all, so everybody wins.

As operators insist that ARIN does not set routing policies, applicants
who can only justify the minimum space /28 will get that, and routing it
is up to them. It is expected that no organization will be requesting
/28 unless it is actually routable and unobtainable anyother way, so
this clause is for a doomsday scenario.

4.10.5.3.1 Small Organization IPv6 Migration Pool

This pool is restricted to small organizations who are unlikely to have
the resources available otherwise.

4.10.5.3.2 Multihomed Organization IPv6 Migration Pool

This pool is explicitly available to any multihomed organization who
cannot otherwise qualify for resources. If an organization was only able
to claim that they need IPv4 to migrate and that they had no space, they
would automatically qualify for a minimal allocation of /28, if they
wanted it. The intent is to eliminate any concern that there is barrier
to entry and allows organizations to be able get something no matter how
small.

4.10.5.3.4 Subsequent Allocations from Migration to IPv6 Pools

This contains some examples of migration uses. This is not intended to
be exhaustive. ARIN staff may exercise their discretion. It is not
expected that there should be any need for them to be zealous, the small
size of the resources available should be dissuasive enough.

4.10.5.3.4 Subsequent Allocations from Migration to IPv6 Pools

This sections requires that subsequent allocations from this policy
require a renumber and return.

4.10.6 Reserved Pools Usage Reporting

The reporting that ARIN performs is critically important to help ARIN
members and policy participants to understand the effect of policy and
to identify problematic patterns. The report data may reveal that pools
are being underutilized or overutilized or misutilized and could prompt
policy action to correct the utilization  patterns.

This will allow the community as a whole to perform reviews on this policy.

4.10.7 Policy Duration

This policy is fairly complex and places burden on ARIN staff. If IPv6
transition or other factors combine to cause this pools defined to be
unused for an extended period of time, ARIN should be able to remove it.
If all of them are inactive, then this policy is obsolete and should be
removable. It is intended that pools continue to be documented
historically for route filter assistance.

4.10.8 Pool Prefix List Publication

While ARIN refrains from directly influencing or controlling routing
policy, ARIN should be encouraged to take steps to allow routing
operators to make informed decisions with their routing policies. This
section puts into writing something that ARIN performs normally.


Timetable for implementation: Simultaneously with execution of 10.4.2






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


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



From owen at delong.com  Fri Apr 23 14:13:21 2010
From: owen at delong.com (Owen DeLong)
Date: Fri, 23 Apr 2010 11:13:21 -0700
Subject: [arin-ppml] Policy Proposal 110: Preservation of minimal IPv4
	Resources for New and Small Organizations and for IPv6 Transition
In-Reply-To: <28E139F46D45AF49A31950F88C49745805E1498D@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745805E1498D@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <EA968B74-B90F-4E6A-8793-FEE8AF6E20FD@delong.com>


On Apr 23, 2010, at 10:24 AM, <michael.dillon at bt.com> <michael.dillon at bt.com> wrote:

>> We should consider the cost of failure, of being wrong, that 
>> the ipv6 soup is stone soup with just the stone.
> 
> Quite a low risk of that considering how widely deployed IPv6 is
> currently, carrying the same level of traffic as the entire IPv4
> Internet in 1999.
> 
>> I dont believe it is defensible to stand up and say that we 
>> knew this was coming and we still could not agree to spare a 
>> bit of space to try and protect those likely to be most vulnerable.
> 
> In another thread it was clear that it is possible to set up
> IPv6 only services with a little bit of help from DNS service
> providers and email service providers that already have IPv4
> addresses.
> 
>> What you might call tough love may be interpreted quite 
>> differently by others.
> 
> Everything is interpreted differently by other people.
> 
> I have yet to see a concrete example of a scenario in which
> ARIN could make things better by giving out small amounts of
> IPv4 address space, after everyone else has been FORCED into
> IPv6 deployment by IPv4 exhaustion. 
> 
> It is too late to do this kind of thing. IPv4 exhaustion will
> happen in your next fiscal year. There could be a run on addresses
> at any moment that would pull that date closer to us by several
> months. Even passing this policy proposal would pull the date closer.
> 
I believe this policy would merely tighten up the requirements for
gaining access to the /10 set aside by an earlier policy for transitional
technologies.

While I have not made my mind up about this proposal yet, I do
not believe it will pull exhaustion closer.


> When the police order people out of a hurricane strike zone, ahead
> of landfall, they are willfully damaging small businesses that
> might be able to continue operating during the hurricane. They
> do this on two counts, first by forcing the owners and staff
> to evacuate, and secondly by forcing their potential customers
> to evacuate. Nobody seriously takes the police to task for
> being unfair to small business while the Macdonalds' restaurants
> away from the landfall zone do extra business.
> 
Not a great analogy because the small businesses away from the
landfall zone also do extra business.
> 

Owen




From jmaimon at chl.com  Fri Apr 23 17:53:53 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Fri, 23 Apr 2010 17:53:53 -0400
Subject: [arin-ppml] Policy Proposal 110: Preservation of minimal IPv4
 Resources for New and Small Organizations and for IPv6 Transition
In-Reply-To: <4BD0998F.60900@arin.net>
References: <4BD0998F.60900@arin.net>
Message-ID: <4BD216F1.6070009@chl.com>



Member Services wrote:

>>
>>
>> Policy Proposal: Preservation of minimal IPv4 Resources for New and
>> Small Organizations and for IPv6 Transition


Michael, George,

4.10 does not provide space to be used for addressing your customers if 
the reality happens to be that you cannot get or keep any customers 
without giving them some IPv4 addresses.

Many believe and most hope that IPv6 will be in a state where all those 
entering the market can and will want to do so with IPv6 at time of full 
depletion and extreme scarcity of IPv4, which takes effect some time 
after free pool depletion, not necessarily next fiscal year.

The possibility exists that it may still be impractical to build a small 
business or start a new one with ipv6 even when no ipv4 is available 
except from preexisting holders who may be viewed unfavorably as 
monopolistic cartels and may even behave in such a manner.

I believe failing to prepare adequately for that scenario is not only 
irresponsible but that it can be widely viewed and seized upon as 
evidence that we have acted irresponsibly.

I do not consider the existence of transfers, waiting lists and the 
current 4.10 to go far enough as to be adequate.

The existence of minimal resources could do much to temper negative 
tendencies inherent in markets for limited resources.

I am of the opinion that we need to behave responsibly and we need to do 
so visibly.

If IPv6 is not completely satisfactory in the common case for new or 
small growing entities that would be our failure.

Punishing them for our failure to properly establish IPv6 as a realistic 
alternative for complete networking and business opportunities is not 
going to fly.

It certainly would not be their fault. They werent even around.

On the other hand, if they can go IPv6 they will certainly do so, at 
which point this pool, like the transfer market, the waiting list, the 
listing service and the existing 4.10 pool will go largely unused and 
join the wide swaths of returned and no longer used IPv4.

I fail to see the down side. I would call this proposal insurance and 
good form, not false hope.

Chris, David,

4.10 is the only section currently where ARIN is directed to hold a 
specifically sized pool for specific purposes. The refinements, 
requirements and additions of more pools and purposes seemed to most 
naturally fit there. There is certainly some time and opportunity to try 
this from other tacks, but I expect this proposal to take a while to 
digest and I am in no rush to introduce other competing ones at this 
early point. Others may of course feel free to do so.

The goals of (the existing) 4.10 are specifically aimed towards those 
who have acute need of IPv4 even when there is none normally available 
from Arin. That is what this entire proposal is about, clarifying some 
needs and adding others.

Owen,

It actually doubles the /10 to a /9, divided differently, with new and 
different requirements for some of it, along with additional eligibilities.

That changes ARIN exhaustion dates by about a month, give or take a 
week, at current burn rates.

Thanks to all for the feedback.

Joe









From owen at delong.com  Fri Apr 23 19:59:01 2010
From: owen at delong.com (Owen DeLong)
Date: Fri, 23 Apr 2010 16:59:01 -0700
Subject: [arin-ppml] Policy Proposal 110: Preservation of minimal IPv4
	Resources for New and Small Organizations and for IPv6 Transition
In-Reply-To: <4BD216F1.6070009@chl.com>
References: <4BD0998F.60900@arin.net> <4BD216F1.6070009@chl.com>
Message-ID: <E59EDC2B-BB76-4ABD-85A5-C42C539DC179@delong.com>


On Apr 23, 2010, at 2:53 PM, Joe Maimon wrote:

> 
> 
> Member Services wrote:
> 
>>> 
>>> 
>>> Policy Proposal: Preservation of minimal IPv4 Resources for New and
>>> Small Organizations and for IPv6 Transition
> 
> 
> Michael, George,
> 
> 4.10 does not provide space to be used for addressing your customers if the reality happens to be that you cannot get or keep any customers without giving them some IPv4 addresses.
> 
Thanks for that clarification Joe.

Nor was it intended to.  I now oppose this proposal.

If we're going to give IPv4 out to people just to give it to their customers, it should be given based on current allocation/assignment rules.  The purpose of reserving the /10 was so that ANYONE who was implementing
new transitional services (such as new NAT-PT infrastructure, etc.) would be able to get small pieces of
IPv4 to make deployment of those transitional technologies possible. It _IS_ not intended to extend the
useful life of IPv4 for anyone.

In my opiion, this space absolutely should not be used to simply add more IPv4 customers to any provider.
The use case must be demonstrated to in some way advance the transition to IPv6 or provide temporary
legacy connectivity to IPv4 from IPv6 only customers. Otherwise, it does not fit the intent of 4.10.
> 
> The possibility exists that it may still be impractical to build a small business or start a new one with ipv6 even when no ipv4 is available except from preexisting holders who may be viewed unfavorably as monopolistic cartels and may even behave in such a manner.
> 
If that is the case, it will be a bad time to start an ISP. There are lots of factors that can make it a bad time to start an ISP. We've been through that before and we'll go through that again.

> I believe failing to prepare adequately for that scenario is not only irresponsible but that it can be widely viewed and seized upon as evidence that we have acted irresponsibly.
> 
I believe that locking up usable addresses for theoretical businesses that may not ever exist at a time when actual running businesses have a demonstrated need is a bigger example of acting irresponsibly.

> I do not consider the existence of transfers, waiting lists and the current 4.10 to go far enough as to be adequate.
> 
> The existence of minimal resources could do much to temper negative tendencies inherent in markets for limited resources.
> 
As I now understand the intent of your policy, it would not accomplish what you intend.  It would, instead, either create a situation where various existing organizations found ways to get in under the policy and get the space, or, it would get ARIN sued for squatting on address space that should be otherwise issued to organizations with demonstrated need.

Also, what you call "negative tendencies of a market", I am starting to call "incentive to move to IPv6."

> I am of the opinion that we need to behave responsibly and we need to do so visibly.
> 
Agreed.  Difference is that I think we have. I agree that 4.10 needs improvement and clarification... SOON.

However, it does not need to be gutted and replaced  by this.

> If IPv6 is not completely satisfactory in the common case for new or small growing entities that would be our failure.
> 
I disagree.

> Punishing them for our failure to properly establish IPv6 as a realistic alternative for complete networking and business opportunities is not going to fly.
> 
I guess that's a matter of perspective. I think I am on record as one of the most liberal champions of small end users and providers. I think I also have a pretty good track record in this area. Still, I don't see this as "punishment" so much
as they are in the same sinking ship with the rest of us. I don't see why the person in the rowboat next to the titanic
should get priority on a lifeboat. (which is how I see the clarification above)

> It certainly would not be their fault. They werent even around.
> 
Then it is a risk they should consider prior to launching a business that is dependent on IPv4.

> On the other hand, if they can go IPv6 they will certainly do so, at which point this pool, like the transfer market, the waiting list, the listing service and the existing 4.10 pool will go largely unused and join the wide swaths of returned and no longer used IPv4.
> 
> I fail to see the down side. I would call this proposal insurance and good form, not false hope.
> 
We can agree to disagree.

> Chris, David,
> 
> 4.10 is the only section currently where ARIN is directed to hold a specifically sized pool for specific purposes. The refinements, requirements and additions of more pools and purposes seemed to most naturally fit there. There is certainly some time and opportunity to try this from other tacks, but I expect this proposal to take a while to digest and I am in no rush to introduce other competing ones at this early point. Others may of course feel free to do so.
> 
> The goals of (the existing) 4.10 are specifically aimed towards those who have acute need of IPv4 even when there is none normally available from Arin. That is what this entire proposal is about, clarifying some needs and adding others.
> 
The goals of 4.10 are, actually, not that.

The goals of 4.10 were to ensure we didn't create a "can't get there from here" problem where all IPv4 addresses were consumed for business as usual and the sudden need to deploy something like NAT-PT to provide for IPv4 services access by IPv6 clients would not be rendered impossible to deploy for want of IPv4 addresses with which to deploy it.

I think that represents good stewardship. I think that it needs to be tightened up a little bit with some clarification so that it's use case doesn't get over-expanded.

> Owen,
> 
> It actually doubles the /10 to a /9, divided differently, with new and different requirements for some of it, along with additional eligibilities.
> 
We actually started out trying to set aside the full /8. We tried compromising to the /9. The community was actually pretty clear in their desire to limit this reservation to a /10.

> That changes ARIN exhaustion dates by about a month, give or take a week, at current burn rates.
> 
Yeah, that sounds like an accurate estimate.  Sorry I missed that in my first read-through.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100423/a8d04cf6/attachment.htm>

From baptista at publicroot.org  Sat Apr 24 12:32:35 2010
From: baptista at publicroot.org (Joe Baptista)
Date: Sat, 24 Apr 2010 12:32:35 -0400
Subject: [arin-ppml] ARIN Policy Clarification: Micro-Allocations
In-Reply-To: <AD990F00C9E042498CCFCEC16E02B53A@TAKA>
References: <AD990F00C9E042498CCFCEC16E02B53A@TAKA>
Message-ID: <s2g874c02a21004240932ze64c7a70rc84f6cfe5fa68002@mail.gmail.com>

I'm going to take this opportunity to offer my support for this proposal.
However, I would like to stress and make very clear that under no
circumstances does my support for this proposal in any way constitute an
endorsement or support of the root services discussed below by Mr. Palmer.
In fact I do not consider Mr. Palmer's root system to qualify as viable root
infrastructure.

John and I have discussed this at length on the GA. When ARIN develops
policy it is critical that a certain measure of responsibility be taken to
properly qualify the allocation. Critical infrastructure implies some degree
of trust or approval or approval by a government body or standard be applied
to justify the allocation.

It's completely understandable why ARIN would allocate the duty to ICANN.
Technically ICANN runs a trusted root. Even with the mess recently in
Beijing - this root works. So John the next question is - why should we
trust your root? Whats behind it. Root operation implies a great deal of
power over the user. Why should a user trust you and your root?

Because if you do take up the challenge proposed by members here i.e. to
provide a revision to policy - then please address the trust issue.

That said I can proceed to agree with Palmer that the policy is
discriminatory towards other existing root systems outside the IANA core.
There has been considerable growth in non-ICANN root service over the years
and I expect that will increase as more and more people discover that
running their own roots is the most viable way to guarantee security. I'm
sure all of you are aware of the recent hijacking of root server "I" in
Beijing. That root service is still offline as far as I'm aware.

I also strongly object that countries were not included. I don't know if we
can trust the worldroot - but I know we can trust countries to be
responsible for their critical infrastructure. The policy should be revised
to reflect this. I'm against having ICANN as the sole party responsible for
making a decision on this allocation. The same trust ARIN is showing ICANN
should be extended to national governments.

And national governments should object to this type of policy being included
in any other RIR.

Also John .. I offer you my help in drafting such a document. Your position
on the discriminatory issues is correct. But I'm sure you will agree minimum
standards and trust issues should be well addressed in opening up critical
infrastructure allocations.

Now with IPv6 - I think critical infrastructure should be assigned to any
tom dick or harry who applies. There's so much IPv6 space you can assign
critical infrastructure to everyone on the planet. Let marketing establish
who's trusted and who's not.

Thats my two cents.

regards
joe baptista

On Wed, Apr 14, 2010 at 2:27 AM, John Palmer <
jpalmer at american-webmasters.net> wrote:

> In the "ARIN Number Resource Policy Manual" is the following section on
> micro allocations
> "4.4. Micro-allocation
> ARIN will make micro-allocations to critical infrastructure providers of
> the Internet, including public exchange points, core DNS service providers
> (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs
> and IANA. These allocations will be no longer than a /24 using IPv4 or a /48
> using IPv6. Multiple allocations may be granted in certain situations. -
> Exchange point allocations MUST be allocated from specific blocks reserved
> only for this purpose. All other micro-allocations WILL be allocated out of
> other blocks reserved for micro-allocation purposes. ARIN will make a list
> of these blocks publicly available. - Exchange point operators must provide
> justification for the allocation, including: connection policy, location,
> other participants (minimum of two total), ASN, and contact information.
> ISPs and other organizations receiving these micro-allocations will be
> charged under the ISP fee schedule, while end-users will be charged under
> the fee schedule for end-users. This policy does not preclude exchange point
> operators from requesting address space under other policies."
>
> The part the concerns me is that part that says "e.g. ICANN-sanctioned
> root, gTLD and ccTLD operators".
>
> Excuse me, but since when do DNS operators have to be ICANN sanctioned? You
> know that there is such a thing called the Inclusive Namespace. ICANN is not
> the only authorized root network operator.
>
> ARIN is supposed to support the whole community, not just the DNS services
> sanctioned by ICANN.
>
> I would like to propose to the ARIN board that the phrase "(e.g.
> ICANN-sanctioned root, gTLD and ccTLD operators)" be replaced with "(root,
> gTLD and ccTLD operators)".
>
> My company manages and operates the WorldRoot, an Inclusive Namespace root
> network and would like to have 13 micro-allocations for Anycast operations
> of our 13 DNS server sets around the world as well as IP6 microallocations
> in the near future.  As it stands, we will probably be able to populate 3 to
> 4 complete cloneSets (13 servers each) in the next 3 to 5 years. The
> language in Section 4.4 of the NRPM seems to exclude our ability to obtain
> the neccesary number resources and is discriminatory to the Inclusive
> Namespace and therefore in violation of ARIN's mission to serve the ENTIRE
> North American community.
>
> ARIN Board - please take note of my request and respond.
>
> Thanks
> John Palmer - President
> American Webmasters Inc
> (operator of the WorldRoot root server network - http://worldroot.net)
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
Joe Baptista

www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive, Representative &
Accountable to the Internet community @large.
----------------------------------------------------------------
 Office: +1 (360) 526-6077 (extension 052)
    Fax: +1 (509) 479-0084

Personal: http://baptista.cynikal.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100424/8372234c/attachment.htm>

From JOHN at egh.com  Sat Apr 24 12:53:59 2010
From: JOHN at egh.com (John Santos)
Date: Sat, 24 Apr 2010 12:53:59 -0400
Subject: [arin-ppml] ARIN Policy Clarification: Micro-Allocations
In-Reply-To: <s2g874c02a21004240932ze64c7a70rc84f6cfe5fa68002@mail.gmail.com>
Message-ID: <1100424125238.601A-100000@Ives.egh.com>


"E.G." means "For Example", so the entire point of the original email
from Palmer is moot.



-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

From joelja at bogus.com  Sat Apr 24 13:54:15 2010
From: joelja at bogus.com (joel jaeggli)
Date: Sat, 24 Apr 2010 10:54:15 -0700
Subject: [arin-ppml] ARIN Policy Clarification: Micro-Allocations
Message-ID: <1100424125238.601A-100000@Ives.egh.com>

Exempli gratia...

John Santos <JOHN at egh.com> wrote:

>
>"E.G." means "For Example", so the entire point of the original email
>from Palmer is moot.
>
>
>
>-- 
>John Santos
>Evans Griffiths & Hart, Inc.
>781-861-0670 ext 539
>_______________________________________________
>PPML
>You are receiving this message because you are subscribed to
>the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>Unsubscribe or manage your mailing list subscription at:
>http://lists.arin.net/mailman/listinfo/arin-ppml
>Please contact info at arin.net if you experience any issues.

From ipv3.com at gmail.com  Sat Apr 24 14:34:02 2010
From: ipv3.com at gmail.com (IPv3.com)
Date: Sat, 24 Apr 2010 13:34:02 -0500
Subject: [arin-ppml] /6 View and /12 View of Legacy IPv4 Address Space
Message-ID: <z2h113c8ba81004241134wbded865cn821f6ab78e082fec@mail.gmail.com>

It seems clear that IPv6 has missed the mark in terms of market needs.
People with
huge investments in IPv6 will likely continue to promote it.
http://www.ietf.org/mail-archive/web/ipv6/current/msg11681.html

Near-term extensions to IPv4 can help extend the life. Contrary to
people's claims, all
routers and software in the world do not have to change to extend
IPv4. Estimates
show that 80% or more of IPv4 equipment never directly touches the
global (public?)
Internet.

Making those changes with an eye to the future may be prudent. Moving
from 32-bits
to 34-bits requires 2-bits for Source & Destination. Those are easy to
mine from idle
and deprecated bits in the 160-bit header.

http://a1.twimg.com/profile_background_images/95178872/IPv4.png
via http://Twitter.com/IPv3

With 34-bit addressing the /6 "View" and the /12 "View" of the IANA
Legacy allocation
table helps to show the current state of affairs. With the /6 view
there are only 64 Rows.
With the /12 view there are 4096 Rows.
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml

For IPv6 Hobbyists & people who want to play with 64-bit addressing
FREE 64-bit addressing using 12+18+6+24+4 can be coded using
6-bit symbols such as: LL_LLL_L_LLLL_X (Example: US_COM_L_IPV3_4)

The 12+18=30 are routed on legacy equipment. The Destination is
Flipped and 6+24=30 is routed.
This assumes /30 routing is where the legacy core reaches steady
state. Any /32 features will not
likely be tapped. That is because the +4 bits are carried un-flipped
in the right-most bits.

===================================
00 - UNIX
01 - ISOC, IETF, IRTF, IANA, ICANN, NANOG, RIRs...
10 - IEEE, ATSC, FCC, NTIA, NIST, LEOs...
11 - UN, ITU, ETSI...
===================================


From owen at delong.com  Sat Apr 24 14:55:07 2010
From: owen at delong.com (Owen DeLong)
Date: Sat, 24 Apr 2010 11:55:07 -0700
Subject: [arin-ppml] ARIN Policy Clarification: Micro-Allocations
In-Reply-To: <s2g874c02a21004240932ze64c7a70rc84f6cfe5fa68002@mail.gmail.com>
References: <AD990F00C9E042498CCFCEC16E02B53A@TAKA>
	<s2g874c02a21004240932ze64c7a70rc84f6cfe5fa68002@mail.gmail.com>
Message-ID: <718F9AA4-1D01-48C4-8800-C7E4D49BD542@delong.com>

I will leave my opinion of Mr. Palmer's proposal out for now, but, I would like to clarify that at this time, this is merely a discussion. To the best of my knowledge, Mr. Palmer has not submitted an actual proposal to modify ARIN policy. If he or anyone else would like to do so, they are welcome to.  More information on submitting a policy proposal can be found at:

https://www.arin.net/policy/pdp.html

Owen

On Apr 24, 2010, at 9:32 AM, Joe Baptista wrote:

> I'm going to take this opportunity to offer my support for this proposal. However, I would like to stress and make very clear that under no circumstances does my support for this proposal in any way constitute an endorsement or support of the root services discussed below by Mr. Palmer. In fact I do not consider Mr. Palmer's root system to qualify as viable root infrastructure.
> 
> John and I have discussed this at length on the GA. When ARIN develops policy it is critical that a certain measure of responsibility be taken to properly qualify the allocation. Critical infrastructure implies some degree of trust or approval or approval by a government body or standard be applied to justify the allocation.
> 
> It's completely understandable why ARIN would allocate the duty to ICANN. Technically ICANN runs a trusted root. Even with the mess recently in Beijing - this root works. So John the next question is - why should we trust your root? Whats behind it. Root operation implies a great deal of power over the user. Why should a user trust you and your root?
> 
> Because if you do take up the challenge proposed by members here i.e. to provide a revision to policy - then please address the trust issue.
> 
> That said I can proceed to agree with Palmer that the policy is discriminatory towards other existing root systems outside the IANA core. There has been considerable growth in non-ICANN root service over the years and I expect that will increase as more and more people discover that running their own roots is the most viable way to guarantee security. I'm sure all of you are aware of the recent hijacking of root server "I" in Beijing. That root service is still offline as far as I'm aware.
> 
> I also strongly object that countries were not included. I don't know if we can trust the worldroot - but I know we can trust countries to be responsible for their critical infrastructure. The policy should be revised to reflect this. I'm against having ICANN as the sole party responsible for making a decision on this allocation. The same trust ARIN is showing ICANN should be extended to national governments.
> 
> And national governments should object to this type of policy being included in any other RIR.
> 
> Also John .. I offer you my help in drafting such a document. Your position on the discriminatory issues is correct. But I'm sure you will agree minimum standards and trust issues should be well addressed in opening up critical infrastructure allocations.
> 
> Now with IPv6 - I think critical infrastructure should be assigned to any tom dick or harry who applies. There's so much IPv6 space you can assign critical infrastructure to everyone on the planet. Let marketing establish who's trusted and who's not.
> 
> Thats my two cents.
> 
> regards
> joe baptista 
> 
> On Wed, Apr 14, 2010 at 2:27 AM, John Palmer <jpalmer at american-webmasters.net> wrote:
> In the "ARIN Number Resource Policy Manual" is the following section on micro allocations
> "4.4. Micro-allocation
> ARIN will make micro-allocations to critical infrastructure providers of the Internet, including public exchange points, core DNS service providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs and IANA. These allocations will be no longer than a /24 using IPv4 or a /48 using IPv6. Multiple allocations may be granted in certain situations. - Exchange point allocations MUST be allocated from specific blocks reserved only for this purpose. All other micro-allocations WILL be allocated out of other blocks reserved for micro-allocation purposes. ARIN will make a list of these blocks publicly available. - Exchange point operators must provide justification for the allocation, including: connection policy, location, other participants (minimum of two total), ASN, and contact information. ISPs and other organizations receiving these micro-allocations will be charged under the ISP fee schedule, while end-users will be charged under the fee schedule for end-users. This policy does not preclude exchange point operators from requesting address space under other policies."
> 
> The part the concerns me is that part that says "e.g. ICANN-sanctioned root, gTLD and ccTLD operators".
> 
> Excuse me, but since when do DNS operators have to be ICANN sanctioned? You know that there is such a thing called the Inclusive Namespace. ICANN is not the only authorized root network operator.
> 
> ARIN is supposed to support the whole community, not just the DNS services sanctioned by ICANN.
> 
> I would like to propose to the ARIN board that the phrase "(e.g. ICANN-sanctioned root, gTLD and ccTLD operators)" be replaced with "(root, gTLD and ccTLD operators)".
> 
> My company manages and operates the WorldRoot, an Inclusive Namespace root network and would like to have 13 micro-allocations for Anycast operations of our 13 DNS server sets around the world as well as IP6 microallocations in the near future.  As it stands, we will probably be able to populate 3 to 4 complete cloneSets (13 servers each) in the next 3 to 5 years. The language in Section 4.4 of the NRPM seems to exclude our ability to obtain the neccesary number resources and is discriminatory to the Inclusive Namespace and therefore in violation of ARIN's mission to serve the ENTIRE North American community.
> 
> ARIN Board - please take note of my request and respond.
> 
> Thanks
> John Palmer - President
> American Webmasters Inc
> (operator of the WorldRoot root server network - http://worldroot.net)
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> 
> 
> -- 
> Joe Baptista
> 
> www.publicroot.org
> PublicRoot Consortium
> ----------------------------------------------------------------
> The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large.
> ----------------------------------------------------------------
>  Office: +1 (360) 526-6077 (extension 052)
>     Fax: +1 (509) 479-0084
> 
> Personal: http://baptista.cynikal.net/
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100424/db71ef16/attachment.htm>

From jmaimon at chl.com  Sun Apr 25 10:40:36 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Sun, 25 Apr 2010 10:40:36 -0400
Subject: [arin-ppml] Policy Proposal 110: Preservation of minimal IPv4
 Resources for New and Small Organizations and for IPv6 Transition
In-Reply-To: <E59EDC2B-BB76-4ABD-85A5-C42C539DC179@delong.com>
References: <4BD0998F.60900@arin.net> <4BD216F1.6070009@chl.com>
	<E59EDC2B-BB76-4ABD-85A5-C42C539DC179@delong.com>
Message-ID: <4BD45464.700@chl.com>



Owen DeLong wrote:
> On Apr 23, 2010, at 2:53 PM, Joe Maimon wrote:
>> Michael, George,
>>
>> 4.10 does not provide space to be used for addressing your customers 
>> if the reality happens to be that you cannot get or keep any 
>> customers without giving them some IPv4 addresses.
> Thanks for that clarification Joe.
>
> Nor was it intended to.  I now oppose this proposal.
>
> If we're going to give IPv4 out to people just to give it to their 
> customers, it should be given based on current allocation/assignment 
> rules.  The purpose of reserving the /10 was so that ANYONE who was 
> implementing
> new transitional services (such as new NAT-PT infrastructure, etc.) 
> would be able to get small pieces of
> IPv4 to make deployment of those transitional technologies possible.
This is preserved, but halved into two /12's with slightly different 
requirements and purposes.

> It _IS_ not intended to extend the
> useful life of IPv4 for anyone.
No matter what is done with the last /8, it wont be a significant 
contributor towards extension of the useful life of IPv4. IPv4 as a 
continuing real world requirement will live or die on its own schedule 
regardless of what is done to the last /8. The fact of the matter is 
that there is enough inefficiently used IPv4 already out there (anywhere 
from 25% - 75% depending on how you look at it) that with sufficiently 
bad conditions, contortions and extortions, it can continue to be used 
and reused for much longer than most of us would want.

Allowing the /8 drain into the same inefficiencies as all the prior /8's 
gains nothing.

The best case scenario is that mass IPv6 adoptions occur quickly and 
seamlessly. While we have seen upticks and many successful technical 
proof of concepts, it has not happened yet. If the chances of it 
happening by depletion are so fragile that proposals such as this one 
threaten it, things are already slated to go badly.

For the not best case scenario, if practical reality dictates that IPv4 
continues to be required to turn up new customers and services, those 
who have been around for a while, who have consumed the bulk of the ~40 
arin /8 and ~70 legacy /8, will have options. New and small orgs will 
not have the quite the same.
>
> In my opinion, this space absolutely should not be used to simply add 
> more IPv4 customers to any provider.

What do you think will happen to the other three /10 in the /8 absent 
this proposal?

>>
>> The possibility exists that it may still be impractical to build a 
>> small business or start a new one with ipv6 even when no ipv4 is 
>> available except from preexisting holders who may be viewed 
>> unfavorably as monopolistic cartels and may even behave in such a manner.
>>
> If that is the case, it will be a bad time to start an ISP. There are 
> lots of factors that can make it a bad time to start an ISP. We've 
> been through that before and we'll go through that again.
>
In this instance it might be demonstrable that the community contributed 
to those factors and failed to attempt to mitigate them. That carries 
its own set of risks.

>> I believe failing to prepare adequately for that scenario is not only 
>> irresponsible but that it can be widely viewed and seized upon as 
>> evidence that we have acted irresponsibly.
>>
> I believe that locking up usable addresses for theoretical businesses 
> that may not ever exist at a time when actual running businesses have 
> a demonstrated need is a bigger example of acting irresponsibly.

The grasshopper and the ant. Years of plenty, years of famine.

(strangely enough both apply at the same time with ipv6 and ipv4 and to 
the same entities)

I consider socking away addresses during time of plenty in the face of 
potential oncoming famine, when the alternative is their near immediate 
consumption at the same rate as the last 95% the bare minimum of 
responsibility.

In fact, I would support the entire /8  held in reserve for specific 
purposes to be dictated by policy.

IPv6 will either be where the action is at or not. Three months of 
/8 at CBR wont make or break.

If it has mass adoption, than nobody should miss it. If it does not has 
mass adoption, we may greatly miss squandering that last rir /8.

>> I do not consider the existence of transfers, waiting lists and the 
>> current 4.10 to go far enough as to be adequate.
>>
>> The existence of minimal resources could do much to temper negative 
>> tendencies inherent in markets for limited resources.
>>
> As I now understand the intent of your policy, it would not accomplish 
> what you intend.  It would, instead, either create a situation where 
> various existing organizations found ways to get in under the policy 
> and get the space, or, it would get ARIN sued for squatting on address 
> space that should be otherwise issued to organizations with 
> demonstrated need.
>
> Also, what you call "negative tendencies of a market", I am starting 
> to call "incentive to move to IPv6."
I believe the proposal adequately prevents abuse - ARIN staff may even 
object to the extra work it imposes on them to prevent abuse.

If conditions are such that only the small and new orgs are punished by 
market conditions, it can actually create an incentive for the 
established larger players to drag their feet towards enabling everyone 
to be on equal footing again with ipv6 as the predominant opportunity 
model. On the other hand, if  the new and small can turn up handfuls 
each of customers demanding/requiring ipv4, its quite the incentive for 
all the rest to convert customer ipv4 needs into ipv6. And they have the 
clout to do it.

Everyone wins.

If ARIN is going to get sued, this proposal is not likely to add to the 
set of risks, even as it may alter them, trading one for the other. 
Legal counsel would probably interject their opinion on that at some point.

>> If IPv6 is not completely satisfactory in the common case for new or 
>> small growing entities that would be our failure.
>>
> I disagree.

Whose then?

>> It certainly would not be their fault. They werent even around.
>>
> Then it is a risk they should consider prior to launching a business 
> that is dependent on IPv4.

If IPv4 is what customers continue to want or require than you arent 
going to be very successful launching IPv6 businesses either.

Attitudes that are variations of "Tough, sucks to be you" are not going 
to go far towards helping to win friends and influence people.

>
>> The goals of (the existing) 4.10 are specifically aimed towards those 
>> who have acute need of IPv4 even when there is none normally 
>> available from Arin. That is what this entire proposal is about, 
>> clarifying some needs and adding others.
>>
> The goals of 4.10 are, actually, not that.
>
> The goals of 4.10 were to ensure we didn't create a "can't get there 
> from here" problem where all IPv4 addresses were consumed for business 
> as usual and the sudden need to deploy something like NAT-PT to 
> provide for IPv4 services access by IPv6 clients would not be rendered 
> impossible to deploy for want of IPv4 addresses with which to deploy it.

That is an acute need. It is also one unlikely to be actually 
experienced by the organizations who have consumed the bulk of the 
resources in the time of plenty - do you really think they cant scare up 
a /24 from their existing holdings, let alone a /28?

Ergo, 4.10 is actually targeted towards those who wont have that ability.

> We actually started out trying to set aside the full /8. We tried 
> compromising to the /9. The community was actually pretty clear in 
> their desire to limit this reservation to a /10.
I think that is short sighted, considering:
>> That changes ARIN exhaustion dates by about a month, give or take a 
>> week, at current burn rates.
>>
> Yeah, that sounds like an accurate estimate.  Sorry I missed that in 
> my first read-through.
>
> Owen
>

Joe


From ipv3.com at gmail.com  Sun Apr 25 11:22:35 2010
From: ipv3.com at gmail.com (IPv3.com)
Date: Sun, 25 Apr 2010 10:22:35 -0500
Subject: [arin-ppml] Is ARIN (The Business) Too Opaque for the Public to
	Participate ?
Message-ID: <t2o113c8ba81004250822p11f1044cq2d7382c79aecb744@mail.gmail.com>

Is ARIN (The Business) Too Opaque for the Public to Participate ?

1. ARIN.NET started as a "steward" of some /8s for small IPv4 ISPs.

2. Large Carriers (ISPs) do not use ARIN or RIR services.?
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml

3. Some ARIN /8 Assets are claimed to be owned and some inherited ?
http://mailman.nanog.org/pipermail/nanog/2010-April/021142.html

4. ARIN.COM was secretly purchased when 4-Letter .COM domains became
useful for FREE unique Address Space pre-Fixing. LL:LLL:L:LLLL:X ?

5. ARIN is now in Las Vegas on your nickel? If this was the DMV would
they travel around on the public's nickel?

6. ARIN Directors and Executives resign or decide not to work there
and no explanation is provided.?

7. ARIN appears to be focused on the IPv6 market with swag, wikis, etc.?

8. ARIN Executives have recently entered the IPv6 Software business?
as a supplier for a major cable company?

9. ARIN claims to provide "unique-ness" service but WHOIS appears to
be the prime focus.
[Aside: there are many much lower cost ways to ensure uniqueness,
especially as address spaces expand from 32 to 480 bits.]

10 People assume ARIN is part of ICANN and that web-site shows a
Subsidiary Business Relationship. Some claim there are no ICANN?ARIN
"Contracts". http://bit.ly/8Ylh1e

Is ARIN (The Business) Too Opaque for the Public to Participate ?


From owen at delong.com  Sun Apr 25 11:46:12 2010
From: owen at delong.com (Owen DeLong)
Date: Sun, 25 Apr 2010 08:46:12 -0700
Subject: [arin-ppml] Policy Proposal 110: Preservation of minimal IPv4
	Resources for New and Small Organizations and for IPv6 Transition
In-Reply-To: <4BD45464.700@chl.com>
References: <4BD0998F.60900@arin.net> <4BD216F1.6070009@chl.com>
	<E59EDC2B-BB76-4ABD-85A5-C42C539DC179@delong.com>
	<4BD45464.700@chl.com>
Message-ID: <3066AC55-025F-454A-ABBC-8B771A653891@delong.com>


On Apr 25, 2010, at 7:40 AM, Joe Maimon wrote:

> 
> 
> Owen DeLong wrote:
>> On Apr 23, 2010, at 2:53 PM, Joe Maimon wrote:
>>> Michael, George,
>>> 
>>> 4.10 does not provide space to be used for addressing your customers if the reality happens to be that you cannot get or keep any customers without giving them some IPv4 addresses.
>> Thanks for that clarification Joe.
>> 
>> Nor was it intended to.  I now oppose this proposal.
>> 
>> If we're going to give IPv4 out to people just to give it to their customers, it should be given based on current allocation/assignment rules.  The purpose of reserving the /10 was so that ANYONE who was implementing
>> new transitional services (such as new NAT-PT infrastructure, etc.) would be able to get small pieces of
>> IPv4 to make deployment of those transitional technologies possible.
> This is preserved, but halved into two /12's with slightly different requirements and purposes.
> 
Yeah, I understand that.  My point is that it should not be reduced to a /11. I wanted to reserve the entire /8. The community found compromise and consensus around /10. IMHO we should be considering expanding this reservation, not reducing it or carving it up into multiple purposes.

I agree that the requirements need to be improved upon for this block. However, this policy contains so many other changes which I believe are not beneficial that I cannot support it as written.

>> It _IS_ not intended to extend the
>> useful life of IPv4 for anyone.
> No matter what is done with the last /8, it wont be a significant contributor towards extension of the useful life of IPv4. IPv4 as a continuing real world requirement will live or die on its own schedule regardless of what is done to the last /8. The fact of the matter is that there is enough inefficiently used IPv4 already out there (anywhere from 25% - 75% depending on how you look at it) that with sufficiently bad conditions, contortions and extortions, it can continue to be used and reused for much longer than most of us would want.
> 
True.

> Allowing the /8 drain into the same inefficiencies as all the prior /8's gains nothing.
> 
Which is why we reserved the /10.

> The best case scenario is that mass IPv6 adoptions occur quickly and seamlessly. While we have seen upticks and many successful technical proof of concepts, it has not happened yet. If the chances of it happening by depletion are so fragile that proposals such as this one threaten it, things are already slated to go badly.
> 
I don't think this proposal will make much difference to IPv6 adoption. I do think that as you have stated, there's little to no benefit to this proposal.

> For the not best case scenario, if practical reality dictates that IPv4 continues to be required to turn up new customers and services, those who have been around for a while, who have consumed the bulk of the ~40 arin /8 and ~70 legacy /8, will have options. New and small orgs will not have the quite the same.

IPv4 won't be available regardless of this policy.  Your previous paragraph states this. I do not believe it is appropriate for ARIN to discriminate against one class of organizations in favor of another. Frankly, large and extra large subscribers are going to be the first ones denied anyway. Smaller blocks will be available longer and run out slower than larger blocks just by the nature of the allocation process. One could argue that this fact already gives an advantage to small organizations.

>> 
>> In my opinion, this space absolutely should not be used to simply add more IPv4 customers to any provider.
> 
> What do you think will happen to the other three /10 in the /8 absent this proposal?
> 
It will, unfortunately, be used to add more IPv4 customers to the providers that get pieces of this space.

However, it will be distributed on the same fair basis as all previous IPv4 blocks. The community was offered the opportunity to reserve the entire /8 and rejected it.

>>> 
>>> The possibility exists that it may still be impractical to build a small business or start a new one with ipv6 even when no ipv4 is available except from preexisting holders who may be viewed unfavorably as monopolistic cartels and may even behave in such a manner.
>>> 
>> If that is the case, it will be a bad time to start an ISP. There are lots of factors that can make it a bad time to start an ISP. We've been through that before and we'll go through that again.
>> 
> In this instance it might be demonstrable that the community contributed to those factors and failed to attempt to mitigate them. That carries its own set of risks.
> 
I'm less concerned about those risks than the risks I see in passing this policy. Unfortunately I think it would be ill advised for me to enumerate those risks on a public list, lest they become a self-fulfilling prophecy.

>>> I believe failing to prepare adequately for that scenario is not only irresponsible but that it can be widely viewed and seized upon as evidence that we have acted irresponsibly.
>>> 
>> I believe that locking up usable addresses for theoretical businesses that may not ever exist at a time when actual running businesses have a demonstrated need is a bigger example of acting irresponsibly.
> 
> The grasshopper and the ant. Years of plenty, years of famine.
> 
> (strangely enough both apply at the same time with ipv6 and ipv4 and to the same entities)
> 
Yep.

> I consider socking away addresses during time of plenty in the face of potential oncoming famine, when the alternative is their near immediate consumption at the same rate as the last 95% the bare minimum of responsibility.
> 
Then you should study survival texts. Turns out that if you are stuck in a wilderness situation with minimal food, you do not actually prolong your life by self-rationing. Your chances of survival actually increase if you continue to eat normally until the food is gone.

> In fact, I would support the entire /8  held in reserve for specific purposes to be dictated by policy.
> 
The time to do that was 2 years ago when we were debating that issue.

> IPv6 will either be where the action is at or not. Three months of /8 at CBR wont make or break.
> 
True, but, that didn't gain community consensus.

> If it has mass adoption, than nobody should miss it. If it does not has mass adoption, we may greatly miss squandering that last rir /8.
> 
I think we're too late. No matter what we do it's going to be a bumpy ride. It will be bumpier for some than others.

>>> I do not consider the existence of transfers, waiting lists and the current 4.10 to go far enough as to be adequate.
>>> 
>>> The existence of minimal resources could do much to temper negative tendencies inherent in markets for limited resources.
>>> 
>> As I now understand the intent of your policy, it would not accomplish what you intend.  It would, instead, either create a situation where various existing organizations found ways to get in under the policy and get the space, or, it would get ARIN sued for squatting on address space that should be otherwise issued to organizations with demonstrated need.
>> 
>> Also, what you call "negative tendencies of a market", I am starting to call "incentive to move to IPv6."
> I believe the proposal adequately prevents abuse - ARIN staff may even object to the extra work it imposes on them to prevent abuse.
> 
How did abuse come into your interpretation of my statement? I'm not talking about abuse, I'm talking about creative solutions to policy compliance.

One example:
	LargeOrg A decides they need some of this address space.
	They hire contractor B to create Entity C -- A new startup.
	Entity C is funded and purchases enough infrastructure to justify an allocation or assignment under this policy.
	Entity C gets their address space.
	Entity C is then purchased by LargeOrg A who invokes section 8.2 of the NRPM and voila. Instant resources.

That's not abuse, that's a legitimate startup being purchased legitimately by a larger organization.

Now, consider how much easier this could become under 8.3.

> If conditions are such that only the small and new orgs are punished by market conditions, it can actually create an incentive for the established larger players to drag their feet towards enabling everyone to be on equal footing again with ipv6 as the predominant opportunity model. On the other hand, if  the new and small can turn up handfuls each of customers demanding/requiring ipv4, its quite the incentive for all the rest to convert customer ipv4 needs into ipv6. And they have the clout to do it.
> 
I don't think that will be the case.  In fact, the large existing orgs will be the first ones to suffer and will, actually, probably have the greatest suffering.

I don't thin the incentives will work the way you think they do. If they did, you wouldn't have public IPv6 commitments already expressed by the largest eye-ball and content providers.

> Everyone wins.
> 
I don't think so.

> If ARIN is going to get sued, this proposal is not likely to add to the set of risks, even as it may alter them, trading one for the other. Legal counsel would probably interject their opinion on that at some point.
> 
If this proposal becomes a draft policy, it will get a staff and legal review.

>>> If IPv6 is not completely satisfactory in the common case for new or small growing entities that would be our failure.
>>> 
>> I disagree.
> 
> Whose then?
> 
The list is long and irrelevant. Point is that ARIN does not design protocols or build routers. We have little or nothing to do with the level of satisfaction that can be gained from use of IPv6 vs. IPv4. There is little we can do to make it more satisfactory.

>>> It certainly would not be their fault. They werent even around.
>>> 
>> Then it is a risk they should consider prior to launching a business that is dependent on IPv4.
> 
> If IPv4 is what customers continue to want or require than you arent going to be very successful launching IPv6 businesses either.
> 
Yes, this might be one of those time periods where it's a bad idea to launch an internet business.
If you think this is news, you haven't been paying attention.

> Attitudes that are variations of "Tough, sucks to be you" are not going to go far towards helping to win friends and influence people.
> 
I'm just saying ARIN shouldn't be making it tougher on one class of organization than another, which is all this proposal really does.  It's like believing that QoS makes your network better.  QoS does nothing of the sort. It just helps you decide which customers to screw when your network becomes inadequate.

>> 
>>> The goals of (the existing) 4.10 are specifically aimed towards those who have acute need of IPv4 even when there is none normally available from Arin. That is what this entire proposal is about, clarifying some needs and adding others.
>>> 
>> The goals of 4.10 are, actually, not that.
>> 
>> The goals of 4.10 were to ensure we didn't create a "can't get there from here" problem where all IPv4 addresses were consumed for business as usual and the sudden need to deploy something like NAT-PT to provide for IPv4 services access by IPv6 clients would not be rendered impossible to deploy for want of IPv4 addresses with which to deploy it.
> 
> That is an acute need. It is also one unlikely to be actually experienced by the organizations who have consumed the bulk of the resources in the time of plenty - do you really think they cant scare up a /24 from their existing holdings, let alone a /28?
> 
Yes, I think that will happen in some cases.

> Ergo, 4.10 is actually targeted towards those who wont have that ability.
> 
Regardless of their size or history, yes.

>> We actually started out trying to set aside the full /8. We tried compromising to the /9. The community was actually pretty clear in their desire to limit this reservation to a /10.
> I think that is short sighted, considering:
>>> That changes ARIN exhaustion dates by about a month, give or take a week, at current burn rates.
>>> 
>> Yeah, that sounds like an accurate estimate.  Sorry I missed that in my first read-through.

Short sighted or not, it was the pretty clear consensus of the community.

Owen




From bill at herrin.us  Sun Apr 25 21:00:20 2010
From: bill at herrin.us (William Herrin)
Date: Sun, 25 Apr 2010 15:00:20 -1000
Subject: [arin-ppml] Policy Proposal 110: Preservation of minimal IPv4
	Resources for New and Small Organizations and for IPv6 Transition
In-Reply-To: <4BD0998F.60900@arin.net>
References: <4BD0998F.60900@arin.net>
Message-ID: <x2p3c3e3fca1004251800rb940f702xf64de06c54386daf@mail.gmail.com>

On Thu, Apr 22, 2010 at 8:46 AM, Member Services <info at arin.net> wrote:
> Policy Proposal: Preservation of minimal IPv4 Resources for New and
> Small Organizations and for IPv6 Transition


I encourage folks consider this proposal in light of the following scenarios:

1. What happens if IPv4 addresses become readily available via an
address transfer market? How will ARIN fairly make a choice between
those who have to buy their addresses on the market and those who can
get them "for free?" How will this impact the perception of
fairness/unfairness that the general public holds with respect to
ARIN's dealings?

2. What happens if an IPv4 addresses address transfer market fails to
develop? Could the existence of this policy impede the development of
an address recovery policy for underutilized address space? During
such a process, what will the impact be on the perception of
fairness/unfairness that the general public holds with respect to
ARIN's dealings?


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 christopher.morrow at gmail.com  Sun Apr 25 21:50:30 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Sun, 25 Apr 2010 21:50:30 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <z2u3c3e3fca1004171519i46dfc6b7y8ad32ee894ea71d4@mail.gmail.com>
References: <20100413172714.M35473@fast-serv.com>
	<75822E125BCB994F8446858C4B19F0D701D5FCA516@SUEX07-MBX-04.ad.syr.edu>
	<4BC63FB7.5000404@umn.edu>
	<75822E125BCB994F8446858C4B19F0D701D5FCA522@SUEX07-MBX-04.ad.syr.edu>
	<4BC74C57.9010602@ipinc.net>
	<75822E125BCB994F8446858C4B19F0D701D5E0A146@SUEX07-MBX-04.ad.syr.edu>
	<z2s3c3e3fca1004161035yfa9de1e8oe5ee17c247860627@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D701D5FCA538@SUEX07-MBX-04.ad.syr.edu>
	<m2q3c3e3fca1004171506p351f7914p97cba840853d2343@mail.gmail.com>
	<z2u3c3e3fca1004171519i46dfc6b7y8ad32ee894ea71d4@mail.gmail.com>
Message-ID: <j2q75cb24521004251850hc4e7cbdcx6ef2a587046d71b3@mail.gmail.com>

On Sat, Apr 17, 2010 at 6:19 PM, William Herrin <bill at herrin.us> wrote:
> On Sat, Apr 17, 2010 at 6:06 PM, William Herrin <bill at herrin.us> wrote:
>> Only the generality was
>> important to Ted's reminder that when providing ARIN allocations to
>> ISPs that find $2250/year challenging, "you consume the same amount of

Is 2250/year really that much of an expense that a business hangs in
the balance? I read 2250/yr as ... 2 laptops/yr. So, essentially 2 new
employees each year get no compute resources. Is that reasonable?

For an individual, sure 2250/yr is a larger expense (not
insurmountable - less than 200/month) but for a business it really
can't be that onerous.

-chris


From tdurack at gmail.com  Sun Apr 25 22:12:39 2010
From: tdurack at gmail.com (Tim Durack)
Date: Sun, 25 Apr 2010 22:12:39 -0400
Subject: [arin-ppml] ARIN XXV transcript archive?
Message-ID: <z2z9e246b4d1004251912w94bf04f2j9e0f687b43018cc3@mail.gmail.com>

Are there any archived transcripts of ARIN XXV?

-- 
Tim:>


From bill at telnetcommunications.com  Sun Apr 25 22:27:17 2010
From: bill at telnetcommunications.com (Bill Sandiford)
Date: Sun, 25 Apr 2010 22:27:17 -0400
Subject: [arin-ppml] ARIN XXV transcript archive?
In-Reply-To: <z2z9e246b4d1004251912w94bf04f2j9e0f687b43018cc3@mail.gmail.com>
References: <z2z9e246b4d1004251912w94bf04f2j9e0f687b43018cc3@mail.gmail.com>
Message-ID: <FE7D4327AABC0448A6281C0AC4445C7C82CF89345D@Exchange2007.HostedMail.local>

Hi Tim:

ARIN member services sent a thank-you email out to participants last week.  It contained the following info which may help you out.

"Thank you for being part of the ARIN XXV Public Policy and Members Meeting. Look for the meeting report, including transcript, presentations, and webcast to be published by 4 May 2010 on the ARIN website at: 

https://www.arin.net/participate/meetings/reports/ARIN_XXV/index.html."

Regards,
Bill


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Tim Durack
> Sent: Sunday, April 25, 2010 10:13 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] ARIN XXV transcript archive?
> 
> Are there any archived transcripts of ARIN XXV?
> 
> --
> Tim:>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From bill at herrin.us  Mon Apr 26 01:40:35 2010
From: bill at herrin.us (William Herrin)
Date: Sun, 25 Apr 2010 19:40:35 -1000
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <j2q75cb24521004251850hc4e7cbdcx6ef2a587046d71b3@mail.gmail.com>
References: <20100413172714.M35473@fast-serv.com> <4BC63FB7.5000404@umn.edu> 
	<75822E125BCB994F8446858C4B19F0D701D5FCA522@SUEX07-MBX-04.ad.syr.edu>
	<4BC74C57.9010602@ipinc.net>
	<75822E125BCB994F8446858C4B19F0D701D5E0A146@SUEX07-MBX-04.ad.syr.edu>
	<z2s3c3e3fca1004161035yfa9de1e8oe5ee17c247860627@mail.gmail.com> 
	<75822E125BCB994F8446858C4B19F0D701D5FCA538@SUEX07-MBX-04.ad.syr.edu> 
	<m2q3c3e3fca1004171506p351f7914p97cba840853d2343@mail.gmail.com> 
	<z2u3c3e3fca1004171519i46dfc6b7y8ad32ee894ea71d4@mail.gmail.com> 
	<j2q75cb24521004251850hc4e7cbdcx6ef2a587046d71b3@mail.gmail.com>
Message-ID: <r2z3c3e3fca1004252240s23a61ed1t2a23163dafc8706b@mail.gmail.com>

On Sun, Apr 25, 2010 at 3:50 PM, Christopher Morrow
<christopher.morrow at gmail.com> wrote:
> On Sat, Apr 17, 2010 at 6:19 PM, William Herrin <bill at herrin.us> wrote:
>> On Sat, Apr 17, 2010 at 6:06 PM, William Herrin <bill at herrin.us> wrote:
>>> Only the generality was
>>> important to Ted's reminder that when providing ARIN allocations to
>>> ISPs that find $2250/year challenging, "you consume the same amount of
>
> Is 2250/year really that much of an expense that a business hangs in
> the balance?

It's IPv6 and it's the year 2010. The business doesn't hang in the
balance. Maybe next year. Maybe the year after. Maybe.

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 christopher.morrow at gmail.com  Mon Apr 26 01:44:33 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Mon, 26 Apr 2010 01:44:33 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <r2z3c3e3fca1004252240s23a61ed1t2a23163dafc8706b@mail.gmail.com>
References: <20100413172714.M35473@fast-serv.com>
	<75822E125BCB994F8446858C4B19F0D701D5FCA522@SUEX07-MBX-04.ad.syr.edu>
	<4BC74C57.9010602@ipinc.net>
	<75822E125BCB994F8446858C4B19F0D701D5E0A146@SUEX07-MBX-04.ad.syr.edu>
	<z2s3c3e3fca1004161035yfa9de1e8oe5ee17c247860627@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D701D5FCA538@SUEX07-MBX-04.ad.syr.edu>
	<m2q3c3e3fca1004171506p351f7914p97cba840853d2343@mail.gmail.com>
	<z2u3c3e3fca1004171519i46dfc6b7y8ad32ee894ea71d4@mail.gmail.com>
	<j2q75cb24521004251850hc4e7cbdcx6ef2a587046d71b3@mail.gmail.com>
	<r2z3c3e3fca1004252240s23a61ed1t2a23163dafc8706b@mail.gmail.com>
Message-ID: <j2u75cb24521004252244kc38a3ad9oc5f0e068cd4f93a4@mail.gmail.com>

On Mon, Apr 26, 2010 at 1:40 AM, William Herrin <bill at herrin.us> wrote:
> On Sun, Apr 25, 2010 at 3:50 PM, Christopher Morrow
> <christopher.morrow at gmail.com> wrote:
>> On Sat, Apr 17, 2010 at 6:19 PM, William Herrin <bill at herrin.us> wrote:
>>> On Sat, Apr 17, 2010 at 6:06 PM, William Herrin <bill at herrin.us> wrote:
>>>> Only the generality was
>>>> important to Ted's reminder that when providing ARIN allocations to
>>>> ISPs that find $2250/year challenging, "you consume the same amount of
>>
>> Is 2250/year really that much of an expense that a business hangs in
>> the balance?
>
> It's IPv6 and it's the year 2010. The business doesn't hang in the
> balance. Maybe next year. Maybe the year after. Maybe.

meaning that today the cost isn't an issue, but because of business
pressures 2250 could be a problem in the future?  Or, did you mean
that in the future the RIR may decide to charge 10x/20x/100x for the
same allocation?

-Chris


From ggiesen at akn.ca  Mon Apr 26 01:55:01 2010
From: ggiesen at akn.ca (Gary Giesen)
Date: Mon, 26 Apr 2010 01:55:01 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <j2u75cb24521004252244kc38a3ad9oc5f0e068cd4f93a4@mail.gmail.com>
Message-ID: <C7FAA2F5.9636%ggiesen@akn.ca>

I think what he's trying to say is that cost is an issue *because* the
business doesn't hang in the balance, and therefore the current pricing is
an impediment to adoption. I don't really agree, because for all but the
tiniest ISPs, $2250 is a tiny amount of their operating budget, and the cost
of a couple decent CPE routers.

GG

On 10-04-26 1:44 AM, "Christopher Morrow" <christopher.morrow at gmail.com>
wrote:

> On Mon, Apr 26, 2010 at 1:40 AM, William Herrin <bill at herrin.us> wrote:
>> On Sun, Apr 25, 2010 at 3:50 PM, Christopher Morrow
>> <christopher.morrow at gmail.com> wrote:
>>> On Sat, Apr 17, 2010 at 6:19 PM, William Herrin <bill at herrin.us> wrote:
>>>> On Sat, Apr 17, 2010 at 6:06 PM, William Herrin <bill at herrin.us> wrote:
>>>>> Only the generality was
>>>>> important to Ted's reminder that when providing ARIN allocations to
>>>>> ISPs that find $2250/year challenging, "you consume the same amount of
>>> 
>>> Is 2250/year really that much of an expense that a business hangs in
>>> the balance?
>> 
>> It's IPv6 and it's the year 2010. The business doesn't hang in the
>> balance. Maybe next year. Maybe the year after. Maybe.
> 
> meaning that today the cost isn't an issue, but because of business
> pressures 2250 could be a problem in the future?  Or, did you mean
> that in the future the RIR may decide to charge 10x/20x/100x for the
> same allocation?
> 
> -Chris
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From bill at herrin.us  Mon Apr 26 02:13:37 2010
From: bill at herrin.us (William Herrin)
Date: Sun, 25 Apr 2010 20:13:37 -1000
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <C7FAA2F5.9636%ggiesen@akn.ca>
References: <j2u75cb24521004252244kc38a3ad9oc5f0e068cd4f93a4@mail.gmail.com> 
	<C7FAA2F5.9636%ggiesen@akn.ca>
Message-ID: <x2y3c3e3fca1004252313v340a4d50j97a5a115119a5b95@mail.gmail.com>

On Sun, Apr 25, 2010 at 7:55 PM, Gary Giesen <ggiesen at akn.ca> wrote:
> I think what he's trying to say is that cost is an issue *because* the
> business doesn't hang in the balance, and therefore the current pricing is
> an impediment to adoption. I don't really agree, because for all but the
> tiniest ISPs, $2250 is a tiny amount of their operating budget, and the cost
> of a couple decent CPE routers.

It's a line item in the overhead budget. The budget requested is
larger than the budget approved. First I cut the things that can wait
until next year. Then I cut the things that can wait until a salesman
tells me that customers have complained. If I'm lucky and the business
has had a good year, the cuts stop there.

CPE routers aren't in the overhead budget. They directly match a
specific paying account. Easy to buy things required by a specific
customer coughing up enough money to cover their cost. Tough to buy
overhead.

-Bill



-- 
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 ggiesen at akn.ca  Mon Apr 26 02:24:29 2010
From: ggiesen at akn.ca (Gary Giesen)
Date: Mon, 26 Apr 2010 02:24:29 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <x2y3c3e3fca1004252313v340a4d50j97a5a115119a5b95@mail.gmail.com>
Message-ID: <C7FAA9DD.963C%ggiesen@akn.ca>

An IPv6 /32 also doesn't cost anything if you have a /20 or larger v4
allocation. If you have an X-Small (smaller than /20), it's only an extra
$1250/year. Pretty small potatoes. By the time you *need* IPv6, it will just
be the cost of doing business, and will be pretty easy to justify it (pretty
hard to be an ISP without it).

GG


On 10-04-26 2:13 AM, "William Herrin" <bill at herrin.us> wrote:

> On Sun, Apr 25, 2010 at 7:55 PM, Gary Giesen <ggiesen at akn.ca> wrote:
>> I think what he's trying to say is that cost is an issue *because* the
>> business doesn't hang in the balance, and therefore the current pricing is
>> an impediment to adoption. I don't really agree, because for all but the
>> tiniest ISPs, $2250 is a tiny amount of their operating budget, and the cost
>> of a couple decent CPE routers.
> 
> It's a line item in the overhead budget. The budget requested is
> larger than the budget approved. First I cut the things that can wait
> until next year. Then I cut the things that can wait until a salesman
> tells me that customers have complained. If I'm lucky and the business
> has had a good year, the cuts stop there.
> 
> CPE routers aren't in the overhead budget. They directly match a
> specific paying account. Easy to buy things required by a specific
> customer coughing up enough money to cover their cost. Tough to buy
> overhead.
> 
> -Bill
> 
> 



From ipv3.com at gmail.com  Mon Apr 26 05:09:52 2010
From: ipv3.com at gmail.com (IPv3.com)
Date: Mon, 26 Apr 2010 04:09:52 -0500
Subject: [arin-ppml] IPv6 is Becoming a Complex Multi-Dimensional Deployment
	Space of Islands
Message-ID: <p2o113c8ba81004260209ne25aa8ffjf22b431a16546315@mail.gmail.com>

IPv6 is Becoming a Complex Multi-Dimensional Deployment Space of Islands

1. IPv6 is very complex & continues to evolve. Vendors now have their
"Flavors". That creates one axis of choice from IPv6 Lite to IPv6
"Everything Bagel".

2. Another axis is Address Plans. With 128-bits of Addressing there
dozens of ways to (logical) divide the bits and more choices emerge
each year.

3. A third axis of choice is Native vs. IPv4-assisted (6to4) vs.other
schemes tied to custom Address Plans (#2).

4. A fourth axis of choice is how it is "triggered" via the DNS. Can
legacy A Records be used with Class ? Are AAAA Records Native (Left
Adjusted) ?
Are special triggers hidden in the AAAA Records, such as 2002 ? Will
people go back to A6 Records designed for IPv6 ?

5. A fifth axis of choice is how the DNS servers are deployed. Is IPv4
used to obtain IPv6 records ? Are IPv6-only servers used for Native
IPv6 (#3) ?

6. Yet another axis is where one obtains IPv6 address space. Will it
be 64-bit FREE ? Does it come from upstream ? Is it mapped from IPv4 ?
Is it Native from RIRs?

Given all of the above, ISPs and consumers are expected to select one
from each of the 6 areas above & deploy something that talks to more
than
the island of users selecting that same set ? It appears there could
be several thousand combinations of the above.

Unlike IPv4 which more or less had one deployment scenario with
reducing options as time went on, IPv6 is at the dawn of a big bang
in deployment expansion. Soon, the term IPv6 may cease to have any meaning.

IPv6 is Becoming a Complex Multi-Dimensional Deployment Space of Islands


From jmaimon at chl.com  Mon Apr 26 08:30:28 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Mon, 26 Apr 2010 08:30:28 -0400
Subject: [arin-ppml] IPv6 is Becoming a Complex Multi-Dimensional
 Deployment Space of Islands
In-Reply-To: <p2o113c8ba81004260209ne25aa8ffjf22b431a16546315@mail.gmail.com>
References: <p2o113c8ba81004260209ne25aa8ffjf22b431a16546315@mail.gmail.com>
Message-ID: <4BD58764.5020105@chl.com>



IPv3.com wrote:
 >

https://www.arin.net/participate/mailing_lists/aup.html

Specifically Prohibited Activities:

6. Postings by fictional or non-identifiable names and addresses.

How do these people get in?

Thanks,

Joe


From jmaimon at chl.com  Mon Apr 26 09:01:31 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Mon, 26 Apr 2010 09:01:31 -0400
Subject: [arin-ppml] Policy Proposal 110: Preservation of minimal IPv4
 Resources for New and Small Organizations and for IPv6 Transition
In-Reply-To: <3066AC55-025F-454A-ABBC-8B771A653891@delong.com>
References: <4BD0998F.60900@arin.net> <4BD216F1.6070009@chl.com>
	<E59EDC2B-BB76-4ABD-85A5-C42C539DC179@delong.com>
	<4BD45464.700@chl.com>
	<3066AC55-025F-454A-ABBC-8B771A653891@delong.com>
Message-ID: <4BD58EAB.9070500@chl.com>



Owen DeLong wrote:
>    
> IPv4 won't be available regardless of this policy. Your previous 
> paragraph states this. I do not believe it is appropriate for ARIN to 
> discriminate against one class of organizations in favor of another. 
> Frankly, large and extra large subscribers are going to be the first 
> ones denied anyway. Smaller blocks will be available longer and run 
> out slower than larger blocks just by the nature of the allocation 
> process. One could argue that this fact already gives an advantage to 
> small organizations.
>
What I have been intending to state is that this policy would not affect 
demand or requirements for IPv4. It may very well affect availability, 
if not directly, then indirectly by inducing liquidity in a transfer market.

If demand and requirements for IPv4 do not transfer seamlessly to IPv6,  
having this policy would be good thing. If IPv6 adoption accelerate 
properly, this policy is still a public opportunity to demonstrate 
proper stewardship, even as it will likely be unused.

For IPv6 adoption, it may be the best scenario that everyone who tries 
to continue to use IPv4 is totally and completely stymied. However, that 
is not a best case scenario for this community, especially if the 
situation could have been improved and was not by deliberate inaction, 
or worse, deliberate action.

The problem is that while we may consider ARIN to have a history of fair 
dealing, its quite possible to interpret it activities to cast them as 
unfair, to say that the large orgs have always had it easier, both 
financially and  procedurally. Superficially the numbers will appear to 
support this viewpoint.

This policy is an opportunity demonstrate that ARIN tends toward doing 
the right thing at the right times.
> Then you should study survival texts. Turns out that if you are stuck in a wilderness situation with minimal food, you do not actually prolong your life by self-rationing. Your chances of survival actually increase if you continue to eat normally until the food is gone.
>
>    
Not if you can drop your metabolism rate to match. IPv4 utilization 
metabolism rate could be cut quite drastically.

> How did abuse come into your interpretation of my statement? I'm not talking about abuse, I'm talking about creative solutions to policy compliance.
>
> One example:
> 	LargeOrg A decides they need some of this address space.
> 	They hire contractor B to create Entity C -- A new startup.
> 	Entity C is funded and purchases enough infrastructure to justify an allocation or assignment under this policy.
> 	Entity C gets their address space.
> 	Entity C is then purchased by LargeOrg A who invokes section 8.2 of the NRPM and voila. Instant resources.
>
> That's not abuse, that's a legitimate startup being purchased legitimately by a larger organization.
>
> Now, consider how much easier this could become under 8.3.
>
>    
8.3 is specifically disallowed.

This kind of activity would be ARIN discretion where to draw the line.

4.10.1 Affiliation of Organizations

To qualify under these sections organizations may be required to
demonstrate to reasonable satisfaction that they are not affiliated with
any other organizations for the intended purpose of qualifying under
these sections where they would not otherwise. All other aspects of
organization affiliations are not of specific concern to section 4.10

Furthermore, it is not clear at all that channeling demand fulfillment 
for IPv4 in this manner would be such a bad thing, especially if done 
legitimately.

> I don't think that will be the case.  In fact, the large existing orgs will be the first ones to suffer and will, actually, probably have the greatest suffering.
>    
The large hosters, yes. The large commercial leased lines, yes - but 
they will be able to reclaim. They large residential, not so much, they 
can always reclaim huge proportions in favor of LSN relatively easily. 
Those that are a mix of all three, like most, will probably end up doing 
much better than anyone whom this policy would apply to.

In any event there is nothing we can do about it. That is why this 
policy proposes using the space where it actually might make a difference.

> The list is long and irrelevant. Point is that ARIN does not design protocols or build routers. We have little or nothing to do with the level of satisfaction that can be gained from use of IPv6 vs. IPv4. There is little we can do to make it more satisfactory.
>    

They might say that we have not spurred its adoption sufficiently, not 
just ARIN but as a community of organizations and users, in order to 
cash in on IPv4, to maintain market lockup and other similarly nasty things.

Proving we did no such thing could be extremely difficult, as is the 
case for proving all negatives.

> Yes, this might be one of those time periods where it's a bad idea to launch an internet business.
> If you think this is news, you haven't been paying attention.
>    

This policy could make things better, were they to head deep south. I 
believe deliberate inaction is not responsible.

>> Attitudes that are variations of "Tough, sucks to be you" are not going to go far towards helping to win friends and influence people.
>>
>>      
> I'm just saying ARIN shouldn't be making it tougher on one class of organization than another, which is all this proposal really does.  It's like believing that QoS makes your network better.  QoS does nothing of the sort. It just helps you decide which customers to screw when your network becomes inadequate.
>    

There is nothing ARIN can do for the larger orgs, no matter what. There 
is something ARIN can do for the new and small orgs. Therefore, they 
should do it, while they still can.

> Short sighted or not, it was the pretty clear consensus of the community.
>
> Owen
>    

I believe in giving everyone an opportunity to change their minds, 
especially if they were wrong the previous times.

Thanks,

Joe



From michael.dillon at bt.com  Mon Apr 26 09:36:59 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 26 Apr 2010 14:36:59 +0100
Subject: [arin-ppml] Policy Proposal 110: Preservation of minimal IPv4
	Resources for New and Small Organizations and for IPv6 Transition
In-Reply-To: <4BD58EAB.9070500@chl.com>
Message-ID: <28E139F46D45AF49A31950F88C49745805E14F2D@E03MVZ2-UKDY.domain1.systemhost.net>

> > Then you should study survival texts. Turns out that if you 
> are stuck in a wilderness situation with minimal food, you do 
> not actually prolong your life by self-rationing. Your 
> chances of survival actually increase if you continue to eat 
> normally until the food is gone.
> >
> Not if you can drop your metabolism rate to match. IPv4 
> utilization metabolism rate could be cut quite drastically.

Also, you can eat rubbish to extend your life in a situation
like this, i.e. stuff that you might not ordinarily eat mixed
with dirt. I'm not joking. This is exactly what Cabeza de Vaca
did somewhere in Texas (along with a tribe of Indians) as he
tried to make his way back to Spanish territory. 

If you go to this URL, http://www.floridahistory.com/cab-txt3.html
search for "pounding" and read the whole paragraph, you will
see what I mean.

What does this have to do with IPv4 addresses? There is really
no shortage for those who are willing to eat a bit of rubbish.
I know of one company which uses 1/8 through 8/8 and 196/8
internally since before RFC 1918 addresses were created.
126/8 was assigned to Softbank BB in Japan for their 
nationwide network. For those who want predictability in
the quality of rubbish addresses, this is a good block. 
Many people block large chunks of address space allocated to
Chinese networks. Why not use some of these rubbish addresses
as well?

There is plenty of IPv4 food available for the small fry that
might end up in desperate straits when ARIN's cupboard has
gone bare. I don't see any good reason for ARIN to try and
ration out a small reserve supply when there is plenty of
more or less nutritious rubbish around.

Some people may be shocked that I am saying, "Let them eat
garbage", but the fact is that this whole discussion is
already about an outrageously unlikely scenario. And in the
real world, when people actually do fall into dire straits
like this, they still eat the garbage just like Cabeza de Vaca
did back in the 1520's. It is a successful survival strategy.

> They might say that we have not spurred its adoption 
> sufficiently, not just ARIN but as a community of 
> organizations and users, in order to cash in on IPv4, to 
> maintain market lockup and other similarly nasty things.

ARIN's job is not to orchestrate the entire Internet, not even
the North American Internet. We just manage IP addresses in
a way that is fair to all organizations. That doesn't necessarily
mean that all organizations feel "fairly treated". Quite likely
most people feel unfairly treated bu rationally, they realize
that they are not being made to suffer less than their competitors.

If you are saying that ARIN must accept this policy for CYA,
then I object, because ARIN has done a lot of other work
in outreach that is more than adequate for CYA.

> This policy could make things better, were they to head deep 
> south. I believe deliberate inaction is not responsible.

This policy could also make things worse by holding out the
hope of something that ARIN simply CANNOT give. If this 
policy passes, it will be misinterpreted in the press and
people will come expecting a handout and get nothing.

> There is nothing ARIN can do for the larger orgs, no matter 
> what. 

Agreed. By now larger orgs know that there is at most, one
kick left at the can and that will be the last IPv4 allocation
EVER.

> There is something ARIN can do for the new and small 
> orgs. Therefore, they should do it, while they still can.

There is a qualitative difference here, it is not just a matter
of organizational scale. If a large org makes bad investments,
they can get money from the bank to cover up their mistakes and
fix things. But if a small org, encouraged by this wierd policy,
makes mistakes, the banks will pull all their loans and force
the business into bankruptcy. We should not be holding out
false hopes. If you are a small business that wants to expand
or build networks after Christmas this year, it had better be
using IPv6 or some form of NAT. If by some miraculous chance
you actuall get an ARIN allocation next year, count your blessings
as you reduce operational costs (no NAT) and perhaps repurpose
a box or two for some more profitable use.

That is the kind of scenario that we are discussing here.

--Michael Dillon


From bill at herrin.us  Mon Apr 26 10:04:44 2010
From: bill at herrin.us (William Herrin)
Date: Mon, 26 Apr 2010 04:04:44 -1000
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <C7FAA9DD.963C%ggiesen@akn.ca>
References: <x2y3c3e3fca1004252313v340a4d50j97a5a115119a5b95@mail.gmail.com> 
	<C7FAA9DD.963C%ggiesen@akn.ca>
Message-ID: <m2m3c3e3fca1004260704jc38d9e52i3df25c897d97785d@mail.gmail.com>

On Sun, Apr 25, 2010 at 8:24 PM, Gary Giesen <ggiesen at akn.ca> wrote:
> On 10-04-26 2:13 AM, "William Herrin" <bill at herrin.us> wrote:
>> It's a line item in the overhead budget. The budget requested is
>> larger than the budget approved.
> An IPv6 /32 also doesn't cost anything if you have a /20 or larger v4
> allocation. If you have an X-Small (smaller than /20), it's only an extra
> $1250/year. Pretty small potatoes. By the time you *need* IPv6, it will just
> be the cost of doing business, and will be pretty easy to justify it (pretty
> hard to be an ISP without it).

By the time I need IPv6, you need me to have finished my IPv6
deployment ages ago so that you can stop paying the premium for IPv4.

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 baptista at publicroot.org  Mon Apr 26 10:22:28 2010
From: baptista at publicroot.org (Joe Baptista)
Date: Mon, 26 Apr 2010 10:22:28 -0400
Subject: [arin-ppml] IPv6 is Becoming a Complex Multi-Dimensional
	Deployment Space of Islands
In-Reply-To: <4BD58764.5020105@chl.com>
References: <p2o113c8ba81004260209ne25aa8ffjf22b431a16546315@mail.gmail.com>
	<4BD58764.5020105@chl.com>
Message-ID: <q2z874c02a21004260722ra6ba4c70s1d40f8e737575172@mail.gmail.com>

I think IPv3.com is Jim Fleming. You should know that.

In any case he brings up some interesting points.

Why is ARIN charging so much for /64 - why not give it away. Thats one of
the point being made.

The current ARIN & RIR business model for IPv6 has failed.

And he's right ... it's a complex game and the numbers are running out. Oh
me ... oh my.

regards
joe baptista

On Mon, Apr 26, 2010 at 8:30 AM, Joe Maimon <jmaimon at chl.com> wrote:

>
>
> IPv3.com wrote:
> >
>
> https://www.arin.net/participate/mailing_lists/aup.html
>
> Specifically Prohibited Activities:
>
> 6. Postings by fictional or non-identifiable names and addresses.
>
> How do these people get in?
>
> Thanks,
>
> Joe
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
Joe Baptista

www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive, Representative &
Accountable to the Internet community @large.
----------------------------------------------------------------
 Office: +1 (360) 526-6077 (extension 052)
    Fax: +1 (509) 479-0084

Personal: http://baptista.cynikal.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100426/0a9c3019/attachment.htm>

From NOC at ChangeIP.com  Mon Apr 26 11:27:00 2010
From: NOC at ChangeIP.com (NOC at ChangeIP.com)
Date: Mon, 26 Apr 2010 08:27:00 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
Message-ID: <10727C0F12264762A332829ED3A8E51C@changeip.com>

----- Original Message ----- 
From: "Gary Giesen" <ggiesen at akn.ca>
> An IPv6 /32 also doesn't cost anything if you have a /20 or larger v4
> allocation. If you have an X-Small (smaller than /20), it's only an extra
> $1250/year. Pretty small potatoes. By the time you *need* IPv6, it will 
> just
> be the cost of doing business, and will be pretty easy to justify it 
> (pretty
> hard to be an ISP without it).
>

Read that again and think about how we really want people to adopt IPv6.  Do
you want someone to start using it NOW because it's free, or when its too
late because it cost $1250/yr extra and wasn't viable because they are
almost going out of business as it is?

How much of the IPv4 space is taken by x-small at the moment?  Do you really
want to delay that group from adopting ipv6?  Sheesh! 



From tedm at ipinc.net  Mon Apr 26 13:09:58 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 26 Apr 2010 10:09:58 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <10727C0F12264762A332829ED3A8E51C@changeip.com>
References: <10727C0F12264762A332829ED3A8E51C@changeip.com>
Message-ID: <4BD5C8E6.4020506@ipinc.net>


Interesting how costs have been bandied about, a few days ago
it was $2250 now it's $1250.

Please tell me the name of an employer where any employee who
is NOT a salesman can go to his or her boss and say "Can I go spend a 
thousand bucks on something that has no justification for existence 
other than we might need it sometime in the future?"


Ted


On 4/26/2010 8:27 AM, NOC at ChangeIP.com wrote:
> ----- Original Message ----- From: "Gary Giesen" <ggiesen at akn.ca>
>> An IPv6 /32 also doesn't cost anything if you have a /20 or larger v4
>> allocation. If you have an X-Small (smaller than /20), it's only an extra
>> $1250/year. Pretty small potatoes. By the time you *need* IPv6, it
>> will just
>> be the cost of doing business, and will be pretty easy to justify it
>> (pretty
>> hard to be an ISP without it).
>>
>
> Read that again and think about how we really want people to adopt IPv6. Do
> you want someone to start using it NOW because it's free, or when its too
> late because it cost $1250/yr extra and wasn't viable because they are
> almost going out of business as it is?
>
> How much of the IPv4 space is taken by x-small at the moment? Do you really
> want to delay that group from adopting ipv6? Sheesh!
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From ggiesen at akn.ca  Mon Apr 26 13:28:20 2010
From: ggiesen at akn.ca (Gary T. Giesen)
Date: Mon, 26 Apr 2010 13:28:20 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <4BD5C8E6.4020506@ipinc.net>
References: <10727C0F12264762A332829ED3A8E51C@changeip.com>
	<4BD5C8E6.4020506@ipinc.net>
Message-ID: <1272302900.13180.25.camel@ggiesen-workstation.netsurf.net>

We're only talking about ISPs here, not end users. Their raison d'?tre
is to provide network services (and one would hope that would include
IPv6). It's pretty late in the game at this point to have not at least
sold management that IPv6 needs to be deployed. I think being ready for
IPv6 is justification enough (it's coming whether you like it or not).
And $1250 is a pretty small price to pay.

My $0.02.

GG

On Mon, 2010-04-26 at 13:09 -0400, Ted Mittelstaedt wrote:
> Interesting how costs have been bandied about, a few days ago
> it was $2250 now it's $1250.
> 
> Please tell me the name of an employer where any employee who
> is NOT a salesman can go to his or her boss and say "Can I go spend a 
> thousand bucks on something that has no justification for existence 
> other than we might need it sometime in the future?"
> 
> 
> Ted
> 
> 
> On 4/26/2010 8:27 AM, NOC at ChangeIP.com wrote:
> > ----- Original Message ----- From: "Gary Giesen" <ggiesen at akn.ca>
> >> An IPv6 /32 also doesn't cost anything if you have a /20 or larger v4
> >> allocation. If you have an X-Small (smaller than /20), it's only an extra
> >> $1250/year. Pretty small potatoes. By the time you *need* IPv6, it
> >> will just
> >> be the cost of doing business, and will be pretty easy to justify it
> >> (pretty
> >> hard to be an ISP without it).
> >>
> >
> > Read that again and think about how we really want people to adopt IPv6. Do
> > you want someone to start using it NOW because it's free, or when its too
> > late because it cost $1250/yr extra and wasn't viable because they are
> > almost going out of business as it is?
> >
> > How much of the IPv4 space is taken by x-small at the moment? Do you really
> > want to delay that group from adopting ipv6? Sheesh!
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From ggiesen at akn.ca  Mon Apr 26 13:35:56 2010
From: ggiesen at akn.ca (Gary T. Giesen)
Date: Mon, 26 Apr 2010 13:35:56 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <1272302900.13180.25.camel@ggiesen-workstation.netsurf.net>
References: <10727C0F12264762A332829ED3A8E51C@changeip.com>
	<4BD5C8E6.4020506@ipinc.net>
	<1272302900.13180.25.camel@ggiesen-workstation.netsurf.net>
Message-ID: <1272303356.13180.32.camel@ggiesen-workstation.netsurf.net>

Just for clarification, it's $2250 if you don't have an IPv4 allocation
direct from ARIN, and $1250 if you currently have an X-Small IPv4
allocation (the difference in price between your X-Small IPv4 allocation
that you're already paying $1250/yr for, and a Small IPv6 allocation).
If you have a Small allocation (/20 to /19), it's free. 

For 2010, there's also a 50% fee waiver in effect. Which means if you
have an X-Small from ARIN, it's free, and if you have no direct
allocations from ARIN, it's $1250.

I would support ARIN extending/increasing the fee waiver (temporarily)
to ease the pain for X-Small allocations, if that is your concern. I
don't think decreasing the minimum allocation size (less than /32) does
anyone any favours.

GG

On Mon, 2010-04-26 at 13:28 -0400, Gary T. Giesen wrote:
> We're only talking about ISPs here, not end users. Their raison d'?tre
> is to provide network services (and one would hope that would include
> IPv6). It's pretty late in the game at this point to have not at least
> sold management that IPv6 needs to be deployed. I think being ready for
> IPv6 is justification enough (it's coming whether you like it or not).
> And $1250 is a pretty small price to pay.
> 
> My $0.02.
> 
> GG
> 
> On Mon, 2010-04-26 at 13:09 -0400, Ted Mittelstaedt wrote:
> > Interesting how costs have been bandied about, a few days ago
> > it was $2250 now it's $1250.
> > 
> > Please tell me the name of an employer where any employee who
> > is NOT a salesman can go to his or her boss and say "Can I go spend a 
> > thousand bucks on something that has no justification for existence 
> > other than we might need it sometime in the future?"
> > 
> > 
> > Ted
> > 
> > 
> > On 4/26/2010 8:27 AM, NOC at ChangeIP.com wrote:
> > > ----- Original Message ----- From: "Gary Giesen" <ggiesen at akn.ca>
> > >> An IPv6 /32 also doesn't cost anything if you have a /20 or larger v4
> > >> allocation. If you have an X-Small (smaller than /20), it's only an extra
> > >> $1250/year. Pretty small potatoes. By the time you *need* IPv6, it
> > >> will just
> > >> be the cost of doing business, and will be pretty easy to justify it
> > >> (pretty
> > >> hard to be an ISP without it).
> > >>
> > >
> > > Read that again and think about how we really want people to adopt IPv6. Do
> > > you want someone to start using it NOW because it's free, or when its too
> > > late because it cost $1250/yr extra and wasn't viable because they are
> > > almost going out of business as it is?
> > >
> > > How much of the IPv4 space is taken by x-small at the moment? Do you really
> > > want to delay that group from adopting ipv6? Sheesh!
> > > _______________________________________________
> > > PPML
> > > You are receiving this message because you are subscribed to
> > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact info at arin.net if you experience any issues.
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From terry.l.davis at boeing.com  Mon Apr 26 13:20:17 2010
From: terry.l.davis at boeing.com (Davis, Terry L)
Date: Mon, 26 Apr 2010 10:20:17 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF5516235A61@XCH-NW-05V.nw.nos.boeing.com>

Ted

Agree!

So we also don't get it into labs or just available on the dev networks for the apps folks to play with and learn.

And even the startups are still not picking it up.  Of course like you pointed out, they are cash starved already.

And if it were openly available, sure some of us would grab an address for home nets/labs.  Would that be bad too if it gets more folks exposed and playing with v6?


Take care
Terry

Via Blackberry handheld

----- Original Message -----
From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net>
To: arin-ppml at arin.net <arin-ppml at arin.net>
Sent: Mon Apr 26 10:09:58 2010
Subject: Re: [arin-ppml] IPv6 /32 minimum for extra-small ISP


Interesting how costs have been bandied about, a few days ago
it was $2250 now it's $1250.

Please tell me the name of an employer where any employee who
is NOT a salesman can go to his or her boss and say "Can I go spend a 
thousand bucks on something that has no justification for existence 
other than we might need it sometime in the future?"


Ted


On 4/26/2010 8:27 AM, NOC at ChangeIP.com wrote:
> ----- Original Message ----- From: "Gary Giesen" <ggiesen at akn.ca>
>> An IPv6 /32 also doesn't cost anything if you have a /20 or larger v4
>> allocation. If you have an X-Small (smaller than /20), it's only an extra
>> $1250/year. Pretty small potatoes. By the time you *need* IPv6, it
>> will just
>> be the cost of doing business, and will be pretty easy to justify it
>> (pretty
>> hard to be an ISP without it).
>>
>
> Read that again and think about how we really want people to adopt IPv6. Do
> you want someone to start using it NOW because it's free, or when its too
> late because it cost $1250/yr extra and wasn't viable because they are
> almost going out of business as it is?
>
> How much of the IPv4 space is taken by x-small at the moment? Do you really
> want to delay that group from adopting ipv6? Sheesh!
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.

From kkargel at polartel.com  Mon Apr 26 13:49:03 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 26 Apr 2010 12:49:03 -0500
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <1272302900.13180.25.camel@ggiesen-workstation.netsurf.net>
References: <10727C0F12264762A332829ED3A8E51C@changeip.com>
	<4BD5C8E6.4020506@ipinc.net>
	<1272302900.13180.25.camel@ggiesen-workstation.netsurf.net>
Message-ID: <8695009A81378E48879980039EEDAD2889A5B786@MAIL1.polartel.local>



 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Gary T. Giesen
> Sent: Monday, April 26, 2010 12:28 PM
> To: Ted Mittelstaedt
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] IPv6 /32 minimum for extra-small ISP
> 
> We're only talking about ISPs here, not end users. Their raison d'?tre
> is to provide network services (and one would hope that would include
> IPv6). It's pretty late in the game at this point to have not at least
> sold management that IPv6 needs to be deployed. I think being ready for
> IPv6 is justification enough (it's coming whether you like it or not).
> And $1250 is a pretty small price to pay.
> 
> My $0.02.
> 
$1200 may be insignificant or trivial in your world.  

In the world of a small independent telco offering IP to it's customers a $1200 recurring expense is neither insignificant nor trivial. 
 


From cgrundemann at gmail.com  Mon Apr 26 14:00:27 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Mon, 26 Apr 2010 12:00:27 -0600
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF5516235A61@XCH-NW-05V.nw.nos.boeing.com>
References: <0267B5481DCC474D8088BF4A25C7F1DF5516235A61@XCH-NW-05V.nw.nos.boeing.com>
Message-ID: <h2g443de7ad1004261100n7746fabbka19c42c4686ceb33@mail.gmail.com>

On Mon, Apr 26, 2010 at 11:20, Davis, Terry L <terry.l.davis at boeing.com> wrote:
> Ted
>
> Agree!
>
> So we also don't get it into labs or just available on the dev networks for the apps folks to play with and learn.
>
> And even the startups are still not picking it up. ?Of course like you pointed out, they are cash starved already.
>
> And if it were openly available, sure some of us would grab an address for home nets/labs. ?Would that be bad too if it gets more folks exposed and playing with v6?

For home nets, PA space is readily available from tunnel brokers (such
as HE.net and SixXS).
For labs, ULA-R is likely suitable if PA space is not.
PA space is also available from a growing number of carriers natively
(not-tunneled).
For ISPs who need addresses to hand out to customers, see Gary's
message regarding the current 50% waiver.

IOW - IPv6 *is* openly available.

My apologies for continuing an increasingly off-topic thread, I felt
compelled to correct the record.

>
>
> Take care
> Terry
>
> Via Blackberry handheld
>
> ----- Original Message -----
> From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net>
> To: arin-ppml at arin.net <arin-ppml at arin.net>
> Sent: Mon Apr 26 10:09:58 2010
> Subject: Re: [arin-ppml] IPv6 /32 minimum for extra-small ISP
>
>
> Interesting how costs have been bandied about, a few days ago
> it was $2250 now it's $1250.
>
> Please tell me the name of an employer where any employee who
> is NOT a salesman can go to his or her boss and say "Can I go spend a
> thousand bucks on something that has no justification for existence
> other than we might need it sometime in the future?"
>
>
> Ted
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From tedm at ipinc.net  Mon Apr 26 14:25:47 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 26 Apr 2010 11:25:47 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <1272303356.13180.32.camel@ggiesen-workstation.netsurf.net>
References: <10727C0F12264762A332829ED3A8E51C@changeip.com>	
	<4BD5C8E6.4020506@ipinc.net>	
	<1272302900.13180.25.camel@ggiesen-workstation.netsurf.net>
	<1272303356.13180.32.camel@ggiesen-workstation.netsurf.net>
Message-ID: <4BD5DAAB.2020306@ipinc.net>



On 4/26/2010 10:35 AM, Gary T. Giesen wrote:
> Just for clarification, it's $2250 if you don't have an IPv4 allocation
> direct from ARIN, and $1250 if you currently have an X-Small IPv4
> allocation (the difference in price between your X-Small IPv4 allocation
> that you're already paying $1250/yr for, and a Small IPv6 allocation).
> If you have a Small allocation (/20 to /19), it's free.
>
> For 2010, there's also a 50% fee waiver in effect. Which means if you
> have an X-Small from ARIN, it's free, and if you have no direct
> allocations from ARIN, it's $1250.
>
> I would support ARIN extending/increasing the fee waiver (temporarily)
> to ease the pain for X-Small allocations, if that is your concern.

That is actually what I have suggested from the beginning, as a 
temporary extension of the fee waiver to keep the cost of IPv6 at
parity with the minimal IPv4 cost, for the next couple years, until
all other fee waivers have expired.  (because, I think that by then
we will have a better idea then of fee changes that might be needed)

Ted

  I
> don't think decreasing the minimum allocation size (less than /32) does
> anyone any favours.
>
> GG
>
> On Mon, 2010-04-26 at 13:28 -0400, Gary T. Giesen wrote:
>> We're only talking about ISPs here, not end users. Their raison d'?tre
>> is to provide network services (and one would hope that would include
>> IPv6). It's pretty late in the game at this point to have not at least
>> sold management that IPv6 needs to be deployed. I think being ready for
>> IPv6 is justification enough (it's coming whether you like it or not).
>> And $1250 is a pretty small price to pay.
>>
>> My $0.02.
>>
>> GG
>>
>> On Mon, 2010-04-26 at 13:09 -0400, Ted Mittelstaedt wrote:
>>> Interesting how costs have been bandied about, a few days ago
>>> it was $2250 now it's $1250.
>>>
>>> Please tell me the name of an employer where any employee who
>>> is NOT a salesman can go to his or her boss and say "Can I go spend a
>>> thousand bucks on something that has no justification for existence
>>> other than we might need it sometime in the future?"
>>>
>>>
>>> Ted
>>>
>>>
>>> On 4/26/2010 8:27 AM, NOC at ChangeIP.com wrote:
>>>> ----- Original Message ----- From: "Gary Giesen"<ggiesen at akn.ca>
>>>>> An IPv6 /32 also doesn't cost anything if you have a /20 or larger v4
>>>>> allocation. If you have an X-Small (smaller than /20), it's only an extra
>>>>> $1250/year. Pretty small potatoes. By the time you *need* IPv6, it
>>>>> will just
>>>>> be the cost of doing business, and will be pretty easy to justify it
>>>>> (pretty
>>>>> hard to be an ISP without it).
>>>>>
>>>>
>>>> Read that again and think about how we really want people to adopt IPv6. Do
>>>> you want someone to start using it NOW because it's free, or when its too
>>>> late because it cost $1250/yr extra and wasn't viable because they are
>>>> almost going out of business as it is?
>>>>
>>>> How much of the IPv4 space is taken by x-small at the moment? Do you really
>>>> want to delay that group from adopting ipv6? Sheesh!
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>
>


From tedm at ipinc.net  Mon Apr 26 14:27:51 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 26 Apr 2010 11:27:51 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <1272302900.13180.25.camel@ggiesen-workstation.netsurf.net>
References: <10727C0F12264762A332829ED3A8E51C@changeip.com>	
	<4BD5C8E6.4020506@ipinc.net>
	<1272302900.13180.25.camel@ggiesen-workstation.netsurf.net>
Message-ID: <4BD5DB27.1080807@ipinc.net>



On 4/26/2010 10:28 AM, Gary T. Giesen wrote:
> We're only talking about ISPs here, not end users. Their raison d'?tre
> is to provide network services (and one would hope that would include
> IPv6). It's pretty late in the game at this point to have not at least
> sold management that IPv6 needs to be deployed. I think being ready for
> IPv6 is justification enough (it's coming whether you like it or not).
> And $1250 is a pretty small price to pay.
>
> My $0.02.
>

If $1250 is a pretty small price then what is $0.02?    :-))

Ted



> GG
>
> On Mon, 2010-04-26 at 13:09 -0400, Ted Mittelstaedt wrote:
>> Interesting how costs have been bandied about, a few days ago
>> it was $2250 now it's $1250.
>>
>> Please tell me the name of an employer where any employee who
>> is NOT a salesman can go to his or her boss and say "Can I go spend a
>> thousand bucks on something that has no justification for existence
>> other than we might need it sometime in the future?"
>>
>>
>> Ted
>>
>>
>> On 4/26/2010 8:27 AM, NOC at ChangeIP.com wrote:
>>> ----- Original Message ----- From: "Gary Giesen"<ggiesen at akn.ca>
>>>> An IPv6 /32 also doesn't cost anything if you have a /20 or larger v4
>>>> allocation. If you have an X-Small (smaller than /20), it's only an extra
>>>> $1250/year. Pretty small potatoes. By the time you *need* IPv6, it
>>>> will just
>>>> be the cost of doing business, and will be pretty easy to justify it
>>>> (pretty
>>>> hard to be an ISP without it).
>>>>
>>>
>>> Read that again and think about how we really want people to adopt IPv6. Do
>>> you want someone to start using it NOW because it's free, or when its too
>>> late because it cost $1250/yr extra and wasn't viable because they are
>>> almost going out of business as it is?
>>>
>>> How much of the IPv4 space is taken by x-small at the moment? Do you really
>>> want to delay that group from adopting ipv6? Sheesh!
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>
>


From cengel at sponsordirect.com  Mon Apr 26 14:39:54 2010
From: cengel at sponsordirect.com (Chris Engel)
Date: Mon, 26 Apr 2010 14:39:54 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <mailman.1458.1272304837.28982.arin-ppml@arin.net>
Message-ID: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA64F@Skyhawk>


Ted Mittelstaedt wrote:

> Interesting how costs have been bandied about, a few days ago
> it was $2250 now it's $1250.
>
> Please tell me the name of an employer where any employee who
> is NOT a salesman can go to his or her boss and say "Can I go spend a
> thousand bucks on something that has no justification for existence
> other than we might need it sometime in the future?"


Ted,

I think you basicaly described most types of insurance that businesses carry. I can't speak for  ISP's but in the Enterprise world 1-2K isn't going to even be a blip on the radar screen as far as the real costs of IPv6 (assuming an Enterprise would even go through ARIN rather then thier ISP for space). The real costs will come in man-hours of planning, deployment, training, support and skill building, HW/SW compatability issues, compliance issues, lost business and broken applications. As far as costs...those are the real killers for IPv6 (IMO).






Christopher Engel



From michael.dillon at bt.com  Mon Apr 26 14:58:50 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 26 Apr 2010 19:58:50 +0100
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF5516235A61@XCH-NW-05V.nw.nos.boeing.com>
Message-ID: <28E139F46D45AF49A31950F88C49745805E1516A@E03MVZ2-UKDY.domain1.systemhost.net>

> So we also don't get it into labs or just available on the 
> dev networks for the apps folks to play with and learn.

Why not?

> And even the startups are still not picking it up.  Of course 
> like you pointed out, they are cash starved already.

Then they should sign up at http://www.tunnelbroker.net/

> And if it were openly available, sure some of us would grab 
> an address for home nets/labs.  Would that be bad too if it 
> gets more folks exposed and playing with v6?

Like I said before, http://www.tunnelbroker.net/

ARIN is not the only place to get IPv6 address blocks.

--Michael Dillon


From christopher.morrow at gmail.com  Mon Apr 26 14:59:59 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Mon, 26 Apr 2010 14:59:59 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <8695009A81378E48879980039EEDAD2889A5B786@MAIL1.polartel.local>
References: <10727C0F12264762A332829ED3A8E51C@changeip.com>
	<4BD5C8E6.4020506@ipinc.net>
	<1272302900.13180.25.camel@ggiesen-workstation.netsurf.net>
	<8695009A81378E48879980039EEDAD2889A5B786@MAIL1.polartel.local>
Message-ID: <v2g75cb24521004261159r63527c50i904b43ed220f0ee7@mail.gmail.com>

On Mon, Apr 26, 2010 at 1:49 PM, Kevin Kargel <kkargel at polartel.com> wrote:
>>
> $1200 may be insignificant or trivial in your world.
>
> In the world of a small independent telco offering IP to it's customers a $1200 recurring expense is neither insignificant nor trivial.

just so we understand new ops employees then buy their own compute
resources to do their job? (1200$ is about a desktop/laptop price
including support and monitor and such)

-chris


From ggiesen at akn.ca  Mon Apr 26 15:20:07 2010
From: ggiesen at akn.ca (Gary T. Giesen)
Date: Mon, 26 Apr 2010 15:20:07 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <8D7A32502ED0436C9BEC3BCC32879209@WolfPC>
References: <10727C0F12264762A332829ED3A8E51C@changeip.com>
	<4BD5C8E6.4020506@ipinc.net>
	<1272302900.13180.25.camel@ggiesen-workstation.netsurf.net>
	<8695009A81378E48879980039EEDAD2889A5B786@MAIL1.polartel.local>
	<8D7A32502ED0436C9BEC3BCC32879209@WolfPC>
Message-ID: <1272309607.13180.34.camel@ggiesen-workstation.netsurf.net>

On Mon, 2010-04-26 at 14:36 -0400, Wolfpaw - Dale Corse wrote:
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> > Behalf Of Gary T. Giesen
> > Sent: Monday, April 26, 2010 12:28 PM
> > To: Ted Mittelstaedt
> > Cc: arin-ppml at arin.net
> > Subject: Re: [arin-ppml] IPv6 /32 minimum for extra-small ISP
> > 
> > We're only talking about ISPs here, not end users. Their raison d'?tre
> > is to provide network services (and one would hope that would include
> > IPv6). It's pretty late in the game at this point to have not at least
> > sold management that IPv6 needs to be deployed. I think being ready for
> > IPv6 is justification enough (it's coming whether you like it or not).
> > And $1250 is a pretty small price to pay.
> > 
> > My $0.02.
> > 
> 
> I have to chime in here too - $1,200 is still $1,200 - certainly a
> significant invoice here. A 50% cost increase over the current 'solution' -
> especially on a recurring basis is going to hinder adoption IMHO. I would be
> pleased to offer customers IPv6 - currently our carriers are just running it
> in beta - however doubling the cost of IP space would certainly make us more
> inclined not to bother until it becomes operationally unavoidable... the
> customers are certainly not going to pay us extra for something the majority
> probably don't even understand, so why would we burn the cash unless we have
> a need?

Another bonus for the really small ISPs (the ones most impacted by this)
is that they're probably using PA space. A good sell for paying for PI
IPv6 is that they will never have to renumber again. Ever. That's pretty
cheap insurance.




From fm-lists at st-kilda.org  Mon Apr 26 15:15:13 2010
From: fm-lists at st-kilda.org (Fearghas McKay)
Date: Mon, 26 Apr 2010 20:15:13 +0100
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <v2g75cb24521004261159r63527c50i904b43ed220f0ee7@mail.gmail.com>
References: <10727C0F12264762A332829ED3A8E51C@changeip.com>
	<4BD5C8E6.4020506@ipinc.net>
	<1272302900.13180.25.camel@ggiesen-workstation.netsurf.net>
	<8695009A81378E48879980039EEDAD2889A5B786@MAIL1.polartel.local>
	<v2g75cb24521004261159r63527c50i904b43ed220f0ee7@mail.gmail.com>
Message-ID: <C73883B2-4C8B-4D35-A1C2-928CC21FD2DE@st-kilda.org>


On 26 Apr 2010, at 19:59, Christopher Morrow wrote:

> just so we understand new ops employees then buy their own compute
> resources to do their job? (1200$ is about a desktop/laptop price
> including support and monitor and such)

yep - I nearly joined a SP type startup that had new hires, not  
founders/equity holders, all buying/bringing their own hi spec laptops  
because the provided option was not up to the job. The machine on  
offer was not even at the $1200 price point.

	f



From kkargel at polartel.com  Mon Apr 26 15:58:51 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 26 Apr 2010 14:58:51 -0500
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <v2g75cb24521004261159r63527c50i904b43ed220f0ee7@mail.gmail.com>
References: <10727C0F12264762A332829ED3A8E51C@changeip.com>
	<4BD5C8E6.4020506@ipinc.net>
	<1272302900.13180.25.camel@ggiesen-workstation.netsurf.net>
	<8695009A81378E48879980039EEDAD2889A5B786@MAIL1.polartel.local>
	<v2g75cb24521004261159r63527c50i904b43ed220f0ee7@mail.gmail.com>
Message-ID: <8695009A81378E48879980039EEDAD2889A5B78B@MAIL1.polartel.local>

And how does that make $1200 trivial?

Are you saying that anything having to do with a new employee is trivial? 

Are you suggesting that all companies are buying computers for employees on a whim?  You must work in a different world than I do.  Employees here certainly don't get a new computer every year.  

Most people I know need a little mor justification to get a new computer than "I want one."


Kevin

 

> -----Original Message-----
> From: Christopher Morrow [mailto:christopher.morrow at gmail.com]
> Sent: Monday, April 26, 2010 2:00 PM
> To: Kevin Kargel
> Cc: Gary T. Giesen; Ted Mittelstaedt; arin-ppml at arin.net
> Subject: Re: [arin-ppml] IPv6 /32 minimum for extra-small ISP
> 
> On Mon, Apr 26, 2010 at 1:49 PM, Kevin Kargel <kkargel at polartel.com>
> wrote:
> >>
> > $1200 may be insignificant or trivial in your world.
> >
> > In the world of a small independent telco offering IP to it's customers
> a $1200 recurring expense is neither insignificant nor trivial.
> 
> just so we understand new ops employees then buy their own compute
> resources to do their job? (1200$ is about a desktop/laptop price
> including support and monitor and such)
> 
> -chris


From alh-ietf at tndh.net  Mon Apr 26 16:40:43 2010
From: alh-ietf at tndh.net (Tony Hain)
Date: Mon, 26 Apr 2010 13:40:43 -0700
Subject: [arin-ppml] ULA-C
In-Reply-To: <014501cacc77$5573fe00$005bfa00$@net>
References: <014501cacc77$5573fe00$005bfa00$@net>
Message-ID: <046501cae580$bdf9a6b0$39ecf410$@net>

Here is the significant part of the text change I expect to put in the next
I-D.

Replace intro paragraph 2 with:
In any case, the prefixes defined here are not expected to appear in the
routing system for the global Internet.  A frequent question is how this
prefix differs from a PI assignment. The simple answer is in expectation of
global public routability.  A PI assignment has the expectation that it
could appear in the global DFZ, where a ULA-C registration is expected to be
limited reach as service providers are free to, and expected to filter the
entire FC00::/7 prefix as bogon space.  The appropriate use of these
prefixes is within a single network administration, or between privately
interconnected networks that want to ensure that private communications do
not accidentally get routed over the public Internet as might happen with
PI.


Replace section 3.2 & 3.3 with:
Global IDs MUST be allocated under a single allocation and registration
authority.  The IAB SHOULD designate IANA as the registration authority. As
policies differ around the world, IANA SHOULD delegate to the RIRs in a
manner similar to the /12 approach used for the 2000::/3 prefix.  The RIRs
SHOULD establish registration policies which recognize that ULA-C prefixes
are not a threat to the global DFZ, and therefore easier to justify.
Organizations that don't want an ongoing relationship with the RIRs SHOULD
be directed to RFC 4193.

The requirements for ULA-C allocation and registrations are:

   - Globally Unique.
   - Available to anyone in an unbiased manner.
   - Available as a single prefix when justified to align subnet structures
with PA or PI.


Other clean up as necessary to align with this simplified text. The point is
to remove as much policy as possible from the IETF text, and leave that to
each region.

I believe this is closer to addressing the range of concerns raised, but as
always comments are welcome. I expect to update the I-D this week, and
discussion of that will occur on the 6man working group list.

Tony




> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Tony Hain
> Sent: Thursday, March 25, 2010 5:00 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] ULA-C
> 
> FYI ---
> 
> I will be updating https://datatracker.ietf.org/doc/draft-hain-ipv6-
> ulac/
> in the next few weeks. Comments welcome.
> 
> Tony
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From tedm at ipinc.net  Mon Apr 26 16:46:31 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 26 Apr 2010 13:46:31 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA64F@Skyhawk>
References: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA64F@Skyhawk>
Message-ID: <4BD5FBA7.4030004@ipinc.net>



On 4/26/2010 11:39 AM, Chris Engel wrote:
>
> Ted Mittelstaedt wrote:
>
>> Interesting how costs have been bandied about, a few days ago it
>> was $2250 now it's $1250.
>>
>> Please tell me the name of an employer where any employee who is
>> NOT a salesman can go to his or her boss and say "Can I go spend a
>> thousand bucks on something that has no justification for
>> existence other than we might need it sometime in the future?"
>
>
> Ted,
>
> I think you basicaly described most types of insurance that
> businesses carry.

That isn't a good analogy.

The proper analogous statement would be the employee who told their boss 
they needed to spend a thousand bucks on something that has no 
justification for existence other than we might need it sometime in the 
future, OTHERWISE if we didn't send the money we could be sued if we
did need it.

That's the difference between buying insurance and buying IPV6
in a nutshell - at the current time, of course.

> I can't speak for  ISP's but in the Enterprise
> world 1-2K isn't going to even be a blip on the radar screen as far
> as the real costs of IPv6 (assuming an Enterprise would even go
> through ARIN rather then thier ISP for space).

Right, of course the debate wouldn't affect Enterprises anyway
because they aren't minimal users of IPv4.  (we would assume)

> The real costs will
> come in man-hours of planning, deployment, training, support and
> skill building, HW/SW compatability issues, compliance issues, lost
> business and broken applications. As far as costs...those are the
> real killers for IPv6 (IMO).
>

Looking at IPv6 from a purely financial perspective what the
enterprise is ultimately going to come up against is that you
are definitely going to lose customers if you have no IP to
give them, and you may lose customers if you have IP to give
them but it's only IPv6.

And of course since the actual IPv4 "runout" is going to vary
from company to company, the companies with the most money
who can afford to buy IPv4 off the transfer market, will have
a competitive advantage - as long as the transfer market can
continue to fill IPv4 orders.

Ted

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


From tedm at ipinc.net  Mon Apr 26 17:25:19 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 26 Apr 2010 14:25:19 -0700
Subject: [arin-ppml] Is ARIN (The Business) Too Opaque for the Public
 to	Participate ?
In-Reply-To: <t2o113c8ba81004250822p11f1044cq2d7382c79aecb744@mail.gmail.com>
References: <t2o113c8ba81004250822p11f1044cq2d7382c79aecb744@mail.gmail.com>
Message-ID: <4BD604BF.7010606@ipinc.net>


Yes.

But this doesn't matter because the general public does not purchase
IP addressing from ARIN and thus has no dog in this hunt.

The ISPs do.  And ARIN is plenty transparent to them.

Ted

On 4/25/2010 8:22 AM, IPv3.com wrote:
> Is ARIN (The Business) Too Opaque for the Public to Participate ?
>
> 1. ARIN.NET started as a "steward" of some /8s for small IPv4 ISPs.
>
> 2. Large Carriers (ISPs) do not use ARIN or RIR services.?
> http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
>
> 3. Some ARIN /8 Assets are claimed to be owned and some inherited ?
> http://mailman.nanog.org/pipermail/nanog/2010-April/021142.html
>
> 4. ARIN.COM was secretly purchased when 4-Letter .COM domains became
> useful for FREE unique Address Space pre-Fixing. LL:LLL:L:LLLL:X ?
>
> 5. ARIN is now in Las Vegas on your nickel? If this was the DMV would
> they travel around on the public's nickel?
>
> 6. ARIN Directors and Executives resign or decide not to work there
> and no explanation is provided.?
>
> 7. ARIN appears to be focused on the IPv6 market with swag, wikis, etc.?
>
> 8. ARIN Executives have recently entered the IPv6 Software business?
> as a supplier for a major cable company?
>
> 9. ARIN claims to provide "unique-ness" service but WHOIS appears to
> be the prime focus.
> [Aside: there are many much lower cost ways to ensure uniqueness,
> especially as address spaces expand from 32 to 480 bits.]
>
> 10 People assume ARIN is part of ICANN and that web-site shows a
> Subsidiary Business Relationship. Some claim there are no ICANN?ARIN
> "Contracts". http://bit.ly/8Ylh1e
>
> Is ARIN (The Business) Too Opaque for the Public to Participate ?
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>


From christopher.morrow at gmail.com  Mon Apr 26 17:41:56 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Mon, 26 Apr 2010 17:41:56 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <8695009A81378E48879980039EEDAD2889A5B78B@MAIL1.polartel.local>
References: <10727C0F12264762A332829ED3A8E51C@changeip.com>
	<4BD5C8E6.4020506@ipinc.net>
	<1272302900.13180.25.camel@ggiesen-workstation.netsurf.net>
	<8695009A81378E48879980039EEDAD2889A5B786@MAIL1.polartel.local>
	<v2g75cb24521004261159r63527c50i904b43ed220f0ee7@mail.gmail.com>
	<8695009A81378E48879980039EEDAD2889A5B78B@MAIL1.polartel.local>
Message-ID: <i2g75cb24521004261441rf408c960zd070647eed90f7fe@mail.gmail.com>

On Mon, Apr 26, 2010 at 3:58 PM, Kevin Kargel <kkargel at polartel.com> wrote:
> And how does that make $1200 trivial?
>
> Are you saying that anything having to do with a new employee is trivial?
>
> Are you suggesting that all companies are buying computers for employees on a whim? ?You must work in a different world than I do. ?Employees here certainly don't get a new computer every year.
>
> Most people I know need a little mor justification to get a new computer than "I want one."

no, but certainly a new employee at an IP Transit company needs some
form of compute resources to do their job. it's likely the case that
more than 1 new employee is hired each year. my point here is that if
you can afford new compute resources for a new employee it seems that
1200$ to keep the business going is within reach.

-chris

>
> Kevin
>
>
>
>> -----Original Message-----
>> From: Christopher Morrow [mailto:christopher.morrow at gmail.com]
>> Sent: Monday, April 26, 2010 2:00 PM
>> To: Kevin Kargel
>> Cc: Gary T. Giesen; Ted Mittelstaedt; arin-ppml at arin.net
>> Subject: Re: [arin-ppml] IPv6 /32 minimum for extra-small ISP
>>
>> On Mon, Apr 26, 2010 at 1:49 PM, Kevin Kargel <kkargel at polartel.com>
>> wrote:
>> >>
>> > $1200 may be insignificant or trivial in your world.
>> >
>> > In the world of a small independent telco offering IP to it's customers
>> a $1200 recurring expense is neither insignificant nor trivial.
>>
>> just so we understand new ops employees then buy their own compute
>> resources to do their job? (1200$ is about a desktop/laptop price
>> including support and monitor and such)
>>
>> -chris
>


From kkargel at polartel.com  Mon Apr 26 18:10:37 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 26 Apr 2010 17:10:37 -0500
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <i2g75cb24521004261441rf408c960zd070647eed90f7fe@mail.gmail.com>
References: <10727C0F12264762A332829ED3A8E51C@changeip.com>
	<4BD5C8E6.4020506@ipinc.net>
	<1272302900.13180.25.camel@ggiesen-workstation.netsurf.net>
	<8695009A81378E48879980039EEDAD2889A5B786@MAIL1.polartel.local>
	<v2g75cb24521004261159r63527c50i904b43ed220f0ee7@mail.gmail.com>
	<8695009A81378E48879980039EEDAD2889A5B78B@MAIL1.polartel.local>
	<i2g75cb24521004261441rf408c960zd070647eed90f7fe@mail.gmail.com>
Message-ID: <8695009A81378E48879980039EEDAD2889A5B78D@MAIL1.polartel.local>



 
> no, but certainly a new employee at an IP Transit company needs some
> form of compute resources to do their job. it's likely the case that
> more than 1 new employee is hired each year. my point here is that if
> you can afford new compute resources for a new employee it seems that
> 1200$ to keep the business going is within reach.
> 
> -chris
> 

Like I said, some companies are avoiding new computer purchases to keep costs down.  It is not unheard of for a new employee to start out with hand-me-down equipment.  The economy is not like it used to be, and we don't all work at f500 level enterprises.  

Let's try and avoid making it harder on the small (or would you call them micro) operations just because it is easy for the huge enterprises to come up with trivial $1000 budget items.

I am not saying it is like that where I work, but I am saying there are operations out there where it is like that.  

Kevin


From tedm at ipinc.net  Mon Apr 26 18:12:01 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 26 Apr 2010 15:12:01 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <i2g75cb24521004261441rf408c960zd070647eed90f7fe@mail.gmail.com>
References: <10727C0F12264762A332829ED3A8E51C@changeip.com>	<4BD5C8E6.4020506@ipinc.net>	<1272302900.13180.25.camel@ggiesen-workstation.netsurf.net>	<8695009A81378E48879980039EEDAD2889A5B786@MAIL1.polartel.local>	<v2g75cb24521004261159r63527c50i904b43ed220f0ee7@mail.gmail.com>	<8695009A81378E48879980039EEDAD2889A5B78B@MAIL1.polartel.local>
	<i2g75cb24521004261441rf408c960zd070647eed90f7fe@mail.gmail.com>
Message-ID: <4BD60FB1.3090700@ipinc.net>



On 4/26/2010 2:41 PM, Christopher Morrow wrote:
> On Mon, Apr 26, 2010 at 3:58 PM, Kevin Kargel<kkargel at polartel.com>  wrote:
>> And how does that make $1200 trivial?
>>
>> Are you saying that anything having to do with a new employee is trivial?
>>
>> Are you suggesting that all companies are buying computers for employees on a whim?  You must work in a different world than I do.  Employees here certainly don't get a new computer every year.
>>
>> Most people I know need a little mor justification to get a new computer than "I want one."
>
> no, but certainly a new employee at an IP Transit company needs some
> form of compute resources to do their job. it's likely the case that
> more than 1 new employee is hired each year. my point here is that if
> you can afford new compute resources for a new employee it seems that
> 1200$ to keep the business going is within reach.
>

Just to interject a bit here,

You need a certain number of employees to start an ISP  (assuming
your starting small)  Let's say, 3 full time.  Your going to
need that number whether you have 1 customer or an IPv4 /24's
worth of customers or a /21's worth of customers, and your
going to need to spend that $3600 on their PC gear.

As it grows from a starting point of 1 customer you can manage the 
customer load with that number of employees until it reaches a critical 
level, then you hire another employee.

I would submit that the "knee" point that the small ISP is
forced to hire another warm body is above the level that this
ISP needs an IPv4 /20 where in which case it's fee will be $2250
for both IPv4 and IPv6 resources.

Thus I feel this analogy and discussion is pointless.  The
extra-small ISP's which are considered extra-small for IPv4
purposes, are not large companies.  They have to spend the
$3600 for employee hardware to even open their doors - this is a
mandatory cost whether they have IPv4 only, or IPv6 only or
both.  An extra $1200 to do both IPv4 and IPv6 is really
significant to them.  They are in the region that they can only
dream about adding another employee than what they have to
have as minimum to keep their doors open.


Ted


> -chris
>
>>
>> Kevin
>>
>>
>>
>>> -----Original Message-----
>>> From: Christopher Morrow [mailto:christopher.morrow at gmail.com]
>>> Sent: Monday, April 26, 2010 2:00 PM
>>> To: Kevin Kargel
>>> Cc: Gary T. Giesen; Ted Mittelstaedt; arin-ppml at arin.net
>>> Subject: Re: [arin-ppml] IPv6 /32 minimum for extra-small ISP
>>>
>>> On Mon, Apr 26, 2010 at 1:49 PM, Kevin Kargel<kkargel at polartel.com>
>>> wrote:
>>>>>
>>>> $1200 may be insignificant or trivial in your world.
>>>>
>>>> In the world of a small independent telco offering IP to it's customers
>>> a $1200 recurring expense is neither insignificant nor trivial.
>>>
>>> just so we understand new ops employees then buy their own compute
>>> resources to do their job? (1200$ is about a desktop/laptop price
>>> including support and monitor and such)
>>>
>>> -chris
>>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>


From owen at delong.com  Mon Apr 26 20:10:01 2010
From: owen at delong.com (Owen DeLong)
Date: Mon, 26 Apr 2010 17:10:01 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <4BD5C8E6.4020506@ipinc.net>
References: <10727C0F12264762A332829ED3A8E51C@changeip.com>
	<4BD5C8E6.4020506@ipinc.net>
Message-ID: <3CEC5E34-A72A-415C-BEAA-61C0CBADBA5E@delong.com>

OK... Here's the actual information...

If you are currently an IPv4 x-small ISP subscriber, you are already paying $1,250/year.
As such, your incremental cost when you obtain a /32 for IPv6 would be an additional $1,000/year.

If you are a brand new IPv6-only ISP, your annual cost would be $2,250/year.

So, the $2,250 number is sort of correct, but, ignores that you are already paying
most of that.  I think the $1,250 figure is a math error vs. $2,250 - $1,250 = $1,000.

Hope that clears things up.

Owen

On Apr 26, 2010, at 10:09 AM, Ted Mittelstaedt wrote:

> 
> Interesting how costs have been bandied about, a few days ago
> it was $2250 now it's $1250.
> 
> Please tell me the name of an employer where any employee who
> is NOT a salesman can go to his or her boss and say "Can I go spend a thousand bucks on something that has no justification for existence other than we might need it sometime in the future?"
> 
> 
> Ted
> 
> 
> On 4/26/2010 8:27 AM, NOC at ChangeIP.com wrote:
>> ----- Original Message ----- From: "Gary Giesen" <ggiesen at akn.ca>
>>> An IPv6 /32 also doesn't cost anything if you have a /20 or larger v4
>>> allocation. If you have an X-Small (smaller than /20), it's only an extra
>>> $1250/year. Pretty small potatoes. By the time you *need* IPv6, it
>>> will just
>>> be the cost of doing business, and will be pretty easy to justify it
>>> (pretty
>>> hard to be an ISP without it).
>>> 
>> 
>> Read that again and think about how we really want people to adopt IPv6. Do
>> you want someone to start using it NOW because it's free, or when its too
>> late because it cost $1250/yr extra and wasn't viable because they are
>> almost going out of business as it is?
>> 
>> How much of the IPv4 space is taken by x-small at the moment? Do you really
>> want to delay that group from adopting ipv6? Sheesh!
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From matthew at matthew.at  Mon Apr 26 20:19:27 2010
From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 26 Apr 2010 17:19:27 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <3CEC5E34-A72A-415C-BEAA-61C0CBADBA5E@delong.com>
References: <10727C0F12264762A332829ED3A8E51C@changeip.com>	<4BD5C8E6.4020506@ipinc.net>
	<3CEC5E34-A72A-415C-BEAA-61C0CBADBA5E@delong.com>
Message-ID: <4BD62D8F.9050700@matthew.at>

Owen DeLong wrote:
> OK... Here's the actual information...
>
> If you are currently an IPv4 x-small ISP subscriber, you are already paying $1,250/year.
> As such, your incremental cost when you obtain a /32 for IPv6 would be an additional $1,000/year.
>
> If you are a brand new IPv6-only ISP, your annual cost would be $2,250/year.
>
> So, the $2,250 number is sort of correct, but, ignores that you are already paying
> most of that.  I think the $1,250 figure is a math error vs. $2,250 - $1,250 = $1,000.
>
> Hope that clears things up.
>
> Owen
>   
And if I'm currently an IPv4 x-small ISP using legacy pre-ARIN IPv4 
space, it is also $2250/year more than I pay now. Plus maybe having to 
sign the legacy RSA, if I'm not careful to keep my IPv4 and IPv6 
entities sufficiently separate.

Correct me if I'm wrong.

Matthew Kaufman


From owen at delong.com  Mon Apr 26 20:50:36 2010
From: owen at delong.com (Owen DeLong)
Date: Mon, 26 Apr 2010 17:50:36 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <4BD5FBA7.4030004@ipinc.net>
References: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA64F@Skyhawk>
	<4BD5FBA7.4030004@ipinc.net>
Message-ID: <3060678D-CC92-42FB-BF77-024E5A0C6D74@delong.com>


On Apr 26, 2010, at 1:46 PM, Ted Mittelstaedt wrote:

> 
> 
> On 4/26/2010 11:39 AM, Chris Engel wrote:
>> 
>> Ted Mittelstaedt wrote:
>> 
>>> Interesting how costs have been bandied about, a few days ago it
>>> was $2250 now it's $1250.
>>> 
>>> Please tell me the name of an employer where any employee who is
>>> NOT a salesman can go to his or her boss and say "Can I go spend a
>>> thousand bucks on something that has no justification for
>>> existence other than we might need it sometime in the future?"
>> 
>> 
>> Ted,
>> 
>> I think you basicaly described most types of insurance that
>> businesses carry.
> 
> That isn't a good analogy.
> 
> The proper analogous statement would be the employee who told their boss they needed to spend a thousand bucks on something that has no justification for existence other than we might need it sometime in the future, OTHERWISE if we didn't send the money we could be sued if we
> did need it.
> 
> That's the difference between buying insurance and buying IPV6
> in a nutshell - at the current time, of course.
> 
Ted,

We can agree to disagree about this, but, frankly, I think that
the insurance analogy is spot on.

If you deploy IPv6, then, you have insured that your operations
can continue in a world where there are IPv6-only hosts trying
to reach your services or where your clients are trying to reach
IPv6-only services.  If you do not deploy IPv6, then, you are taking
significant risks that your business continuity on the internet may
be interrupted in a post IPv4-depletion scenario.

Since the reason most businesses purchase insurance is to be
able to ensure their business continuity in the face of a sudden
change (fire, flood, etc.), I think that deploying IPv6 to ensure
continued business on the internet after IPv4 depletion is a
very similar cost justification.

>> I can't speak for  ISP's but in the Enterprise
>> world 1-2K isn't going to even be a blip on the radar screen as far
>> as the real costs of IPv6 (assuming an Enterprise would even go
>> through ARIN rather then thier ISP for space).
> 
> Right, of course the debate wouldn't affect Enterprises anyway
> because they aren't minimal users of IPv4.  (we would assume)
> 
For most enterprises, the IPv6 cost would be a one-time initial
fee of $1,250 and they would then pay $100/year thereafter,
which, if they had direct IPv4 resources or an ASN would be
the same $100/year they are already paying.

>> The real costs will
>> come in man-hours of planning, deployment, training, support and
>> skill building, HW/SW compatability issues, compliance issues, lost
>> business and broken applications. As far as costs...those are the
>> real killers for IPv6 (IMO).
>> 
> 
> Looking at IPv6 from a purely financial perspective what the
> enterprise is ultimately going to come up against is that you
> are definitely going to lose customers if you have no IP to
> give them, and you may lose customers if you have IP to give
> them but it's only IPv6.
> 
By enterprise above, I assume from context you mean end-users
as was described earlier.

End users shouldn't be giving IP addresses to their customers,
so, the above paragraph doesn't make sense to me.  If you mean
ISPs rather than End users, then, the above paragraph sort of
makes sense, but, it's unclear to me how you expect to continue
to have IPv4 addresses to give customers throughout 2012,
or, especially beyond that date.

> And of course since the actual IPv4 "runout" is going to vary
> from company to company, the companies with the most money
> who can afford to buy IPv4 off the transfer market, will have
> a competitive advantage - as long as the transfer market can
> continue to fill IPv4 orders.
> 
Perhaps, perhaps not.  I expect one of two things will happen with
the alleged transfer market...

1.	There will be little to no supply available at any price, or, it
	will be at such extremely high prices that there will be very
	few who can afford to buy it.  In this case, competitive advantage
	is only an advantage if you can make enough money off of
	your subscribers to cover the high cost of address acquisition.

or

2.	The address transfer market will be vibrant, indeed, and the
	IPv4 routing table will rapidly grow to a completely unworkable
	size causing fragmentation, discontinuity, and damage to the
	IPv4 internet, inevitably leading to the rapid deployment of
	IPv6 just for the sake of restoring global reachability.

In either case, what is likely to happen is that the IPv4 transfer
market will create strong financial and/or technical incentives
to move to increase the speed of a move towards IPv6.

Owen
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100426/8baa1a9b/attachment.htm>

From steve at ipv6canada.com  Mon Apr 26 21:01:18 2010
From: steve at ipv6canada.com (Steve Bertrand)
Date: Mon, 26 Apr 2010 21:01:18 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <3060678D-CC92-42FB-BF77-024E5A0C6D74@delong.com>
References: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA64F@Skyhawk>	<4BD5FBA7.4030004@ipinc.net>
	<3060678D-CC92-42FB-BF77-024E5A0C6D74@delong.com>
Message-ID: <4BD6375E.3090707@ipv6canada.com>

On 2010.04.26 20:50, Owen DeLong wrote:
> 
> On Apr 26, 2010, at 1:46 PM, Ted Mittelstaedt wrote:

>> On 4/26/2010 11:39 AM, Chris Engel wrote:
>>>
>>> Ted Mittelstaedt wrote:
>>>
>>>> Interesting how costs have been bandied about, a few days ago it
>>>> was $2250 now it's $1250.
>>>>
>>>> Please tell me the name of an employer where any employee who is
>>>> NOT a salesman can go to his or her boss and say "Can I go spend a
>>>> thousand bucks on something that has no justification for
>>>> existence other than we might need it sometime in the future?"

>>> I think you basicaly described most types of insurance that
>>> businesses carry.
>>
>> That isn't a good analogy.

> We can agree to disagree about this, 

It was once mentioned to me (I forget by who) that if you agree to
disagree, someone is always going to be disrespected.

> but, frankly, I think that
> the insurance analogy is spot on.

So do I.

Steve


From owen at delong.com  Mon Apr 26 21:00:43 2010
From: owen at delong.com (Owen DeLong)
Date: Mon, 26 Apr 2010 18:00:43 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <4BD62D8F.9050700@matthew.at>
References: <10727C0F12264762A332829ED3A8E51C@changeip.com>	<4BD5C8E6.4020506@ipinc.net>
	<3CEC5E34-A72A-415C-BEAA-61C0CBADBA5E@delong.com>
	<4BD62D8F.9050700@matthew.at>
Message-ID: <19EDA9D4-AACF-4CAC-93E4-2F310D76F1B4@delong.com>


On Apr 26, 2010, at 5:19 PM, Matthew Kaufman wrote:

> Owen DeLong wrote:
>> OK... Here's the actual information...
>> 
>> If you are currently an IPv4 x-small ISP subscriber, you are already paying $1,250/year.
>> As such, your incremental cost when you obtain a /32 for IPv6 would be an additional $1,000/year.
>> 
>> If you are a brand new IPv6-only ISP, your annual cost would be $2,250/year.
>> 
>> So, the $2,250 number is sort of correct, but, ignores that you are already paying
>> most of that.  I think the $1,250 figure is a math error vs. $2,250 - $1,250 = $1,000.
>> 
>> Hope that clears things up.
>> 
>> Owen
>>  
> And if I'm currently an IPv4 x-small ISP using legacy pre-ARIN IPv4 space, it is also $2250/year more than I pay now. Plus maybe having to sign the legacy RSA, if I'm not careful to keep my IPv4 and IPv6 entities sufficiently separate.
> 
> Correct me if I'm wrong.
> 
> Matthew Kaufman

If you can qualify independent of your legacy IPv4 usage, then, you don't need to
sign any RSA with regard to your IPv4 addresses to get IPv6, so, to at least that
extent, you are wrong.

However, you are also gambling with your IPv4 future in my opinion.

Owen



From steve at ipv6canada.com  Mon Apr 26 21:24:51 2010
From: steve at ipv6canada.com (Steve Bertrand)
Date: Mon, 26 Apr 2010 21:24:51 -0400
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <4BD62D8F.9050700@matthew.at>
References: <10727C0F12264762A332829ED3A8E51C@changeip.com>	<4BD5C8E6.4020506@ipinc.net>	<3CEC5E34-A72A-415C-BEAA-61C0CBADBA5E@delong.com>
	<4BD62D8F.9050700@matthew.at>
Message-ID: <4BD63CE3.1010508@ipv6canada.com>

On 2010.04.26 20:19, Matthew Kaufman wrote:
> Owen DeLong wrote:
>> OK... Here's the actual information...
>>
>> If you are currently an IPv4 x-small ISP subscriber, you are already
>> paying $1,250/year.
>> As such, your incremental cost when you obtain a /32 for IPv6 would be
>> an additional $1,000/year.
>>
>> If you are a brand new IPv6-only ISP, your annual cost would be
>> $2,250/year.
>>
>> So, the $2,250 number is sort of correct, but, ignores that you are
>> already paying
>> most of that.  I think the $1,250 figure is a math error vs. $2,250 -
>> $1,250 = $1,000.
>>
>> Hope that clears things up.
>>
>> Owen
>>   
> And if I'm currently an IPv4 x-small ISP using legacy pre-ARIN IPv4
> space, it is also $2250/year more than I pay now. Plus maybe having to
> sign the legacy RSA, if I'm not careful to keep my IPv4 and IPv6
> entities sufficiently separate.

At the ARIN meeting, I spoke to a few people who have signed the LRSA,
so I'd like to focus on that side of your comment (Matthew, I'm not
being judgmental on what you have said, nor do I have an opinion on it).

Just for informative purposes, would someone who has signed the LRSA
speak up with any regrets they may have had by signing the agreement?

otoh, I'd be interested to learn of benefits you have gained by not
having to "keep" ... "IPv4 and IPv6 entities sufficiently separate"?

Steve


From bill at herrin.us  Mon Apr 26 21:34:04 2010
From: bill at herrin.us (William Herrin)
Date: Mon, 26 Apr 2010 15:34:04 -1000
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <3060678D-CC92-42FB-BF77-024E5A0C6D74@delong.com>
References: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA64F@Skyhawk> 
	<4BD5FBA7.4030004@ipinc.net>
	<3060678D-CC92-42FB-BF77-024E5A0C6D74@delong.com>
Message-ID: <j2y3c3e3fca1004261834g5dfe2f5ct3b3e98a05a486e43@mail.gmail.com>

On Mon, Apr 26, 2010 at 2:50 PM, Owen DeLong <owen at delong.com> wrote:
> We can agree to disagree about this, but, frankly, I think that
> the insurance analogy is spot on.

Then you'll understand when I tell you that the actuarial tables
describing the risk to my system suggest that your IPv6 insurance is
jaw-droppingly overpriced. We're talkin' Louis Vuitton is a pauper
overpriced.

Purely from an insurance perspective, of course. There are other
analogies that don't leave IPv6 quite so wanting.

Regards,
Bill

-- 
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 bill at herrin.us  Mon Apr 26 22:41:22 2010
From: bill at herrin.us (William Herrin)
Date: Mon, 26 Apr 2010 16:41:22 -1000
Subject: [arin-ppml] IPv6 Guarantee
Message-ID: <i2g3c3e3fca1004261941w82c6696eka6e38d486a683175@mail.gmail.com>

All this rubbish about IPv6 as insurance popped an idea into my head:

The IPv6 guarantee:
20% or it's free

Every January 1, ARIN will determine whether at least 20% of typical
residential packets on ARIN-territory Internet connections are carried
via IPv6, as reported by scientifically defensible studies. If not,
all registrants who both hold IPv6 registrations and route the
registered address blocks on the public Internet will receive a full
refund of any registration, maintenance or other ARIN fees incurred in
the prior year solely as a consequence of the IPv6 registration.


Do we -really- believe in IPv6? Lets prove it.

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 rsm at fast-serv.com  Tue Apr 27 00:05:29 2010
From: rsm at fast-serv.com (Randy McAnally)
Date: Tue, 27 Apr 2010 00:05:29 -0400
Subject: [arin-ppml] IPv6 Guarantee
In-Reply-To: <i2g3c3e3fca1004261941w82c6696eka6e38d486a683175@mail.gmail.com>
References: <i2g3c3e3fca1004261941w82c6696eka6e38d486a683175@mail.gmail.com>
Message-ID: <20100427040450.M88087@fast-serv.com>

From: William Herrin <bill at herrin.us>

> All this rubbish about IPv6 as insurance popped an idea into my head:
> 
> The IPv6 guarantee:
> 20% or it's free
> 
> Every January 1, ARIN will determine whether at least 20% of typical
> residential packets on ARIN-territory Internet connections are 
> carried via IPv6, as reported by scientifically defensible studies. 
> If not, all registrants who both hold IPv6 registrations and route 
> the registered address blocks on the public Internet will receive a full
> refund of any registration, maintenance or other ARIN fees incurred 
> in the prior year solely as a consequence of the IPv6 registration.
> 
> Do we -really- believe in IPv6? Lets prove it.

I like this.



From ggiesen at akn.ca  Tue Apr 27 00:38:13 2010
From: ggiesen at akn.ca (Gary Giesen)
Date: Tue, 27 Apr 2010 00:38:13 -0400
Subject: [arin-ppml] IPv6 Guarantee
In-Reply-To: <20100427040450.M88087@fast-serv.com>
Message-ID: <C7FBE275.9695%ggiesen@akn.ca>

This is little more than a bit of fun. The reality is the vast majority of
people with IPv6 already get it for free, because it's included in the price
of their IPv4 allocations/assignments.

GG


On 10-04-27 12:05 AM, "Randy McAnally" <rsm at fast-serv.com> wrote:

> From: William Herrin <bill at herrin.us>
> 
>> All this rubbish about IPv6 as insurance popped an idea into my head:
>> 
>> The IPv6 guarantee:
>> 20% or it's free
>> 
>> Every January 1, ARIN will determine whether at least 20% of typical
>> residential packets on ARIN-territory Internet connections are
>> carried via IPv6, as reported by scientifically defensible studies.
>> If not, all registrants who both hold IPv6 registrations and route
>> the registered address blocks on the public Internet will receive a full
>> refund of any registration, maintenance or other ARIN fees incurred
>> in the prior year solely as a consequence of the IPv6 registration.
>> 
>> Do we -really- believe in IPv6? Lets prove it.
> 
> I like this.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From mysidia at gmail.com  Tue Apr 27 02:35:58 2010
From: mysidia at gmail.com (James Hess)
Date: Tue, 27 Apr 2010 01:35:58 -0500
Subject: [arin-ppml] IPv6 Guarantee
In-Reply-To: <i2g3c3e3fca1004261941w82c6696eka6e38d486a683175@mail.gmail.com>
References: <i2g3c3e3fca1004261941w82c6696eka6e38d486a683175@mail.gmail.com>
Message-ID: <z2r6eb799ab1004262335yac6a2550i23b9c445492e76df@mail.gmail.com>

Well, a few things...   (a) How do we measure the 20%?
How can ARIN assure the would-be IPv6 applicant that a study will be done?

Perhaps more importantly...  will ARIN be able to afford it  if the
bet goes wrong?
Isn't the per-reg price of an IPv6 registration connected to ARIN's
costs of creating and  maintaining each registration?


And (b)...  does tunneled traffic count,  then where does packet count
get measured?   For example, end hosts sending IPv6 packets  that get
encapsujlated in IPv4 packets  and received by ISP as IPv4 packets,
that are then transmitted to a tunnel endpoint for de-encapsulation.

Do those count towards the number of IPv6 packets or towards the
number of IPv4 packets,  and  can we  expect a study to be able to
identify/distinguish them

IOW -- what type of packets does the study have to say there are 20% of...
native end-to-end V6,   or    packets that are V6   at any point
during their travel.
;)


On Mon, Apr 26, 2010 at 9:41 PM, William Herrin <bill at herrin.us> wrote:
> All this rubbish about IPv6 as insurance popped an idea into my head:
>
> The IPv6 guarantee:
> 20% or it's free
>
> Every January 1, ARIN will determine whether at least 20% of typical
> residential packets on ARIN-territory Internet connections are carried
> via IPv6, as reported by scientifically defensible studies. If not,
> all registrants who both hold IPv6 registrations and route the
> registered address blocks on the public Internet will receive a full
> refund of any registration, maintenance or other ARIN fees incurred in
> the prior year solely as a consequence of the IPv6 registration.
>
>
> Do we -really- believe in IPv6? Lets prove it.
>
> Regards,
> Bill Herrin


--
-J


From owen at delong.com  Tue Apr 27 02:51:06 2010
From: owen at delong.com (Owen DeLong)
Date: Mon, 26 Apr 2010 23:51:06 -0700
Subject: [arin-ppml] IPv6 /32 minimum for extra-small ISP
In-Reply-To: <4BD63CE3.1010508@ipv6canada.com>
References: <10727C0F12264762A332829ED3A8E51C@changeip.com>	<4BD5C8E6.4020506@ipinc.net>	<3CEC5E34-A72A-415C-BEAA-61C0CBADBA5E@delong.com>
	<4BD62D8F.9050700@matthew.at> <4BD63CE3.1010508@ipv6canada.com>
Message-ID: <D6D982B1-B859-4218-9C3C-467CA325EC1E@delong.com>


On Apr 26, 2010, at 6:24 PM, Steve Bertrand wrote:

> On 2010.04.26 20:19, Matthew Kaufman wrote:
>> Owen DeLong wrote:
>>> OK... Here's the actual information...
>>> 
>>> If you are currently an IPv4 x-small ISP subscriber, you are already
>>> paying $1,250/year.
>>> As such, your incremental cost when you obtain a /32 for IPv6 would be
>>> an additional $1,000/year.
>>> 
>>> If you are a brand new IPv6-only ISP, your annual cost would be
>>> $2,250/year.
>>> 
>>> So, the $2,250 number is sort of correct, but, ignores that you are
>>> already paying
>>> most of that.  I think the $1,250 figure is a math error vs. $2,250 -
>>> $1,250 = $1,000.
>>> 
>>> Hope that clears things up.
>>> 
>>> Owen
>>> 
>> And if I'm currently an IPv4 x-small ISP using legacy pre-ARIN IPv4
>> space, it is also $2250/year more than I pay now. Plus maybe having to
>> sign the legacy RSA, if I'm not careful to keep my IPv4 and IPv6
>> entities sufficiently separate.
> 
> At the ARIN meeting, I spoke to a few people who have signed the LRSA,
> so I'd like to focus on that side of your comment (Matthew, I'm not
> being judgmental on what you have said, nor do I have an opinion on it).
> 
> Just for informative purposes, would someone who has signed the LRSA
> speak up with any regrets they may have had by signing the agreement?
> 
I signed the LRSA.

I have no regrets.

Admittedly, I expected to be paying $100/year for my IPv6 resources anyway,
so, it didn't make any difference cost-wise and there weren't really any other
reasons in my opinion to avoid the LRSA.

The LRSA locks in most of my rights and assures me in writing that ARIN will
honor them, whereas without such, it's unclear ARIN had any obligation whatsoever
to respect my use of my legacy addresses or preserve any records of their
registration whatsoever.

> otoh, I'd be interested to learn of benefits you have gained by not
> having to "keep" ... "IPv4 and IPv6 entities sufficiently separate"?
> 
I'm just running native dual-stack on all of my capable devices while a few
more limited devices (TiVOs, Yamaha Amp, and some HP Printers)
remain IPv4-only for the time being.

In terms of ARIN, I get one invoice per year, I pay it, and all is well.

It's really quite simple.

Owen



From owen at delong.com  Tue Apr 27 03:10:29 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 27 Apr 2010 00:10:29 -0700
Subject: [arin-ppml] IPv6 Guarantee
In-Reply-To: <z2r6eb799ab1004262335yac6a2550i23b9c445492e76df@mail.gmail.com>
References: <i2g3c3e3fca1004261941w82c6696eka6e38d486a683175@mail.gmail.com>
	<z2r6eb799ab1004262335yac6a2550i23b9c445492e76df@mail.gmail.com>
Message-ID: <9A9551D1-FD69-4614-BCAA-87C291737387@delong.com>


On Apr 26, 2010, at 11:35 PM, James Hess wrote:

> Well, a few things...   (a) How do we measure the 20%?
> How can ARIN assure the would-be IPv6 applicant that a study will be done?
> 
I've got a couple of ideas on how this might be accomplished.  I know a network
that is in a pretty good position to take a representative sample of the current
IPv6 traffic load. ;-)  I'm investigating whether we'd be able to easily produce
these statistics or not.  The trick is identifying the residential traffic.

> Perhaps more importantly...  will ARIN be able to afford it  if the
> bet goes wrong?
> Isn't the per-reg price of an IPv6 registration connected to ARIN's
> costs of creating and  maintaining each registration?
> 
I think this would be a waiver of the annual fees (which presumably
people would end up still paying their IPv4 fees, so, it wouldn't likely
have a significant financial impact to ARIN).
> 
> And (b)...  does tunneled traffic count,  then where does packet count
> get measured?   For example, end hosts sending IPv6 packets  that get
> encapsujlated in IPv4 packets  and received by ISP as IPv4 packets,
> that are then transmitted to a tunnel endpoint for de-encapsulation.
> 
Tunneled packets will appear as IPv6 on the native IPv6 backbones.
They're only IPv4 from one end of the tunnel to the other.  Certainly,
I think they should count whether tunneled or not. Measurement should
be conducted from one or more points with native IPv6.

> Do those count towards the number of IPv6 packets or towards the
> number of IPv4 packets,  and  can we  expect a study to be able to
> identify/distinguish them
> 
They should only be counted once.  A v6 packet inside a v4 packet
should, IMHO, be counted as a v6 packet.

> IOW -- what type of packets does the study have to say there are 20% of...
> native end-to-end V6,   or    packets that are V6   at any point
> during their travel.
> ;)
> 
Packets where the destination and origin for the actual (innermost) payload
are IPv6 should count as IPv6. Packets where the destination and origin of
the actual (innermost) payload are IPv4 should count as IPv4.

The harder part is identifying residential packets vs. others.

Owen

> 
> On Mon, Apr 26, 2010 at 9:41 PM, William Herrin <bill at herrin.us> wrote:
>> All this rubbish about IPv6 as insurance popped an idea into my head:
>> 
>> The IPv6 guarantee:
>> 20% or it's free
>> 
>> Every January 1, ARIN will determine whether at least 20% of typical
>> residential packets on ARIN-territory Internet connections are carried
>> via IPv6, as reported by scientifically defensible studies. If not,
>> all registrants who both hold IPv6 registrations and route the
>> registered address blocks on the public Internet will receive a full
>> refund of any registration, maintenance or other ARIN fees incurred in
>> the prior year solely as a consequence of the IPv6 registration.
>> 
>> 
>> Do we -really- believe in IPv6? Lets prove it.
>> 
>> Regards,
>> Bill Herrin
> 
> 
> --
> -J
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From bill at herrin.us  Tue Apr 27 11:01:00 2010
From: bill at herrin.us (William Herrin)
Date: Tue, 27 Apr 2010 05:01:00 -1000
Subject: [arin-ppml] IPv6 Guarantee
In-Reply-To: <z2r6eb799ab1004262335yac6a2550i23b9c445492e76df@mail.gmail.com>
References: <i2g3c3e3fca1004261941w82c6696eka6e38d486a683175@mail.gmail.com> 
	<z2r6eb799ab1004262335yac6a2550i23b9c445492e76df@mail.gmail.com>
Message-ID: <i2o3c3e3fca1004270801u397d5fc6ne24cbc7c9f8b6bdc@mail.gmail.com>

On Mon, Apr 26, 2010 at 8:35 PM, James Hess <mysidia at gmail.com> wrote:
> Well, a few things... ? (a) How do we measure the 20%?

By the time it's anywhere near 20%, comScore will almost certainly be
measuring and reporting it. Their business is all about figuring out
any significant activity the personal end user is doing. Their methods
are sound and they're not the only commercial net metrics company
who'll be watching.

Regards,
Bill



-- 
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 spiffnolee at yahoo.com  Tue Apr 27 11:11:14 2010
From: spiffnolee at yahoo.com (Lee Howard)
Date: Tue, 27 Apr 2010 08:11:14 -0700 (PDT)
Subject: [arin-ppml] IPv6 Guarantee
In-Reply-To: <i2g3c3e3fca1004261941w82c6696eka6e38d486a683175@mail.gmail.com>
References: <i2g3c3e3fca1004261941w82c6696eka6e38d486a683175@mail.gmail.com>
Message-ID: <709763.41775.qm@web63308.mail.re1.yahoo.com>

----- Original Message ----

> From: William Herrin <bill at herrin.us>
> To: arin-ppml at arin.net
> Sent: Mon, April 26, 2010 10:41:22 PM
> Subject: [arin-ppml] IPv6 Guarantee
> 
> The IPv6 guarantee:  20% or it's free

Interesting idea.  I like it for its novelty.  Don't know if I 
would actually support it yet.
Does that disincentivize IPv6 deployment--if it happens, then
fees go up?

> Every January 1, ARIN will determine 
> whether at least 20% of typical
> residential packets on ARIN-territory 
> Internet connections are carried
> via IPv6, as reported by scientifically 
> defensible studies. If not,
> all registrants who both hold IPv6 registrations 
> and route the
> registered address blocks on the public Internet will receive a 
> full refund of any registration, maintenance or other ARIN fees incurred 
> in the prior year solely as a consequence of the IPv6 
> registration.

I would assume we would use the ASCP Consultation Process
to solicit proposals for studies.  

Lee



      


From owen at delong.com  Tue Apr 27 12:15:29 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 27 Apr 2010 09:15:29 -0700
Subject: [arin-ppml] IPv6 Guarantee
In-Reply-To: <709763.41775.qm@web63308.mail.re1.yahoo.com>
References: <i2g3c3e3fca1004261941w82c6696eka6e38d486a683175@mail.gmail.com>
	<709763.41775.qm@web63308.mail.re1.yahoo.com>
Message-ID: <AA9E3082-9509-4955-B79E-C167AF0123ED@delong.com>


On Apr 27, 2010, at 8:11 AM, Lee Howard wrote:

> ----- Original Message ----
> 
>> From: William Herrin <bill at herrin.us>
>> To: arin-ppml at arin.net
>> Sent: Mon, April 26, 2010 10:41:22 PM
>> Subject: [arin-ppml] IPv6 Guarantee
>> 
>> The IPv6 guarantee:  20% or it's free
> 
> Interesting idea.  I like it for its novelty.  Don't know if I 
> would actually support it yet.
> Does that disincentivize IPv6 deployment--if it happens, then
> fees go up?
> 
Since only fees for IPv6 go up, and, only a minimal amount to a relatively
small fraction of ARIN's customer base, I tend to doubt there is any
actual disincentive.

Owen



From jcurran at arin.net  Tue Apr 27 14:30:59 2010
From: jcurran at arin.net (John Curran)
Date: Tue, 27 Apr 2010 14:30:59 -0400
Subject: [arin-ppml] =?windows-1252?q?Reminder_-_Consultation_=96_Transfer?=
	=?windows-1252?q?_Listing_Service?=
References: <4BCF2AA0.90709@arin.net>
Message-ID: <0DFE1366-BBE8-4436-8366-A631E3E1F70C@arin.net>

ARIN is presently conducting a community consultation on implementation
of a Transfer Listing Service to facilitate designated transfers of IPv4 number
resources to specified qualified recipients per NRPM 8.3.  Comments on this
service are encouraged, and details on the consultation may be found in the
attached announcement.

Thank you for your assistance and feedback!
/John

John Curran
President and CEO
ARIN


Begin forwarded message:

From: Member Services <info at arin.net<mailto:info at arin.net>>
Date: April 21, 2010 9:41:04 AM PDT
To: arin-announce at arin.net<mailto:arin-announce at arin.net>
Subject: [arin-announce] Consultation ? Transfer Listing Service

ARIN is seeking community input regarding the implementation of a Transfer Listing Service for parties with documented need who are seeking IPv4 address space and parties who are authorized resource holders that may potentially be able to make IPv4 number resource available for transfer. The Transfer Listing Service is proposed to facilitate the implementation of Section 8.3 of the Number Resource Policy Manual (NRPM), entitled ?Transfers to Specified Recipients?, which allows a party to designate transfer of IPv4 number resources to a specified qualified recipient.

The proposed Transfer Listing Service is located at www.arin.net/resources/transfer_listing.html<http://www.arin.net/resources/transfer_listing.html>. It is a hypothetical model to generate discussion; ARIN is specifically interested in receiving feedback on the following:

1. How long should ARIN offer a Transfer Listing Service and what, if any, conditions should be tied to its availability?

2. As proposed, there is a usage agreement for participation. Is this a fair and reasonable requirement?

3. Under what conditions should ARIN disallow or remove either an organization listing or seeking IPv4 address space from the service? For example, if an organization has a Registration Services Agreement
(?RSA?) with ARIN and is not current on payments with ARIN, should they be allowed to participate?

4. Should there be a fee associated with the Transfer Listing Service?
If so, on what factors should the fee be based?

5. Are there any other factors that ARIN should consider in providing this service?

A Transfer Listing Service will begin operation as soon as possible after the successful completion of this community consultation.

Comments regarding this proposed Transfer Listing Service can be submitted through the ARIN Consultation and Suggestion Process, available at: https://www.arin.net/participate/acsp/index.html

Discussion on arin-consult at arin.net<mailto:arin-consult at arin.net> will close on 21 May 2010, at noon EDT.

ARIN welcomes community-wide participation. Please address any process questions to info at arin.net<mailto:info at arin.net>.

Regards,

Member Services
American Registry for Internet Numbers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100427/a9e0b801/attachment.htm>

From tedm at ipinc.net  Tue Apr 27 16:13:17 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 27 Apr 2010 13:13:17 -0700
Subject: [arin-ppml] IPv6 Guarantee
In-Reply-To: <709763.41775.qm@web63308.mail.re1.yahoo.com>
References: <i2g3c3e3fca1004261941w82c6696eka6e38d486a683175@mail.gmail.com>
	<709763.41775.qm@web63308.mail.re1.yahoo.com>
Message-ID: <4BD7455D.1040208@ipinc.net>



   I think that it is imperative that the IPv4->IPv6
transition be as fee-neutral as possible.

   This is why the language here:

https://www.arin.net/fees/fee_schedule.html

"...ISPs with both IPv4 resources and IPv6 resources pay the larger of 
the two fees...."

because it causes a smooth transition from IPv4->IPv6
for most orgs from a fee standpoint, since as an org stops
using IPv4 and starts replacing it with IPv6, their
fees remain unchanged.

This allows the network admin to be removed from the
ROI discussions over IP addressing fees of the IPv4->IPv6
transition.  It removes some control of the corporate
beancounters over the network admin.

If ARIN were to ever attempt to do something like this
suggestion your going to merely succeed
in perking up the ears of the beancounters when they
hear or read about the word "fee refund".

Right now the admin has control since he can choose to
commence his IPv6 transition and thus avoid having to
shell out a cash-pile for IPv4 off the transfer market.
If he's doing what we want - transitioning to IPv6 -
the beancounters leave him alone.  They only make life
miserable for him if he's a laggard and has to go to them
for a cash-pile to buy IPv4 from the transfer market.

But this proposal is going to have the beancounters on
his neck whether he's doing what we want or not - they
are either going to be screaming at him for being a
laggard and wanting money for IPv4 off the transfer
market, or they are going to be screaming at him because
they want to be absolutely sure the are gonna get that
fee refund.  Since he's going to have them on his neck
either way, I think it really does disincentivize IPv6
deployment

Ted

On 4/27/2010 8:11 AM, Lee Howard wrote:
> ----- Original Message ----
>
>> From: William Herrin<bill at herrin.us>
>> To: arin-ppml at arin.net
>> Sent: Mon, April 26, 2010 10:41:22 PM
>> Subject: [arin-ppml] IPv6 Guarantee
>>
>> The IPv6 guarantee:  20% or it's free
>
> Interesting idea.  I like it for its novelty.  Don't know if I
> would actually support it yet.
> Does that disincentivize IPv6 deployment--if it happens, then
> fees go up?
>
>> Every January 1, ARIN will determine
>> whether at least 20% of typical
>> residential packets on ARIN-territory
>> Internet connections are carried
>> via IPv6, as reported by scientifically
>> defensible studies. If not,
>> all registrants who both hold IPv6 registrations
>> and route the
>> registered address blocks on the public Internet will receive a
>> full refund of any registration, maintenance or other ARIN fees incurred
>> in the prior year solely as a consequence of the IPv6
>> registration.
>
> I would assume we would use the ASCP Consultation Process
> to solicit proposals for studies.
>
> Lee
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From mysidia at gmail.com  Tue Apr 27 19:56:02 2010
From: mysidia at gmail.com (James Hess)
Date: Tue, 27 Apr 2010 18:56:02 -0500
Subject: [arin-ppml] IPv6 Guarantee
In-Reply-To: <4BD7455D.1040208@ipinc.net>
References: <i2g3c3e3fca1004261941w82c6696eka6e38d486a683175@mail.gmail.com>
	<709763.41775.qm@web63308.mail.re1.yahoo.com>
	<4BD7455D.1040208@ipinc.net>
Message-ID: <r2v6eb799ab1004271656m4a3c473cra77623f2d94fc37b@mail.gmail.com>

On Tue, Apr 27, 2010 at 3:13 PM, Ted Mittelstaedt <tedm at ipinc.net> wrote:
> If ARIN were to ever attempt to do something like this
> suggestion your going to merely succeed
> in perking up the ears of the beancounters when they
> hear or read about the word "fee refund".

Perhaps  ARIN should reserve the  last /8 it gets,  and make a rule to
 only allocate any space from it   to organizations  are able to
demonstrate some
reasonable level of  permanent IPv6 connectivity,  and still want the
IPs  12 months after applying ---  in other words, a 12 months delay
to get IPv4 addresses.  :)

Applicants who request an allocation at the time no other addresses
are available will be informed that  the requested addresses are
generally unavailable,    they may request an IPv6  address assignment
instead.

And if  20%  IPv6  isn't met within 12 months,   then they will
receive IPv4 addresses from the /8,  to the extent available,  without
an additional cost.

With requests sorted in order of size  (and requests for the smallest
amounts of addresses being answered first,  in a randomized order)

-- 
-J


From info at arin.net  Wed Apr 28 11:02:53 2010
From: info at arin.net (Member Services)
Date: Wed, 28 Apr 2010 11:02:53 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - April 2010
Message-ID: <4BD84E1D.8060803@arin.net>

In accordance with the ARIN Policy Development Process the ARIN Advisory
Council (AC) held a meeting on 21 April 2010 and made decisions about
several draft policies.

The AC moved the following draft policies to last call (each of these
three drafts will be posted separately to last call):

   2010-2: /24 End User Minimum Assignment Unit
   2010-4: Rework of IPv6 allocation criteria
   2010-6: Simplified M&A transfer policy

The AC abandoned the following draft policies:

   2010-3: Customer Confidentiality
   2010-5: Reduce and Simplify IPv4 Initial Allocations
   2010-7: Simplified IPv6 policy

The AC noted, "Given the lack of support at the ARIN XXV meeting for
Draft Policy 2010-3, and given the petitioner's desire to have the
proposal withdrawn, the AC has abandoned Draft Policy 2010-3."

2010-5 was abandoned due to lack of support.

The AC commented, "Given the lack of support at the ARIN XXV meeting for
2010-7's approach as a comprehensive rewrite of IPv6 policy, the AC has
abandoned Draft Policy 2010-7. However, it was suggested in the meeting
that parts of 2010-7 maybe a good basis for  separate proposals more
limited in scope. Therefore, the AC plans to  review 2010-7, the related
record from the meeting, and PPML, to see if there are such proposals
that could be resubmitted in the future. As always, the AC welcomes and
encourages community input or proposals that may lead to useful policy."

The following draft policies remain on the AC's docket for further
development and evaluation:

   2010-1: Waiting List for Unmet IPv4 Requests
   2010-8: Rework of IPv6 assignment criteria

Several of the AC's decisions may be petitioned. This includes the draft
policies that were abandoned (2010-3, 2010-5, 2010-7) and the drafts
that were not selected for last call (2010-1, 2010-8). Anyone
dissatisfied with these decisions may initiate a "Last Call Petition."
The purpose of a petition at this time is to try to send the draft
policy to last call. The deadline to begin a petition is 5 May 2010. For
more information on starting and participating in petitions, see PDP
Petitions at: https://www.arin.net/policy/pdp_petitions.html

Draft Policy and Proposal texts are available at:
https://www.arin.net/policy/proposals/index.html

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


















From info at arin.net  Wed Apr 28 11:03:14 2010
From: info at arin.net (Member Services)
Date: Wed, 28 Apr 2010 11:03:14 -0400
Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment
 Unit - Last Call
Message-ID: <4BD84E32.1040000@arin.net>

The ARIN Advisory Council (AC) met on 21 April 2010 and decided to
send the following draft policy to last call:

    Draft Policy 2010-2: /24 End User Minimum Assignment Unit

The AC met in accordance with the ARIN Policy Development Process which
requires the AC to meet within 30 days of the conclusion of the Public
Policy Meeting to make decisions about the draft policies that had been
presented.

Feedback is encouraged during this last call period. All comments should
be provided to the Public Policy Mailing List. This last call will
expire on 12 May 2010. After last call the AC will conduct their
last call review.

The draft policy text is below and available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2010-2
/24 End User Minimum Assignment Unit

Version/Date: 2 March 2010

Policy statement:

Replace section 4.3.2.2 of the NRPM with the following:

4.3.2.2 Multihomed Connection

For multi-homed end-users who demonstrate an intent to announce the
requested space in a multihomed fashion to two or more distinct ASNs not
owned or controlled by the end-user, the minimum block of IP address
space assigned is a /24. If assignments smaller than a /24 are needed,
multihomed end-users should contact their upstream providers. When
prefixes are assigned which are longer than /20, they will be from a
block reserved for that purpose so long as that is feasible.

Renumber the existing paragraph under the 4.3.6 to

4.3.6.1 Utilization requirements for additional Assignment

Add the following paragraph 4.3.6.2

4.3.6.2 Additional assignments for small multi-homers

Any end-user that possesses an assignment smaller than /22 under any
part of section 4.3 shall not be able to get an additional assignment
unless they agree to return all existing 4.3 assignments with a /23 or
longer prefix within 12 months of receiving a new assignment. The new
assignment shall be sized to accommodate their existing utilization in
addition to their justified additional growth space under section
4.3.6.1. The common cases for this are expected to be a /24 returned
after receipt of a /23, or a /23 returned after receipt of a /22.

Rationale:

This policy attempts to incorporate the recent and historical
discussions of policy for multi-home users on PPML. The intent is to
provide as fair a process as possible for multi-homed organizations down
to the smallest feasible size while still preserving some control over
growth in the routing table.

It has been repeatedly noted that /24 multi-homers exist today with PA
space and still occupy a routing table slot, so, it is unlikely that
moving this boundary to /24 would significantly impact the routing table.

By requiring smaller assignments to renumber and return, rather than add
more small blocks to their assignments, this policy seeks to further
reduce the chances of unnecessary growth in the routing table and
encourage good aggregation where possible.

Does this apply only to end users? Yes, this policy applies only to end
users. This policy does not represent a good solution for organizations
that are delegating space to other entities. If a case can be made that
such a policy is needed for ISPs, then, the author is happy to work with
interested parties to craft such a policy, but, this policy would be
unnecessarily onerous on ISPs, and, as an ISP policy could be somewhat
onerous to their peers and/or upstream providers.

What about resources obtained from policies other than 4.3 or outside of
ARIN? Such resources would not be counted for excluding an organization
from this policy. The intent is to limit IPv4 micro-allocations for
multi-homed end-user organizations under this policy to a single
assignment unless each such assignment is /22 or larger. This is to
prevent unnecessary routing table growth. This is a tradeoff, and, not
the ideal solution for smaller end-user organizations, however, author
believes that this is the best policy likely to gain consensus at this
time and believes that it is incrementally far better for such
organizations than current policy.

If I grow, I have to renumber? Not necessarily... If you have a /24
under this policy, and you want to grow that, then, you will likely need
to renumber. Depending on ARIN resource management and timing, ARIN may
simply be able to give you the /23 that includes your /24. More likely,
you will get a new /23, have 1 year to renumber into that and return
your /24. At most, you would be subject to two such renumbering cycles
under this policy (24->23 and 23->22) before you meet the criteria for
other policies which do not require renumbering.

Other policies don't include renumbering provisions, why this one? The
policy which allows multi-homed organizations to get a /22 was
originally written at /24. That policy was shouted down and /22 was the
compromise achieved to gain community consensus for anything smaller
than /20. Author hopes that this compromise will allow many
organizations to get resources they need with minimal impact while
assuring the community that doing so will not cause an explosion in the
routing table.

Timetable for implementation: Immediate







From info at arin.net  Wed Apr 28 11:03:27 2010
From: info at arin.net (Member Services)
Date: Wed, 28 Apr 2010 11:03:27 -0400
Subject: [arin-ppml] Draft Policy 2010-4: Rework of IPv6 allocation criteria
	- Last Call
Message-ID: <4BD84E3F.6090009@arin.net>

The ARIN Advisory Council (AC) met on 21 April 2010 and decided to
send the following draft policy to last call:

    Draft Policy 2010-4: Rework of IPv6 allocation criteria

The AC met in accordance with the ARIN Policy Development Process which
requires the AC to meet within 30 days of the conclusion of the Public
Policy Meeting to make decisions about the draft policies that had been
presented.

Feedback is encouraged during this last call period. All comments should
be provided to the Public Policy Mailing List. This last call will
expire on 12 May 2010. After last call the AC will conduct their
last call review.

The draft policy text is below and available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2010-4
Rework of IPv6 allocation criteria

Version/Date: 23 February 2010

Policy statement:

Delete section 6.4.3. Minimum Allocation.

Modify the following sections;

6.5.1 Initial allocations for ISPs and LIRs

6.5.1.1. Initial allocation size

Organizations that meet at least one of the following criteria are
eligible to receive a minimum allocation of /32. Requests for larger
allocations, reasonably justified with supporting documentation, will be
evaluated based on the number of existing users and the extent of the
organization's infrastructure.

6.5.1.2. Criteria for initial allocation to ISPs

Organizations may justify an initial allocation for the purpose of
assigning addresses to other organizations or customers that it will
provide IPv6 Internet connectivity to, with an intent to provide global
reachability for the allocation within 12 months, by meeting one of the
following additional criteria:

a. Having a previously justified IPv4 ISP allocation from ARIN or one of
its predecessor registries, or;

b. Currently being IPv6 Multihomed or immediately becoming IPv6
Multihomed and using an assigned valid global AS number, or;

c. By providing a reasonable plan detailing assignments to other
organizations or customers for one, two and five year periods, with a
minimum of 50 assignments within 5 years.

6.5.1.3. Criteria for initial allocation to other LIRs

Organizations may justify an initial allocation for the purpose of
assigning addresses to other organizations or customers that it will
provide IPv6 based network connectivity services to, not necessarily
Internet connected, by meeting one of the following additional criteria:

a. Having a previously justified IPv4 ISP allocation from ARIN or one of
its predecessor registries, or;

b. By providing a reasonable technical justification, indicating why an
allocation is necessary, including the intended purposes for the
allocation, and describing the network infrastructure the allocation
will be used to support. Justification must include a plan detailing
assignments to other organizations or customers for one, two and five
year periods, with a minimum of 50 assignments within 5 years.

Rationale:

This proposal provides a complete rework of the IPv6 allocation criteria
while maintaining many of the basic concepts contained in the current
policies. The order of the subsections of 6.5.1 are rearranged moving
the initial allocation size to 6.5.1.1. This will facilitate adding
future criteria without additional renumbering the current policies.

The initial allocation criteria include the following general concepts:

? The need for an allocation is only justified by the need to assign
resource to customers, either internal or external.
? When the need to provide Internet connectivity is use to justify
resources it is implied the resources should be advertised to the
Internet, within some reasonable time frame after they are received.
? IPv4 resources may be use to justify the need for IPv6 resources.
? An ISP may justify independent resource by being Multihomed or
planning to assign IPv6 resource to some minimum number of customers.
? It should be possible to justify an IPv6 allocation for more than just
classical ISPs, such as non-connected networks or other types of LIRs.
But additional justification should be required, describing the purpose
and network infrastructure the allocation will be supporting.

Finally, section 6.4.3 Minimum Allocation, is deleted as it is
incomplete and redundant anyway.

Timetable for implementation: immediate









From info at arin.net  Wed Apr 28 11:03:39 2010
From: info at arin.net (Member Services)
Date: Wed, 28 Apr 2010 11:03:39 -0400
Subject: [arin-ppml] Draft Policy 2010-6: Simplified M&A transfer policy -
	Last Call
Message-ID: <4BD84E4B.2070509@arin.net>

The ARIN Advisory Council (AC) met on 21 April 2010 and decided to
send the following draft policy to last call:

    Draft Policy 2010-6: Simplified M&A transfer policy

The AC met in accordance with the ARIN Policy Development Process which
requires the AC to meet within 30 days of the conclusion of the Public
Policy Meeting to make decisions about the draft policies that had been
presented.

Feedback is encouraged during this last call period. All comments should
be provided to the Public Policy Mailing List. This last call will
expire on 12 May 2010. After last call the AC will conduct their
last call review.

The draft policy text is below and available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2010-6
Simplified M&A transfer policy

Version/Date: 23 February 2010

Policy statement:

Replace section 8.2 with:

8.2. Mergers and Acquisitions

ARIN will consider requests for the transfer of number resources in the
case of mergers and acquisitions upon receipt of evidence that the new
entity has acquired assets that used the transferred resources from the
current registrant. ARIN will maintain an up-to-date list of acceptable
types of documentation.

In the event that number resources of the combined organizations are no
longer justified under ARIN policy at the time ARIN becomes aware of the
transaction, through a transfer request or otherwise, ARIN will work
with the resource holder(s) to return, aggregate, or reclaim resources
as appropriate via the processes outlined in current ARIN policy (for
example, sections 4.6, 4.7, or 12 of the NRPM).

Add "In addition to transfers under section 8.2, " at the beginning of
section 8.3. Transfers to Specified Recipients.

Rationale:

This policy proposal: attempts to simplify the M&A transfer section of
the NRPM; eliminates the ambiguity discussed at the ARIN Public Policy
Meeting (PPM) in Dearborn by clarifying that transfers can occur under
either 8.2 or 8.3 independently; and attempts to address the concerns
raised in the staff policy implementation report at the Dearborn PPM
(https://www.arin.net/participate/meetings/reports/ARIN_XXIV/PDF/thursday/policy_exp_report.pdf)

The idea here is to simply say that ARIN will allow M&A transfers, and
to require the return of any number resources for which there is no
longer a justified need after the acquisition. Preferably that would
happen voluntarily under the policies of NRPM 4.6 (Amnesty), but it also
leaves the door open for ARIN to revoke space under NRPM 12 (Resource
Review) if necessary. By implication, future needs that would qualify
the organization for an allocation/assignment would likewise justify
keeping transferred space. In particular, see the language of NRPM
section 12, paragraphs 4 and 4a.

This policy also should dramatically increase the completion rate for
transfer requests, as the evaluation of whether space is efficiently
utilized after the transfer can occur in parallel, completely
independently of the transfer request, and can continue even if the
transfer request is abandoned.

The bulleted lists of acceptable documentation removed from the NRPM
should be maintained by ARIN elsewhere on the website, such as at
https://www.arin.net/resources/request/transfers.html

FAQ:

Q1: What about legacy resources?

A1: Resources subject to the legacy RSA are exempt from a number of ARIN
policies, such as usage justification. However, the recipient of
transferred resources must sign a standard RSA covering the received
resources. At that point, the resources lose their legacy status and
become subject to all ARIN policies, including section 12.

Q2: I'm not sure how NRPM 4.7 will come into play with this policy. Is
the aggregation policy actually applicable here? I understand how 4.6
would work, but just not making the connection with 4.7.

A2: If the organization is returning pieces of space, or, wants to
return multiple disparate chunks and get a single aggregate in the
process, that shouldn't be precluded. NRPM section 4.7 facilitates that.

Timetable for implementation: Immediate











From tedm at ipinc.net  Wed Apr 28 13:26:05 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 28 Apr 2010 10:26:05 -0700
Subject: [arin-ppml] IPv6 Guarantee
In-Reply-To: <r2v6eb799ab1004271656m4a3c473cra77623f2d94fc37b@mail.gmail.com>
References: <i2g3c3e3fca1004261941w82c6696eka6e38d486a683175@mail.gmail.com>	
	<709763.41775.qm@web63308.mail.re1.yahoo.com>	
	<4BD7455D.1040208@ipinc.net>
	<r2v6eb799ab1004271656m4a3c473cra77623f2d94fc37b@mail.gmail.com>
Message-ID: <4BD86FAD.9000900@ipinc.net>



On 4/27/2010 4:56 PM, James Hess wrote:
> On Tue, Apr 27, 2010 at 3:13 PM, Ted Mittelstaedt<tedm at ipinc.net>  wrote:
>> If ARIN were to ever attempt to do something like this
>> suggestion your going to merely succeed
>> in perking up the ears of the beancounters when they
>> hear or read about the word "fee refund".
>
> Perhaps  ARIN should reserve the  last /8 it gets,  and make a rule to
>   only allocate any space from it   to organizations  are able to
> demonstrate some
> reasonable level of  permanent IPv6 connectivity,  and still want the
> IPs  12 months after applying ---  in other words, a 12 months delay
> to get IPv4 addresses.  :)
>

I love that!  I can hear the cats screaming about it now, though.

Ted

> Applicants who request an allocation at the time no other addresses
> are available will be informed that  the requested addresses are
> generally unavailable,    they may request an IPv6  address assignment
> instead.
>
> And if  20%  IPv6  isn't met within 12 months,   then they will
> receive IPv4 addresses from the /8,  to the extent available,  without
> an additional cost.
>
> With requests sorted in order of size  (and requests for the smallest
> amounts of addresses being answered first,  in a randomized order)
>


From owen at delong.com  Wed Apr 28 17:38:13 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 28 Apr 2010 14:38:13 -0700
Subject: [arin-ppml] IPv4 Fragment Managemnt policy proposal
Message-ID: <8AEAA82D-9BA6-408F-B256-157D61C952CB@delong.com>

At ARIN XXV, one of the discussions pointed out that under current
ARIN policy, after IANA runout, a justified request for a /10 could
(and would) be satisfied, if necessary, by issuing 1024 disjoint /20s.

I believe there is a need for policy to prevent this kind of
gathering of the last breadcrumbs by a small number of large
entities. As such, I offer the following proposal for the discussion
of the community.

Owen

TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0

1.      Policy Proposal Name:	IPv4 Fragment Management
2.      Proposal Originator
        a.      name:		Owen DeLong
        b.      email:		owen at delong.com
        c.      telephone:	408-890-7992
        d.      organization:	Hurricane Electric
3.      Proposal Version:	0.8
4.      Date:			2010-04-28
5.      Proposal type:		New
        new, modify, or delete.
6.      Policy term:		Permanent
        temporary, permanent, or renewable.
7.      Policy statement:

	Add the following to the NRPM as new sections 4.2.1.7 et. seq.

	Each time ARIN approves an IPv4 request which it cannot
	satisfy from 4 or fewer bit-aligned blocks of free address
	space, ARIN shall notify the requestor that there is
	insufficient free address space to meet their request and
	shall offer the requestor their choice of the following
	alternatives:

	a.	They can have the largest 4 available bit-aligned
		blocks of free addresses.

	b.	This section reserved -- (in case we implement the
		waiting list for unmet requests policy)

	c.	They can seek resources through the directed
		transfer policy in section 8.3 of the NRPM.

8.      Rationale:

	When the ARIN free pool begins to diminish, the free space
	will become fragmented into smaller and smaller remaining
	contiguous spaces. This policy attempts to ensure that a
	large number of remaining disjoint small blocks are not
	consumed by a single large request.

	While this policy could be regarded as unfair to larger
	entities, it is consistent with the safeguards adopted in
	section 8.3 which require an exact match or full fill
	style of resource transfer.  As such, I believe the policy
	is fair and in line with the consensus will of the community.

9.      Timetable for implementation: Immediate, although it has no
		actual effect until some time after IANA runout.

END OF TEMPLATE

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100428/757a0ab9/attachment.htm>

From scottleibrand at gmail.com  Wed Apr 28 17:44:03 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 28 Apr 2010 14:44:03 -0700
Subject: [arin-ppml] IPv4 Fragment Management policy proposal
In-Reply-To: <8AEAA82D-9BA6-408F-B256-157D61C952CB@delong.com>
References: <8AEAA82D-9BA6-408F-B256-157D61C952CB@delong.com>
Message-ID: <4BD8AC23.90202@gmail.com>

Owen,

2010-1 is intended to prevent this for free pool addresses, and 8.3 
transfer policy disallows it for transfers.

Do you feel that either of those are insufficient?

-Scott

On Wed 4/28/2010 2:38 PM, Owen DeLong wrote:
> At ARIN XXV, one of the discussions pointed out that under current
> ARIN policy, after IANA runout, a justified request for a /10 could
> (and would) be satisfied, if necessary, by issuing 1024 disjoint /20s.
>
> I believe there is a need for policy to prevent this kind of
> gathering of the last breadcrumbs by a small number of large
> entities. As such, I offer the following proposal for the discussion
> of the community.
>
> Owen
>
> TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0
>
> 1.      Policy Proposal Name: IPv4 Fragment Management
> 2.      Proposal Originator
>         a.      name: Owen DeLong
>         b.      email: owen at delong.com <mailto:owen at delong.com>
>         c.      telephone: 408-890-7992
>         d.      organization: Hurricane Electric
> 3.      Proposal Version: 0.8
> 4.      Date: 2010-04-28
> 5.      Proposal type: New
>         new, modify, or delete.
> 6.      Policy term: Permanent
>         temporary, permanent, or renewable.
> 7.      Policy statement:
>
> Add the following to the NRPM as new sections 4.2.1.7 et. seq.
>
> Each time ARIN approves an IPv4 request which it cannot
> satisfy from 4 or fewer bit-aligned blocks of free address
> space, ARIN shall notify the requestor that there is
> insufficient free address space to meet their request and
> shall offer the requestor their choice of the following
> alternatives:
>
> a. They can have the largest 4 available bit-aligned
> blocks of free addresses.
>
> b. This section reserved -- (in case we implement the
> waiting list for unmet requests policy)
>
> c. They can seek resources through the directed
> transfer policy in section 8.3 of the NRPM.
>
> 8.      Rationale:
>
> When the ARIN free pool begins to diminish, the free space
> will become fragmented into smaller and smaller remaining
> contiguous spaces. This policy attempts to ensure that a
> large number of remaining disjoint small blocks are not
> consumed by a single large request.
>
> While this policy could be regarded as unfair to larger
> entities, it is consistent with the safeguards adopted in
> section 8.3 which require an exact match or full fill
> style of resource transfer.  As such, I believe the policy
> is fair and in line with the consensus will of the community.
>
> 9.      Timetable for implementation: Immediate, although it has no
> actual effect until some time after IANA runout.
>
> END OF TEMPLATE
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100428/1dcc2534/attachment.htm>

From marty at akamai.com  Wed Apr 28 21:29:09 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Wed, 28 Apr 2010 21:29:09 -0400
Subject: [arin-ppml] IPv4 Fragment Managemnt policy proposal
In-Reply-To: <8AEAA82D-9BA6-408F-B256-157D61C952CB@delong.com>
Message-ID: <C7FE5925.2D8FA%marty@akamai.com>



No need to assert a position on this, but I will say that the distribution
method is severely lacking. Under this regime some will undoubtedly fulfill
their requests entirely and others will not.

The language that would be more suitable is something akin to pct of space
available related to request fulfillment pct IMHO. Specifying hard limits
may be anti-competitive, especially with the apparently hostile reason that
you state for the creation of this policy ?I believe there is a need for
policy to prevent this kind of gathering of the last breadcrumbs by a small
number of large entities.?

Best,

-M<


-- 
Martin Hannigan                        http://www.akamai.com
Akamai Technologies, Inc.              marty at akamai.com
Cambridge, MA USA                      cell: +16178216079
                                       ofc: +16174442535



From: Owen DeLong <owen at delong.com>
Date: Wed, 28 Apr 2010 14:38:13 -0700
To: <policy at arin.net>, arin ppml <ppml at arin.net>
Subject: [arin-ppml] IPv4 Fragment Managemnt policy proposal

At ARIN XXV, one of the discussions pointed out that under current
ARIN policy, after IANA runout, a justified request for a /10 could
(and would) be satisfied, if necessary, by issuing 1024 disjoint /20s.

I believe there is a need for policy to prevent this kind of
gathering of the last breadcrumbs by a small number of large
entities. As such, I offer the following proposal for the discussion
of the community.

Owen

TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0

1.      Policy Proposal Name: IPv4 Fragment Management
2.      Proposal Originator
        a.      name: Owen DeLong
        b.      email: owen at delong.com
        c.      telephone: 408-890-7992
        d.      organization: Hurricane Electric
3.      Proposal Version: 0.8
4.      Date: 2010-04-28
5.      Proposal type: New
        new, modify, or delete.
6.      Policy term: Permanent
        temporary, permanent, or renewable.
7.      Policy statement:

Add the following to the NRPM as new sections 4.2.1.7 et. seq.

Each time ARIN approves an IPv4 request which it cannot
satisfy from 4 or fewer bit-aligned blocks of free address
space, ARIN shall notify the requestor that there is
insufficient free address space to meet their request and
shall offer the requestor their choice of the following
alternatives:

a. They can have the largest 4 available bit-aligned
blocks of free addresses.

b. This section reserved -- (in case we implement the
waiting list for unmet requests policy)

c. They can seek resources through the directed
transfer policy in section 8.3 of the NRPM.

8.      Rationale:

When the ARIN free pool begins to diminish, the free space
will become fragmented into smaller and smaller remaining
contiguous spaces. This policy attempts to ensure that a
large number of remaining disjoint small blocks are not
consumed by a single large request.

While this policy could be regarded as unfair to larger
entities, it is consistent with the safeguards adopted in
section 8.3 which require an exact match or full fill
style of resource transfer.  As such, I believe the policy
is fair and in line with the consensus will of the community.

9.      Timetable for implementation: Immediate, although it has no
actual effect until some time after IANA runout.

END OF TEMPLATE



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100428/7e2ef630/attachment.htm>

From ipv3.com at gmail.com  Wed Apr 28 22:29:52 2010
From: ipv3.com at gmail.com (IPv3.com)
Date: Wed, 28 Apr 2010 21:29:52 -0500
Subject: [arin-ppml] Post IANA & RIR IPv4 Address Space Management Silos
Message-ID: <h2o113c8ba81004281929heb3e137akd599622e4123b6ac@mail.gmail.com>

Post IANA & RIR IPv4 Address Space Management Silos

Historically the IPv4 Address Space has been managed based on /8s with
256 rows in the table.
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml

Using a /6 View there would be 64 rows or Silos
Using a /12 View there would be 4096 Silos
Using the 6-bit Alphabet (64 Symbols) each of the /12 Silos would have
Two Symbols LL with case-sensitive
[LL could be US Us uS us or CA Ca cA ca]
Each of the /12 Silos would be included in one of the 64 Silos

Each of the 64 Silos could be self-governed in a bottom-up manner by
the /12 Silos
People, governments, TLD Registries, cats, dogs, ISPs, RIRs, etc.
could find their place(s) in the 4096 Silos

Artificial (arbitrary?) rules would not allow blocks to be aggregated
(managed) across Silos at either level.
Trading, leasing, grey-markets, black-markets, etc. may vary from one
Silo to the next. Birds of a feather...blah blah blah

Some simple site(s) can be used to display the various Silos & Community links.
FREE services such as http://NING.com could be used to set up 4096
Silos (each a FB-like Community)

The /6 & /12 are arbitrary & artificial but tied to the 64 Symbol set.
0-9 A-Z a@ b? c? d? e= f? g& h# i| j? k? l( m? n! o* p% q? r) s$ t~ u_
v^ w? x? y? z? -? .? ~ 6 bits per Symbol

People may find that a New look at an old table allows them a new beginning...
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt


From ipv3.com at gmail.com  Wed Apr 28 22:54:33 2010
From: ipv3.com at gmail.com (IPv3.com)
Date: Wed, 28 Apr 2010 21:54:33 -0500
Subject: [arin-ppml] Example SILO (or SandBox) 4/6
Message-ID: <u2o113c8ba81004281954t2c19663bt3090c92ad02f1e6@mail.gmail.com>

Example SILO (or SandBox) 4/6
4/6------------------------
016/8  Digital Equipment Corporation                  1994-11
           LEGACY
017/8  Apple Computer Inc.                            1992-07
           LEGACY
018/8  MIT                                            1994-01
           LEGACY
019/8  Ford Motor Company                             1995-05
           LEGACY
-----------------------------

In the Post IANA & RIR approach, the above 4 /8s would be grouped and
since IPv4 is "Full" and completely
and efficiently utilized, people from the above organizations would
Self-Govern SandBox 4/6.
They would be like a mini-IANA for only those 4 /8s.

There would also be many /12s inside that SandBox. What those would
look like and how they are governed
would be left to the bottom-up process. Since IPv4 is "Full" and
completely and efficiently utilized those /12s
would likely have people with an interest.

With only 64 SandBoxes, there would likely be some sort of global
coordination emerge. In general, people
could stay in their SandBoxes and Silos.
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt


From owen at delong.com  Thu Apr 29 00:07:32 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 28 Apr 2010 21:07:32 -0700
Subject: [arin-ppml] IPv4 Fragment Managemnt policy proposal
In-Reply-To: <C7FE5925.2D8FA%marty@akamai.com>
References: <C7FE5925.2D8FA%marty@akamai.com>
Message-ID: <B46FCF24-2093-4A05-BEA1-704D90E972FC@delong.com>

I don't understand what you mean by "% space available related to % request fulfillment".

The only thing I could think of was essentially what we have today -- If 100% of what you request is available, you get it.
If less than that is available, you get what is left.  Either of these regardless of the number of prefixes involved in fulfilling
your request.

Obviously you're suggesting something that could be a policy proposal, so, can you clarify what I misunderstood?

Since most laws against anti-competitive practices are geared towards preventing small numbers of massive organizations from blocking entry or competition by larger numbers of smaller entities, I believe that allowing a small number (or likely even 1 at some point) to garner all of the remaining space to the exclusion of a much larger number of smaller entities is unfair.  As it already stands, 24 extra large organizations hold more than 80% of the address space issued in 2006 and 2007 (the only statistics I could find on the ARIN web site).  I think the fair thing to do once ARIN starts receiving requests it can't satisfy with a single block is to start limiting the number of crumbs each organization may pick up at one time. Yes, this means that smaller organizations will continue to get the /20s and smaller that they ask for long after we can no longer hand out /9s.  However, that's largely the result of the fact that there are more than 2 million /20s in each /9 more than anything particularly unfair.

As time goes on, the size of the largest crumbs will get progressively smaller. In reality, under this policy, the large organizations will take the largest crumbs early on leaving only smaller crumbs behind.

Should they be allowed to get an ever increasing percentage of the remaining crumbs at the expense of others?

It's clearly expressed in NRPM 8.3 that this is not the will of the community.

One of the few points of 2010-1 that received no opposition was it's provision to limit each entity to exactly 1 crumb.  Here I'm offering 4 crumbs as an alternative strategy.

Otherwise, as it stands now, it's basically a lottery to see which x-large ISP picks up thousands of prefixes in one request to finish out the ARIN free pool.

Remember, there was some community support for proposals that said if your request can't be completely filled, you wait, too bad, so sad. I spoke out against those proposals because I felt they were unfair to large organizations. I believe current policy is unfair to smaller organizations. This policy is my attempt to strike a balance.


Owen

On Apr 28, 2010, at 6:29 PM, Hannigan, Martin wrote:

> 
> 
> No need to assert a position on this, but I will say that the distribution method is severely lacking. Under this regime some will undoubtedly fulfill their requests entirely and others will not. 
> 
> The language that would be more suitable is something akin to pct of space available related to request fulfillment pct IMHO. Specifying hard limits may be anti-competitive, especially with the apparently hostile reason that you state for the creation of this policy ?I believe there is a need for policy to prevent this kind of gathering of the last breadcrumbs by a small number of large entities.?
> 
> Best,
> 
> -M<
> 
> 
> -- 
> Martin Hannigan                        http://www.akamai.com
> Akamai Technologies, Inc.              marty at akamai.com
> Cambridge, MA USA                      cell: +16178216079
>                                        ofc: +16174442535
> 
> 
> From: Owen DeLong <owen at delong.com>
> Date: Wed, 28 Apr 2010 14:38:13 -0700
> To: <policy at arin.net>, arin ppml <ppml at arin.net>
> Subject: [arin-ppml] IPv4 Fragment Managemnt policy proposal
> 
> At ARIN XXV, one of the discussions pointed out that under current
> ARIN policy, after IANA runout, a justified request for a /10 could
> (and would) be satisfied, if necessary, by issuing 1024 disjoint /20s.
> 
> I believe there is a need for policy to prevent this kind of
> gathering of the last breadcrumbs by a small number of large
> entities. As such, I offer the following proposal for the discussion
> of the community.
> 
> Owen
> 
> TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0
> 
> 1.      Policy Proposal Name: IPv4 Fragment Management
> 2.      Proposal Originator
>         a.      name: Owen DeLong
>         b.      email: owen at delong.com
>         c.      telephone: 408-890-7992
>         d.      organization: Hurricane Electric
> 3.      Proposal Version: 0.8
> 4.      Date: 2010-04-28
> 5.      Proposal type: New
>         new, modify, or delete.
> 6.      Policy term: Permanent
>         temporary, permanent, or renewable.
> 7.      Policy statement:
> 
> Add the following to the NRPM as new sections 4.2.1.7 et. seq.
> 
> Each time ARIN approves an IPv4 request which it cannot
> satisfy from 4 or fewer bit-aligned blocks of free address
> space, ARIN shall notify the requestor that there is
> insufficient free address space to meet their request and
> shall offer the requestor their choice of the following
> alternatives:
> 
> a. They can have the largest 4 available bit-aligned
> blocks of free addresses.
> 
> b. This section reserved -- (in case we implement the
> waiting list for unmet requests policy)
> 
> c. They can seek resources through the directed
> transfer policy in section 8.3 of the NRPM.
> 
> 8.      Rationale:
> 
> When the ARIN free pool begins to diminish, the free space
> will become fragmented into smaller and smaller remaining
> contiguous spaces. This policy attempts to ensure that a
> large number of remaining disjoint small blocks are not
> consumed by a single large request.
> 
> While this policy could be regarded as unfair to larger
> entities, it is consistent with the safeguards adopted in
> section 8.3 which require an exact match or full fill
> style of resource transfer.  As such, I believe the policy
> is fair and in line with the consensus will of the community.
> 
> 9.      Timetable for implementation: Immediate, although it has no
> actual effect until some time after IANA runout.
> 
> END OF TEMPLATE
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100428/40937914/attachment.htm>

From michael.dillon at bt.com  Thu Apr 29 03:59:20 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 29 Apr 2010 08:59:20 +0100
Subject: [arin-ppml] IPv4 Fragment Managemnt policy proposal
In-Reply-To: <8AEAA82D-9BA6-408F-B256-157D61C952CB@delong.com>
Message-ID: <28E139F46D45AF49A31950F88C49745805E90B1A@E03MVZ2-UKDY.domain1.systemhost.net>

> Each time ARIN approves an IPv4 request which it cannot 
> satisfy from 4 or fewer bit-aligned blocks of free address 
> space, ARIN shall notify the requestor that there is 
> insufficient free address space to meet their request and 
> shall offer the requestor their choice of the following
> alternatives:
> 
> 
> a. They can have the largest 4 available bit-aligned blocks 
> of free addresses.
> 
> 
> b. This section reserved -- (in case we implement the waiting 
> list for unmet requests policy)
> 
> 
> c. They can seek resources through the directed transfer 
> policy in section 8.3 of the NRPM.

Seems like a good idea. 

One thing to be aware of is that ARIN does not allocate CIDR
blocks. They allocate IP address ranges, i.e. from a start
address to an ending address. One time we received an allocation
that consisted of two disjoint ranges. One of those was 3/4
of a reserved block where we had already received 1/4 of the
block previously. And the other was 1/4 of a new reserved block.

It might be a good idea to think this through and see whether
or not it can be simplified to say that ARIN will never allocate
more than 4 blocks to satisfy a request, and leave off the bit
about when there is insufficient free space.

--Michael Dillon


From ipv3.com at gmail.com  Thu Apr 29 06:00:00 2010
From: ipv3.com at gmail.com (IPv3.com)
Date: Thu, 29 Apr 2010 05:00:00 -0500
Subject: [arin-ppml] Post IANA & RIR IPv4 Address Space Management
	Parties(/1), Cultures(/2), Sandboxes(/6), Silos(/12)
Message-ID: <k2h113c8ba81004290300p37de0e31o2823a28b0e58d60a@mail.gmail.com>

Post IANA & RIR IPv4 Address Space Management Parties(/1),
Cultures(/2), Sandboxes(/6), Silos(/12)

One bit, a 0 or a 1, allows Two Parties to be defined. {Democrat 0 ,
Republican 1} is one example.
Two bits, 00 01 10 11, allow Four Cultures to be defined. [Unix 00
,ISOC 01 ,FCC 10 ,ITU 11] is an example.
http://www.ietf.org/mail-archive/web/rrg/current/msg06541.html
===================================
00 - UNIX
01 - ISOC, IETF, IRTF, IANA, ICANN, NANOG, RIRs...
10 - IEEE, ATSC, FCC, NTIA, NIST, LEOs...
11 - UN, ITU, ETSI...
===================================

Parties & Cultures can be used to "Help" the Sandboxes have default stewardship.

Example SandBox 4/6
4/6------------------------
{D} [UNIX] 016/8  Digital Equipment Corporation                  1994-11
           LEGACY
{R} [ISOC] 017/8  Apple Computer Inc.                            1992-07
           LEGACY
{D} [FCC] 018/8  MIT                                            1994-01
           LEGACY
{R} [ITU] 019/8  Ford Motor Company                             1995-05
           LEGACY
-----------------------------
With XSLT and XML this table can be shown collapsed to 64 rows with
Party & Culture labels.
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml

Old traditions of a One Party Dictator remain ?
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt

The U.S. FCC could step in and do the entire job of Post IANA & RIR stewardship.
http://xkcd.com/195/

The ITU could also easily do the entire task.

Binary does not change. One bit denotes Two 0 or 1. Two bits denote
Four 00 01 10 11.
With 6 bits (64) and 12 bits (4096) large blocks can be grouped for
"stewardship" (i.e. management).

Note: 3 bits could denote 8 Carriers....AT&T, Comcast....etc...they
could also do the entire job.


From jmaimon at chl.com  Thu Apr 29 09:49:03 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Thu, 29 Apr 2010 09:49:03 -0400
Subject: [arin-ppml] IPv4 Fragment Managemnt policy proposal
In-Reply-To: <8AEAA82D-9BA6-408F-B256-157D61C952CB@delong.com>
References: <8AEAA82D-9BA6-408F-B256-157D61C952CB@delong.com>
Message-ID: <4BD98E4F.8000306@chl.com>



Owen DeLong wrote:
> At ARIN XXV, one of the discussions pointed out that under current
> ARIN policy, after IANA runout, a justified request for a /10 could
> (and would) be satisfied, if necessary, by issuing 1024 disjoint /20s.
>
> I believe there is a need for policy to prevent this kind of
> gathering of the last breadcrumbs by a small number of large
> entities. As such, I offer the following proposal for the discussion
> of the community.
>
> Owen


I agree with the intent and support the policy proposal. I will also 
note that PP110 deals with this head on, but the two are not 
incompatible in either intent or effect.


> Add the following to the NRPM as new sections 4.2.1.7 et. seq.
>
> Each time ARIN approves an IPv4 request which it cannot
> satisfy from 4 or fewer bit-aligned blocks of free address
> space


This could be somewhat confusing. I would support a simple 1 request == 
1 NEW prefix + possible adjustments to old prefixes, which could differ 
from current practice.


>
> 8. Rationale:
>
> When the ARIN free pool begins to diminish, the free space
> will become fragmented into smaller and smaller remaining
> contiguous spaces. This policy attempts to ensure that a
> large number of remaining disjoint small blocks are not
> consumed by a single large request.


I question the effectiveness of any proposal that could be defeated 
simply by inundating ARIN with multiple smaller requests if the 
objective of the requester cannot be achieved via a single large request.

Unless constrained by policy, larger entities would easily be able to 
muster the manpower required to inundate ARIN with many justified small 
requests, either successively or concurrently.

As I currently understand it, the 12 or 3 month window are maximums, not 
minimums.

>
> While this policy could be regarded as unfair to larger
> entities,

I think we need to ask ourselves a few questions:

Is it possible to do anything that would not be perceived as unfair to 
segments of the ARIN community?

What about inaction?

Have some segments of the ARIN community received or are perceived to 
have received more than their fair share of fairness to date?

Might it not be time for them to repay the balance?

Could not it be considered that the only policy that is fair to large 
entities would be one that levels the field between them, by denying 
them resources equally, instead of potentially allowing one of them to 
gain a few month (or longer) advantage over the others?

Do we believe that IPv4 players large and small will begin an orderly 
transition to IPv6 when faced with real resource scarcity or do we 
expect or suspect chaos and crisis?

If there is a real chance of chaos and crisis, are we doing the best we 
can to prepare and attempt to mitigate?

Damned if we do, damned if we dont - is the question one of how hot will 
hell be?


>
> 9. Timetable for implementation: Immediate, although it has no
> actual effect until some time after IANA runout.

Only due to detail, but not due to intent. Edits could easily change that.


Joe



From owen at delong.com  Thu Apr 29 10:55:33 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 29 Apr 2010 07:55:33 -0700
Subject: [arin-ppml] IPv4 Fragment Managemnt policy proposal
In-Reply-To: <28E139F46D45AF49A31950F88C49745805E90B1A@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745805E90B1A@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <C44B3A05-282F-4CB1-B65D-FA2D01237105@delong.com>


On Apr 29, 2010, at 12:59 AM, <michael.dillon at bt.com> wrote:

>> Each time ARIN approves an IPv4 request which it cannot 
>> satisfy from 4 or fewer bit-aligned blocks of free address 
>> space, ARIN shall notify the requestor that there is 
>> insufficient free address space to meet their request and 
>> shall offer the requestor their choice of the following
>> alternatives:
>> 
>> 
>> a. They can have the largest 4 available bit-aligned blocks 
>> of free addresses.
>> 
>> 
>> b. This section reserved -- (in case we implement the waiting 
>> list for unmet requests policy)
>> 
>> 
>> c. They can seek resources through the directed transfer 
>> policy in section 8.3 of the NRPM.
> 
> Seems like a good idea. 
> 
> One thing to be aware of is that ARIN does not allocate CIDR
> blocks. They allocate IP address ranges, i.e. from a start
> address to an ending address. One time we received an allocation
> that consisted of two disjoint ranges. One of those was 3/4
> of a reserved block where we had already received 1/4 of the
> block previously. And the other was 1/4 of a new reserved block.
> 
While that is true, it does not need to remain true.  ARIN allocates
IP resources according to policy.  If policy states that ARIN will
allocate bit-aligned prefixes, then, ARIN will begin allocating in
that manner.

> It might be a good idea to think this through and see whether
> or not it can be simplified to say that ARIN will never allocate
> more than 4 blocks to satisfy a request, and leave off the bit
> about when there is insufficient free space.
> 

Having thought that through, I believe it would complicate the
policy and reduce clarity. Brevity is not always simplicity.

Owen



From info at arin.net  Thu Apr 29 11:45:47 2010
From: info at arin.net (Member Services)
Date: Thu, 29 Apr 2010 11:45:47 -0400
Subject: [arin-ppml] IPv4 Fragment Managemnt policy proposal
In-Reply-To: <8AEAA82D-9BA6-408F-B256-157D61C952CB@delong.com>
References: <8AEAA82D-9BA6-408F-B256-157D61C952CB@delong.com>
Message-ID: <4BD9A9AB.50805@arin.net>

ARIN received the following policy proposal.

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

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

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

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

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

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Owen DeLong wrote:
> At ARIN XXV, one of the discussions pointed out that under current
> ARIN policy, after IANA runout, a justified request for a /10 could
> (and would) be satisfied, if necessary, by issuing 1024 disjoint /20s.
>
> I believe there is a need for policy to prevent this kind of
> gathering of the last breadcrumbs by a small number of large
> entities. As such, I offer the following proposal for the discussion
> of the community.
>
> Owen
>
> TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0
>
> 1.      Policy Proposal Name: IPv4 Fragment Management
> 2.      Proposal Originator
>         a.      name: Owen DeLong
>         b.      email: owen at delong.com <mailto:owen at delong.com>
>         c.      telephone: 408-890-7992
>         d.      organization: Hurricane Electric
> 3.      Proposal Version: 0.8
> 4.      Date: 2010-04-28
> 5.      Proposal type: New
>         new, modify, or delete.
> 6.      Policy term: Permanent
>         temporary, permanent, or renewable.
> 7.      Policy statement:
>
> Add the following to the NRPM as new sections 4.2.1.7 et. seq.
>
> Each time ARIN approves an IPv4 request which it cannot
> satisfy from 4 or fewer bit-aligned blocks of free address
> space, ARIN shall notify the requestor that there is
> insufficient free address space to meet their request and
> shall offer the requestor their choice of the following
> alternatives:
>
> a. They can have the largest 4 available bit-aligned
> blocks of free addresses.
>
> b. This section reserved -- (in case we implement the
> waiting list for unmet requests policy)
>
> c. They can seek resources through the directed
> transfer policy in section 8.3 of the NRPM.
>
> 8.      Rationale:
>
> When the ARIN free pool begins to diminish, the free space
> will become fragmented into smaller and smaller remaining
> contiguous spaces. This policy attempts to ensure that a
> large number of remaining disjoint small blocks are not
> consumed by a single large request.
>
> While this policy could be regarded as unfair to larger
> entities, it is consistent with the safeguards adopted in
> section 8.3 which require an exact match or full fill
> style of resource transfer.  As such, I believe the policy
> is fair and in line with the consensus will of the community.
>
> 9.      Timetable for implementation: Immediate, although it has no
> actual effect until some time after IANA runout.
>
> END OF TEMPLATE
>




From info at arin.net  Thu Apr 29 11:59:34 2010
From: info at arin.net (Member Services)
Date: Thu, 29 Apr 2010 11:59:34 -0400
Subject: [arin-ppml] Policy Proposal 112: Utilization of 10.4.2 resources
 only via explicit policy
Message-ID: <4BD9ACE6.1020301@arin.net>

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

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

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

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

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

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

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal Name: Utilization of 10.4.2 resources only via explicit
policy

Proposal Originator: Joe Maimon

Proposal Version: 1.0

Date: 29 April 2010

Proposal type: New

Policy term: permanent

Policy statement:

Add section 4.11

4.11 Last /8 utilization

Resources received from IANA under section 10.4.2 (the last /8) will be
unavailable for any purposes not explicitly specified, such as 4.10, and
will be held in reserve.

Rationale:

No reason to blow the last /8 as quickly as all the others.

Timetable for implementation: Concurrently with 10.4




From michael.dillon at bt.com  Thu Apr 29 12:01:32 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 29 Apr 2010 17:01:32 +0100
Subject: [arin-ppml] IPv4 Fragment Managemnt policy proposal
In-Reply-To: <C44B3A05-282F-4CB1-B65D-FA2D01237105@delong.com>
Message-ID: <28E139F46D45AF49A31950F88C49745805EF5A8F@E03MVZ2-UKDY.domain1.systemhost.net>


> While that is true, it does not need to remain true.  ARIN 
> allocates IP resources according to policy.  If policy states 
> that ARIN will allocate bit-aligned prefixes, then, ARIN will 
> begin allocating in that manner.

That would be dumb

1. I ask for some addresses.
2. ARIN says, you can have a /18. ARIN also reserves the entire /16 in
the expectation that I will come back.
3. Next time, I ask for and justify a /16
4. ARIN give me a /16 and the reserved addresses go into limbo, hoping
that my network growth slows down sometime before armageddon so that can
allocate it in /18 blocks.

Even though it is odd to get non-CIDR blocks, I think that ARIN did the
right thing and that policy ahould not specify bit-aligned prefixes.

> > It might be a good idea to think this through and see 
> whether or not 
> > it can be simplified to say that ARIN will never allocate 
> more than 4 
> > blocks to satisfy a request, and leave off the bit about 
> when there is 
> > insufficient free space.
> 
> Having thought that through, I believe it would complicate 
> the policy and reduce clarity. Brevity is not always simplicity.

I don't want YOU to think it through, I want US to think it through.

I think that it should be possible to come up with a change to current
policy that would not negatively impact current activities and that
would also prevent breadcrumb sweeping without requiring a specific
trigger event for the policy.

--Michael Dillon


From owen at delong.com  Thu Apr 29 12:12:20 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 29 Apr 2010 09:12:20 -0700
Subject: [arin-ppml] IPv4 Fragment Managemnt policy proposal
In-Reply-To: <4BD98E4F.8000306@chl.com>
References: <8AEAA82D-9BA6-408F-B256-157D61C952CB@delong.com>
	<4BD98E4F.8000306@chl.com>
Message-ID: <8D08558B-E30C-4540-9161-898B73962B2E@delong.com>


On Apr 29, 2010, at 6:49 AM, Joe Maimon wrote:

> 
> 
> Owen DeLong wrote:
>> At ARIN XXV, one of the discussions pointed out that under current
>> ARIN policy, after IANA runout, a justified request for a /10 could
>> (and would) be satisfied, if necessary, by issuing 1024 disjoint /20s.
>> 
>> I believe there is a need for policy to prevent this kind of
>> gathering of the last breadcrumbs by a small number of large
>> entities. As such, I offer the following proposal for the discussion
>> of the community.
>> 
>> Owen
> 
> 
> I agree with the intent and support the policy proposal. I will also note that PP110 deals with this head on, but the two are not incompatible in either intent or effect.
> 
PP 110 does this in a way that singles out particular classes of organization at the expense of others. This policy proposal allows all organizations to get IP resources while they are available, but, limits the number of the remaining crumbs of address space that may be cornered by any one organization at a time.

> 
>> Add the following to the NRPM as new sections 4.2.1.7 et. seq.
>> 
>> Each time ARIN approves an IPv4 request which it cannot
>> satisfy from 4 or fewer bit-aligned blocks of free address
>> space
> 
> 
> This could be somewhat confusing. I would support a simple 1 request == 1 NEW prefix + possible adjustments to old prefixes, which could differ from current practice.
> 
Why is it confusing?  Let's say the remaining free pool contains:

250 /22s
100 /20s
18 /19s
5 /14s
1 /12

(total prefix equivalents /11 + /13 + /14 + /15 + /16 + 2 /17 + /18 + /19 + /21)


A request comes in for a /9 and is approved.

The organization requesting the /9 would have the option of receiving {1x/12, 3x/14}.

They would not have the option of receiving {1x/12, 5x/14, 18x/19, 100x/20, 250x/22}.

IOW, the request for the /9 cannot be filled and they get the 4 largest blocks
available.

I don't think it would be fair to limit the /9 requestor to a single /12 when there is a
stack of /14s sitting right next to it.

An organization requesting a /20 that is approved would receive one of the
remaining /20s under business as usual.

I can understand the "bitmath is hard let's go shopping" concept if
the applicant was going to need to identify the largest available
sub-blocks, etc. However, this is very simple from the end user's
perspective.  All the "hard math" is handled by ARIN's systems.

The requestor says "I need a /9".

ARIN approves the request, looks in their allocation system and sees
they don't have a /9 available and cannot manufacture one from four
or fewer remaining pieces.  The system automatically offers up
the {1x /12, 3x/14} recipe. ARIN offers this to the requestor on a
basically here's what we can give you if you like basis.  The
requestor says yes or no. Simple.

Now let's see if we can find the corner cases, etc...

Given the same free pool (let's assume the /9 didn't want the pieces
and went away to try their luck on the transfer market)...

Request for a /10 -- Same results as the /9. (and off to the transfer
market he goes, also.. The free pool remains in tact).

Note: Both the /9 and the /10 could not be completely filled anyway. The
total free space is less than  a /10.

Request for a /11 -- While there is actually a /11 total space in the free pool,
this request would still receive only a partial fill. They would receive the same
four possible blocks {1x/12, 3x/14} as the previous 2 requests. A /11 is
equivalent to 8x/14. This requestor would receive address space which
is equivalent to 7x/14 or 87.5% of what he requested.

As such, I think that this policy is significantly more fair than PP 110 as
it does not exclude large organizations from getting reasonable proportions
of the remaining crumbs of address space while preventing any single
request from wiping out a significant number of crumbs.

>> 
>> 8. Rationale:
>> 
>> When the ARIN free pool begins to diminish, the free space
>> will become fragmented into smaller and smaller remaining
>> contiguous spaces. This policy attempts to ensure that a
>> large number of remaining disjoint small blocks are not
>> consumed by a single large request.
> 
> 
> I question the effectiveness of any proposal that could be defeated simply by inundating ARIN with multiple smaller requests if the objective of the requester cannot be achieved via a single large request.
> 
1.	This won't work because the second request will need to demonstrate
	effective utilization of the space issued under the first request.  Processing
	time on the first request alone will place your second request significantly
	further back in the queue.

> Unless constrained by policy, larger entities would easily be able to muster the manpower required to inundate ARIN with many justified small requests, either successively or concurrently.
> 
2.	Concurrent requests would be rejected as duplicates or consolidated. (I have
	seen ARIN catch these in the past when multiple administrators at the same
	company did not realize the other was working on the request).

> As I currently understand it, the 12 or 3 month window are maximums, not minimums.
> 
You can justify a maximum of 12 (3) months worth of space in a single request, correct.
You can make a subsequent request at any time, so long as you can show efficient
utilization of your previous requests.

IOW, the large organization would have to:

1.	Submit request
2.	Get request approved (some delay here, days if ARIN is "innundated").
3.	Accept sub-fill.
4.	Make utilization of addresses and SWIP it.
5.	Prepare subsequent request (some delay here, 9 women cannot have a baby in 1 month)
6.	Goto 1.

In the time elapsed between 2 and 6, there is likely a significant number of
organizations in the queue ahead of them.

As such, I think there are already sufficient safeguards in this case.

>> 
>> While this policy could be regarded as unfair to larger
>> entities,
> 
> I think we need to ask ourselves a few questions:
> 
> Is it possible to do anything that would not be perceived as unfair to segments of the ARIN community?
> 
Of course not.

> What about inaction?
> 
Probably not the most fair thing to do, but, almost certainly the safest.

> Have some segments of the ARIN community received or are perceived to have received more than their fair share of fairness to date?
> 
That depends to a great extent on your perspective. Obviously it is your perspective that large and x-large organizations have.
I am not convinced that is true.

> Might it not be time for them to repay the balance?
> 
This assumes facts not in evidence... Namely that the answer to the previous question is yes.

> Could not it be considered that the only policy that is fair to large entities would be one that levels the field between them, by denying them resources equally, instead of potentially allowing one of them to gain a few month (or longer) advantage over the others?
> 
There is actually no way to accomplish this, and, even if there were, it would not actually be fair.

> Do we believe that IPv4 players large and small will begin an orderly transition to IPv6 when faced with real resource scarcity or do we expect or suspect chaos and crisis?
> 
Probably a little of both.

> If there is a real chance of chaos and crisis, are we doing the best we can to prepare and attempt to mitigate?
> 
I don't think ARIN's role is to mitigate the chaos and crisis of individual ISPs choices on IPv6 transition. I think ARIN's role is to manage the remaining address space in a manner which is responsible, technically sound, and in line with the intent of the community as expressed through the policy development process.

> Damned if we do, damned if we dont - is the question one of how hot will hell be?
> 
Pretty much.

> 
>> 
>> 9. Timetable for implementation: Immediate, although it has no
>> actual effect until some time after IANA runout.
> 
> Only due to detail, but not due to intent. Edits could easily change that.
> 
I do not believe such a change would be beneficial to the policy or the
community.

Owen



From jcurran at arin.net  Thu Apr 29 16:10:23 2010
From: jcurran at arin.net (John Curran)
Date: Thu, 29 Apr 2010 16:10:23 -0400
Subject: [arin-ppml]  IPv3.com
Message-ID: <AB63290A-BC09-4EF0-81DA-95308B5FC446@arin.net>

Acting on the recommendation of the ARIN Mailing List AUP Committee, 
sender "IPv3.com <ipv3.com at gmail.com>" has been warned about messages
in violation of the AUP, and potential loss of posting privileges to 
ARIN Mailing Lists if further violations should occur.

FYI,
/John

John Curran 
President and CEO
ARIN


From JOHN at egh.com  Thu Apr 29 22:40:28 2010
From: JOHN at egh.com (John Santos)
Date: Thu, 29 Apr 2010 22:40:28 -0400
Subject: [arin-ppml] IPv4 Fragment Managemnt policy proposal
In-Reply-To: <8D08558B-E30C-4540-9161-898B73962B2E@delong.com>
Message-ID: <1100429222011.3243A-100000@Ives.egh.com>

On Thu, 29 Apr 2010, Owen DeLong wrote:

> 
> 
> I can understand the "bitmath is hard let's go shopping" concept if
> the applicant was going to need to identify the largest available
> sub-blocks, etc. However, this is very simple from the end user's
> perspective.  All the "hard math" is handled by ARIN's systems.

Um, I think that what people were objecting to was the proposal
(requirement of bit-aligned blocks) would make it impossible for
ARIN to expand existing blocks when possible, which is current
policy.

For example, if a org has a /18 and qualifies for an additional
/16 (4 more /18s) and the /16 that starts with their current /18 is
available (as a /18 and a /17), then currently ARIN would assign
/allocate theremainder of the /16 and the org would have effectively
plus another /18 to get them their full allocation in only 2 blocks.
But the bit-alignment criteria would apparently force ARIN to treat
the /16 (3/4ths of which is available) as a /18 followed by a /17,
or as 3 /18s, with org potentially ending up with 4 random /18s.
In this case, its a wash since they don't go over their 4-block
limit, but I can imagine there are many cases where if they hold
multiple blocks, several of which could be extended, their would
be unnecessary fragmentation.

I think a single clause saying that extending an existing address
block counts as single block under the 4-block limit of this
proposal (in cases where even if the additional block(s) aren't bit
aligned, the resulting block, including the original block, is
aligned.)

Maybe this is mathematically impossible, or statistically very
unlikely?

But the point is the policy shouldn't force unnecessary deaggregation.

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539



From owen at delong.com  Thu Apr 29 23:48:16 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 29 Apr 2010 20:48:16 -0700
Subject: [arin-ppml] IPv4 Fragment Managemnt policy proposal
In-Reply-To: <1100429222011.3243A-100000@Ives.egh.com>
References: <1100429222011.3243A-100000@Ives.egh.com>
Message-ID: <2982213E-42F9-4C58-A961-3E6A9E59B3B3@delong.com>


On Apr 29, 2010, at 7:40 PM, John Santos wrote:

> On Thu, 29 Apr 2010, Owen DeLong wrote:
> 
>> 
>> 
>> I can understand the "bitmath is hard let's go shopping" concept if
>> the applicant was going to need to identify the largest available
>> sub-blocks, etc. However, this is very simple from the end user's
>> perspective.  All the "hard math" is handled by ARIN's systems.
> 
> Um, I think that what people were objecting to was the proposal
> (requirement of bit-aligned blocks) would make it impossible for
> ARIN to expand existing blocks when possible, which is current
> policy.
> 
> For example, if a org has a /18 and qualifies for an additional
> /16 (4 more /18s) and the /16 that starts with their current /18 is
> available (as a /18 and a /17), then currently ARIN would assign
> /allocate theremainder of the /16 and the org would have effectively
> plus another /18 to get them their full allocation in only 2 blocks.
> But the bit-alignment criteria would apparently force ARIN to treat
> the /16 (3/4ths of which is available) as a /18 followed by a /17,
> or as 3 /18s, with org potentially ending up with 4 random /18s.
> In this case, its a wash since they don't go over their 4-block
> limit, but I can imagine there are many cases where if they hold
> multiple blocks, several of which could be extended, their would
> be unnecessary fragmentation.
> 
Ah... That is outside of the intent.  I will review and revise the
proposal to account for this.  The intent is to prevent ARIN from
granting someone a new allocation which contains 1.5 /20s
taken from a clean /19 or something like that.

> I think a single clause saying that extending an existing address
> block counts as single block under the 4-block limit of this
> proposal (in cases where even if the additional block(s) aren't bit
> aligned, the resulting block, including the original block, is
> aligned.)
> 
Agreed.

> Maybe this is mathematically impossible, or statistically very
> unlikely?
> 
I suspect in the end game, block extensions will be very rare, indeed.

> But the point is the policy shouldn't force unnecessary deaggregation.
> 
Agreed.  The intent of the bit-alignment clause was to prevent, not
create unnecessary deaggregation. I believe that section 8.3 will
do more than enough of that.


Owen



From owen at delong.com  Fri Apr 30 12:17:02 2010
From: owen at delong.com (Owen DeLong)
Date: Fri, 30 Apr 2010 09:17:02 -0700
Subject: [arin-ppml] x-small IPv4 ISPs going to IPv6
In-Reply-To: <2B842A75-E1E6-4B8F-820D-DA3C25148C62@delong.com>
References: <50EE5968-A41E-4BBD-92FE-6F025765E5F2@delong.com>
	<FEA070315E40A3489D38398C35FE7BB279DD04DF31@EDAMAME.arin.net>
	<327D7E22-D689-4F39-9B62-80439653D126@delong.com>
	<FEA070315E40A3489D38398C35FE7BB279DD3B2124@EDAMAME.arin.net>
	<2B842A75-E1E6-4B8F-820D-DA3C25148C62@delong.com>
Message-ID: <83307504-F093-40A4-AB06-8E78C6066B7C@delong.com>



As a data point, there are currently 866* x-small IPv4 ISP organizations in the ARIN region.

There are a total of 3,562* ISP organizations in the ARIN region (including IPv4 and IPv6).

x-small IPv4 providers as such, constitute about 1/4 of the total ARIN ISP constituency.

The maximum revenue impact of an IPv6 waiver for them (removing the $1,000 surcharge
for IPv6 /32 pricing) would be $833,000 per year, increasing as the number of organizations
affected by the waiver increased.

This information is provided strictly as a data point and not in the interests of pushing
the discussion in either direction.

Owen


*The data I used to produce these numbers comes from ARIN staff and is current as of
earlier April 29, 2010. ARIN will be publishing the data to their statistics page in the next few
days. Please don't blame staff for the publication delay. I asked for the numbers late
last night and they have been extremely responsive in getting the data to me and have
taken the additional initiative to publish it as quickly as they can within their process.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100430/2a5987a4/attachment.htm>

From NOC at ChangeIP.com  Fri Apr 30 13:21:53 2010
From: NOC at ChangeIP.com (NOC at ChangeIP.com)
Date: Fri, 30 Apr 2010 10:21:53 -0700
Subject: [arin-ppml] x-small IPv4 ISPs going to IPv6
References: <50EE5968-A41E-4BBD-92FE-6F025765E5F2@delong.com><FEA070315E40A3489D38398C35FE7BB279DD04DF31@EDAMAME.arin.net><327D7E22-D689-4F39-9B62-80439653D126@delong.com><FEA070315E40A3489D38398C35FE7BB279DD3B2124@EDAMAME.arin.net><2B842A75-E1E6-4B8F-820D-DA3C25148C62@delong.com>
	<83307504-F093-40A4-AB06-8E78C6066B7C@delong.com>
Message-ID: <F4B854F30B8A43C19D5F5393BBEAC2F9@changeip.com>

> x-small IPv4 providers as such,
> constitute about 1/4 of the total ARIN ISP constituency.

So 1/4 of the current IPv4 ARIN community will have to pay something to get 
IPv6... which will hinder IPv6 rollout in my opinion.  If we truly want 
people to transition now we need to make their initial small ipv6 allocation 
at no additional cost if they are already paying for x-small ipv4.

"6.4.3. Minimum Allocation
The minimum allocation size for IPv6 address space is /32."

which is $2,250/yr, more than the $1,250/yr that they are currently paying. 
The x-small ipv6 allocation on the fee schedule is misleading since you 
can't even get it.

Don't start with the $1,000/yr is nothing; its the cost of a PC for an 
employee argument... it all comes back to do you really want IPv6 rollout to 
succeed or not.  I personally am holding out on ISP v6 block because I don't 
want the extra cost.  I can't get anything from my upstreams (level3, 
cogent) because ipv6 isn't available thru them.

Thx,
Sam 



From joelja at bogus.com  Fri Apr 30 13:37:00 2010
From: joelja at bogus.com (joel jaeggli)
Date: Fri, 30 Apr 2010 10:37:00 -0700
Subject: [arin-ppml] x-small IPv4 ISPs going to IPv6
In-Reply-To: <F4B854F30B8A43C19D5F5393BBEAC2F9@changeip.com>
References: <50EE5968-A41E-4BBD-92FE-6F025765E5F2@delong.com><FEA070315E40A3489D38398C35FE7BB279DD04DF31@EDAMAME.arin.net><327D7E22-D689-4F39-9B62-80439653D126@delong.com><FEA070315E40A3489D38398C35FE7BB279DD3B2124@EDAMAME.arin.net><2B842A75-E1E6-4B8F-820D-DA3C25148C62@delong.com>	<83307504-F093-40A4-AB06-8E78C6066B7C@delong.com>
	<F4B854F30B8A43C19D5F5393BBEAC2F9@changeip.com>
Message-ID: <4BDB153C.9090700@bogus.com>

On 4/30/2010 10:21 AM, NOC at ChangeIP.com wrote:
> I can't get anything from my upstreams (level3, cogent) because ipv6 isn't available thru them.


I think level-3 would disagree with that statement.

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



From ggiesen at akn.ca  Fri Apr 30 14:19:49 2010
From: ggiesen at akn.ca (Gary T. Giesen)
Date: Fri, 30 Apr 2010 14:19:49 -0400
Subject: [arin-ppml] x-small IPv4 ISPs going to IPv6
In-Reply-To: <F4B854F30B8A43C19D5F5393BBEAC2F9@changeip.com>
References: <50EE5968-A41E-4BBD-92FE-6F025765E5F2@delong.com>
	<FEA070315E40A3489D38398C35FE7BB279DD04DF31@EDAMAME.arin.net>
	<327D7E22-D689-4F39-9B62-80439653D126@delong.com>
	<FEA070315E40A3489D38398C35FE7BB279DD3B2124@EDAMAME.arin.net>
	<2B842A75-E1E6-4B8F-820D-DA3C25148C62@delong.com>
	<83307504-F093-40A4-AB06-8E78C6066B7C@delong.com>
	<F4B854F30B8A43C19D5F5393BBEAC2F9@changeip.com>
Message-ID: <1272651589.13180.238.camel@ggiesen-workstation.netsurf.net>

If you currently have an X-Small from ARIN, it costs you nothing right
now because of the 50% fee waiver in effect.

GG

On Fri, 2010-04-30 at 13:21 -0400, NOC at ChangeIP.com wrote:
> > x-small IPv4 providers as such,
> > constitute about 1/4 of the total ARIN ISP constituency.
> 
> So 1/4 of the current IPv4 ARIN community will have to pay something to get 
> IPv6... which will hinder IPv6 rollout in my opinion.  If we truly want 
> people to transition now we need to make their initial small ipv6 allocation 
> at no additional cost if they are already paying for x-small ipv4.
> 
> "6.4.3. Minimum Allocation
> The minimum allocation size for IPv6 address space is /32."
> 
> which is $2,250/yr, more than the $1,250/yr that they are currently paying. 
> The x-small ipv6 allocation on the fee schedule is misleading since you 
> can't even get it.
> 
> Don't start with the $1,000/yr is nothing; its the cost of a PC for an 
> employee argument... it all comes back to do you really want IPv6 rollout to 
> succeed or not.  I personally am holding out on ISP v6 block because I don't 
> want the extra cost.  I can't get anything from my upstreams (level3, 
> cogent) because ipv6 isn't available thru them.
> 
> Thx,
> Sam 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From mksmith at adhost.com  Fri Apr 30 14:34:26 2010
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Fri, 30 Apr 2010 11:34:26 -0700
Subject: [arin-ppml] x-small IPv4 ISPs going to IPv6
In-Reply-To: <F4B854F30B8A43C19D5F5393BBEAC2F9@changeip.com>
References: <50EE5968-A41E-4BBD-92FE-6F025765E5F2@delong.com><FEA070315E40A3489D38398C35FE7BB279DD04DF31@EDAMAME.arin.net><327D7E22-D689-4F39-9B62-80439653D126@delong.com><FEA070315E40A3489D38398C35FE7BB279DD3B2124@EDAMAME.arin.net><2B842A75-E1E6-4B8F-820D-DA3C25148C62@delong.com><83307504-F093-40A4-AB06-8E78C6066B7C@delong.com>
	<F4B854F30B8A43C19D5F5393BBEAC2F9@changeip.com>
Message-ID: <17838240D9A5544AAA5FF95F8D52031607EE1961@ad-exh01.adhost.lan>

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of NOC at ChangeIP.com
> Sent: Friday, April 30, 2010 10:22 AM
> To: Owen DeLong; arin ppml
> Subject: Re: [arin-ppml] x-small IPv4 ISPs going to IPv6
> 
<snip>
> 
> Don't start with the $1,000/yr is nothing; its the cost of a PC for an
> employee argument... it all comes back to do you really want IPv6
> rollout to
> succeed or not.  I personally am holding out on ISP v6 block because I
> don't
> want the extra cost.  I can't get anything from my upstreams (level3,
> cogent) because ipv6 isn't available thru them.
> 

Both Level 3 and Cogent have a v6 offering.

2001:200::/32    7193    100      0 3356 2914 2500 i
2001:550::/32    7193    140      0 3356 174 i

Mike


From ggiesen at akn.ca  Fri Apr 30 14:47:56 2010
From: ggiesen at akn.ca (Gary T. Giesen)
Date: Fri, 30 Apr 2010 14:47:56 -0400
Subject: [arin-ppml] x-small IPv4 ISPs going to IPv6
In-Reply-To: <17838240D9A5544AAA5FF95F8D52031607EE1961@ad-exh01.adhost.lan>
References: <50EE5968-A41E-4BBD-92FE-6F025765E5F2@delong.com>
	<FEA070315E40A3489D38398C35FE7BB279DD04DF31@EDAMAME.arin.net>
	<327D7E22-D689-4F39-9B62-80439653D126@delong.com>
	<FEA070315E40A3489D38398C35FE7BB279DD3B2124@EDAMAME.arin.net>
	<2B842A75-E1E6-4B8F-820D-DA3C25148C62@delong.com>
	<83307504-F093-40A4-AB06-8E78C6066B7C@delong.com>
	<F4B854F30B8A43C19D5F5393BBEAC2F9@changeip.com>
	<17838240D9A5544AAA5FF95F8D52031607EE1961@ad-exh01.adhost.lan>
Message-ID: <1272653276.13180.279.camel@ggiesen-workstation.netsurf.net>

Keep in mind that even if they offer IPv6, they may not offer it
everywhere...

GG

On Fri, 2010-04-30 at 14:34 -0400, Michael K. Smith - Adhost wrote:
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> On
> > Behalf Of NOC at ChangeIP.com
> > Sent: Friday, April 30, 2010 10:22 AM
> > To: Owen DeLong; arin ppml
> > Subject: Re: [arin-ppml] x-small IPv4 ISPs going to IPv6
> > 
> <snip>
> > 
> > Don't start with the $1,000/yr is nothing; its the cost of a PC for an
> > employee argument... it all comes back to do you really want IPv6
> > rollout to
> > succeed or not.  I personally am holding out on ISP v6 block because I
> > don't
> > want the extra cost.  I can't get anything from my upstreams (level3,
> > cogent) because ipv6 isn't available thru them.
> > 
> 
> Both Level 3 and Cogent have a v6 offering.
> 
> 2001:200::/32    7193    100      0 3356 2914 2500 i
> 2001:550::/32    7193    140      0 3356 174 i
> 
> Mike
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From NOC at ChangeIP.com  Fri Apr 30 15:03:39 2010
From: NOC at ChangeIP.com (NOC at ChangeIP.com)
Date: Fri, 30 Apr 2010 12:03:39 -0700
Subject: [arin-ppml] x-small IPv4 ISPs going to IPv6
References: <50EE5968-A41E-4BBD-92FE-6F025765E5F2@delong.com><FEA070315E40A3489D38398C35FE7BB279DD04DF31@EDAMAME.arin.net><327D7E22-D689-4F39-9B62-80439653D126@delong.com><FEA070315E40A3489D38398C35FE7BB279DD3B2124@EDAMAME.arin.net><2B842A75-E1E6-4B8F-820D-DA3C25148C62@delong.com><83307504-F093-40A4-AB06-8E78C6066B7C@delong.com>
	<F4B854F30B8A43C19D5F5393BBEAC2F9@changeip.com>
	<17838240D9A5544AAA5FF95F8D52031607EE1961@ad-exh01.adhost.lan>
Message-ID: <98F41070620441E5A5BBAF0AFE2F0981@changeip.com>

> Both Level 3 and Cogent have a v6 offering.
> 2001:200::/32    7193    100      0 3356 2914 2500 i
> 2001:550::/32    7193    140      0 3356 174 i

Level3 cannot give us IPv6 in San Diego.  Not even tunnels.  We are told 
their 'beta' trial isn't open anymore.  We've been asking for 2 years now. 
We use 100+mbps on their network.

Cogent has finally given us native IPv6 here in San Diego, however, we can 
only reach about 1/3 of the IPv6 net using it since they don't peer with 
many people.  If we used Cogent assigned IPv6 only a few would be able to 
reach us.  We are forced to use the Tunnelbroker service to even get to 
ARINs website using IPv6.

IPv6 from an upstream is another problem / topic.

Sam 



From tedm at ipinc.net  Fri Apr 30 14:53:43 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 30 Apr 2010 11:53:43 -0700
Subject: [arin-ppml] [arin-discuss] x-small IPv4 ISPs going to IPv6
In-Reply-To: <C3F4CA6C-5522-4822-A2ED-B39D31957A94@delong.com>
References: <50EE5968-A41E-4BBD-92FE-6F025765E5F2@delong.com>	<FEA070315E40A3489D38398C35FE7BB279DD04DF31@EDAMAME.arin.net>	<327D7E22-D689-4F39-9B62-80439653D126@delong.com>	<FEA070315E40A3489D38398C35FE7BB279DD3B2124@EDAMAME.arin.net>	<2B842A75-E1E6-4B8F-820D-DA3C25148C62@delong.com>
	<C3F4CA6C-5522-4822-A2ED-B39D31957A94@delong.com>
Message-ID: <4BDB2737.70400@ipinc.net>

Owen,

Now just hold on there.

This $833,000 figure is POTENTIAL revenue.
You cannot have a "revenue impact" on revenue you have not collected
and are not expected to collect.  Further ARIN is a non-profit.  It is
ILLEGAL for it to NOT hand that money back to the customer base - and
it must do it by LOWERING FEES.

   Your terminology is ASSUMING that if the waiver expires in 2012 that
all of the x-small IPv4 holders will pony up the $1000 for IPv6.  If
that happens ARIN realizes an extra $833,000 - and any waiver we do
would then have an $833,000 "revenue impact"

   But the liklihood is they will NOT pony that money up.  Thus ARIN
is NEVER going to realize that extra $833,000 and thus cannot "lose"
it if we put in a waiver.

   If you really want to know the true revenue impact in 2012 then 
here's how to find it out.

fist, you have to ask the ARIN staff to break the 866 x-small ISP's down 
into ISP's that have x-small Legacy holdings and thus currently pay 
-nothing- to ARIN and x-small ISP's that are paying the $1250.00 a year.

Reason being is that the freeloaders ARE NEVER going to go to IPv6
unless we waive it down to nothing for them.  And I don't think that
ANYONE (except for the Legacy holders) wants to perpetuate the "free
if you got your IP before the Dinosaurs lived" business in IPv6.

Any waiver of 2011 and 2012 would ONLY affect the x-small IPv4 holders
paying the $1250.00 right now - by definition, NON legacy x-small IPv4
holders.

Secondly, even with a modification of the current waiver to 50% for 2011
and 50% for 2012 for the Small /32 IPv6 category, (which is what -I-
have been advocating) a lot of those x-small ISPs will STILL NOT go to 
IPv6 before 2012.  Thus the only "revenue impacts" would be for the ones 
that WENT FOR IT.

If 76 out of the 866 x-small ISP's took advantage of a 50% waiver in 
2011 and 2012 the unrealized income to ARIN would be $42,000 in 2011
and $76,000 in 2012

Lastly, there is also the chance to phase this in much more gradually.

To do this we have to face the following facts:

The inevitability of IPv6 means the x-small ISPs are eventually going
to all have to be paying the $2250 for the Small IPv6 allocation.  This
means the Legacy x-small holders who are paying nothing now, are going 
to have to pay the $2250 and the non-legacy x-smalls are going to have 
to pay an extra $1000

This represents a permanent income increase to ARIN.  You have named off
a figure of .8 million a year.  OK whatever.  I think it will be higher
but without x-small Legacy holder figures I'll go with the .8 million.

Right now ARIN doesen't have this .8 million - but when the day comes
that the x-smalls HAVE to have IPv6 then it WILL have the .8 million.

Let's rub the crystal ball a moment and assume that this date will be
2015 - 3 years after the "end of virgin RIR assignments"

If the waiver is allowed to disappear then few x-smalls will go to
IPv6 before this "must have" date.  That represents an .8 mil a year
loss to ARIN commencing from 2012 to the "must have" date of 2015
- using your logic of "it's ours before we have it" financial analysis.
:-)

ARIN can say "well if we drop the waiver to 40% how many additonal
x-smalls will sign up and what money do we make"

These are the same "what-if" games that retailers play when they
set store "It's the blow-out 50% off sale" prices.  I don't have
experience with those but they obviously work.  The additional
revenue ARIN collects must go towards lowering fees - thus if
we waive it now, and more x-smalls buy in, then the price they
buy-in at drops.

Obviously this all goes away on the "must have" date.  If the
x-smalls can't hack it then, then they never will.  But until that
date, the pricing for this category should be set in a manner as
to encourage the x-smalls to get into IPv6 as much as possible.

Ted

On 4/30/2010 9:17 AM, Owen DeLong wrote:
>
>
> As a data point, there are currently 866* x-small IPv4 ISP organizations in the ARIN region.
>
> There are a total of 3,562* ISP organizations in the ARIN region (including IPv4 and IPv6).
>
> x-small IPv4 providers as such, constitute about 1/4 of the total ARIN ISP constituency.
>
> The maximum revenue impact of an IPv6 waiver for them (removing the $1,000 surcharge
> for IPv6 /32 pricing) would be $833,000 per year, increasing as the number of organizations
> affected by the waiver increased.
>
> This information is provided strictly as a data point and not in the interests of pushing
> the discussion in either direction.
>
> Owen
>
>
> *The data I used to produce these numbers comes from ARIN staff and is current as of
> earlier April 29, 2010. ARIN will be publishing the data to their statistics page in the next few
> days. Please don't blame staff for the publication delay. I asked for the numbers late
> last night and they have been extremely responsive in getting the data to me and have
> taken the additional initiative to publish it as quickly as they can within their process.
>
>
>
>
> _______________________________________________
> ARIN-Discuss
> You are receiving this message because you are subscribed to
> the ARIN Discussion Mailing List (ARIN-discuss at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-discuss
> Please contact info at arin.net if you experience any issues.


From owen at delong.com  Fri Apr 30 15:00:07 2010
From: owen at delong.com (Owen DeLong)
Date: Fri, 30 Apr 2010 12:00:07 -0700
Subject: [arin-ppml] x-small IPv4 ISPs going to IPv6
In-Reply-To: <F4B854F30B8A43C19D5F5393BBEAC2F9@changeip.com>
References: <50EE5968-A41E-4BBD-92FE-6F025765E5F2@delong.com><FEA070315E40A3489D38398C35FE7BB279DD04DF31@EDAMAME.arin.net><327D7E22-D689-4F39-9B62-80439653D126@delong.com><FEA070315E40A3489D38398C35FE7BB279DD3B2124@EDAMAME.arin.net><2B842A75-E1E6-4B8F-820D-DA3C25148C62@delong.com>
	<83307504-F093-40A4-AB06-8E78C6066B7C@delong.com>
	<F4B854F30B8A43C19D5F5393BBEAC2F9@changeip.com>
Message-ID: <4AEC59C5-949F-4ED5-8316-F14B8BF183D7@delong.com>


On Apr 30, 2010, at 10:21 AM, <NOC at ChangeIP.com> wrote:

>> x-small IPv4 providers as such,
>> constitute about 1/4 of the total ARIN ISP constituency.
> 
> So 1/4 of the current IPv4 ARIN community will have to pay something to get IPv6... which will hinder IPv6 rollout in my opinion.  If we truly want people to transition now we need to make their initial small ipv6 allocation at no additional cost if they are already paying for x-small ipv4.
> 
> "6.4.3. Minimum Allocation
> The minimum allocation size for IPv6 address space is /32."
> 
> which is $2,250/yr, more than the $1,250/yr that they are currently paying. The x-small ipv6 allocation on the fee schedule is misleading since you can't even get it.
> 
I'm not sure how, but, according to staff, there is 1 xtra-small IPv6 allocation.

> Don't start with the $1,000/yr is nothing; its the cost of a PC for an employee argument... it all comes back to do you really want IPv6 rollout to succeed or not.  I personally am holding out on ISP v6 block because I don't want the extra cost.  I can't get anything from my upstreams (level3, cogent) because ipv6 isn't available thru them.
> 
Note, also, that the entities subject to that additional charge currently do have a fee waiver that would more than cover the $1,000 for their IPv6 block, so, for now, it is actually free.

Owen



From Wesley.E.George at sprint.com  Fri Apr 30 15:20:06 2010
From: Wesley.E.George at sprint.com (George, Wes E IV [NTK])
Date: Fri, 30 Apr 2010 14:20:06 -0500
Subject: [arin-ppml] Policy Proposal 112: Utilization of 10.4.2
 resources only via explicit policy
In-Reply-To: <4BD9ACE6.1020301@arin.net>
References: <4BD9ACE6.1020301@arin.net>
Message-ID: <F7EB0A7C707E39409A73CD0353242551A89266E9D4@PLSWM01C.ad.sprint.com>

I oppose this proposal. Justified use and allocation of IPv4 address space under ARIN's current policy is justified use regardless of whether it is the last /8 or not. I agree that there are some reasons to hold addresses in reserve for transition items, but the existing policy already makes provision for that in the form of a /10. It is impossible to say that we as a community will know (and more importantly, agree on) 100% of the reasons why addresses should be allocated in the 10.4.2 endgame and can get them all documented in the policy process in a reasonable amount of time so that this is not an overly inflexible and limiting rule for ARIN staff and users of IPv4 space.

Thanks,
Wes

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services
Sent: Thursday, April 29, 2010 12:00 PM
To: arin-ppml at arin.net
Subject: [arin-ppml] Policy Proposal 112: Utilization of 10.4.2 resources only via explicit policy
## * ##


Policy Proposal Name: Utilization of 10.4.2 resources only via explicit
policy

Proposal Originator: Joe Maimon

Proposal Version: 1.0

Date: 29 April 2010

Proposal type: New

Policy term: permanent

Policy statement:

Add section 4.11

4.11 Last /8 utilization

Resources received from IANA under section 10.4.2 (the last /8) will be
unavailable for any purposes not explicitly specified, such as 4.10, and
will be held in reserve.

Rationale:

No reason to blow the last /8 as quickly as all the others.

Timetable for implementation: Concurrently with 10.4


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



From jmaimon at chl.com  Fri Apr 30 16:04:11 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Fri, 30 Apr 2010 16:04:11 -0400
Subject: [arin-ppml] Policy Proposal 112: Utilization of 10.4.2
 resources only via explicit policy
In-Reply-To: <F7EB0A7C707E39409A73CD0353242551A89266E9D4@PLSWM01C.ad.sprint.com>
References: <4BD9ACE6.1020301@arin.net>
	<F7EB0A7C707E39409A73CD0353242551A89266E9D4@PLSWM01C.ad.sprint.com>
Message-ID: <4BDB37BB.6080603@chl.com>

Hi George,

This /8 is not given to ARIN based upon need. It is given based upon its 
status as the last one available from the free pool. There is no 
implicit assumption that it should go to fill needs in the same manner 
as all previous ones. I see no reason that it should be squandered in 
the same manner as all the rest have without at minimum due 
consideration as to possible alternates.

If there wont be enough time to work out policy for this last /8 while 
holding it in reserve, then there definitely will not be time to work 
out policy before it is consumed -- too late. On the other hand, the 
policy process does have the ability to move quickly, such as the 
emergency pdp process.

4.10 is possibly not enough. We do not know yet.

Joe

George, Wes E IV [NTK] wrote:
> I oppose this proposal. Justified use and allocation of IPv4 address space under ARIN's current policy is justified use regardless of whether it is the last /8 or not. I agree that there are some reasons to hold addresses in reserve for transition items, but the existing policy already makes provision for that in the form of a /10. It is impossible to say that we as a community will know (and more importantly, agree on) 100% of the reasons why addresses should be allocated in the 10.4.2 endgame and can get them all documented in the policy process in a reasonable amount of time so that this is not an overly inflexible and limiting rule for ARIN staff and users of IPv4 space.
>
> Thanks,
> Wes
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services
> Sent: Thursday, April 29, 2010 12:00 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Policy Proposal 112: Utilization of 10.4.2 resources only via explicit policy
> ## * ##
>
>
> Policy Proposal Name: Utilization of 10.4.2 resources only via explicit
> policy
>
> Proposal Originator: Joe Maimon
>
> Proposal Version: 1.0
>
> Date: 29 April 2010
>
> Proposal type: New
>
> Policy term: permanent
>
> Policy statement:
>
> Add section 4.11
>
> 4.11 Last /8 utilization
>
> Resources received from IANA under section 10.4.2 (the last /8) will be
> unavailable for any purposes not explicitly specified, such as 4.10, and
> will be held in reserve.
>
> Rationale:
>
> No reason to blow the last /8 as quickly as all the others.
>
> Timetable for implementation: Concurrently with 10.4
>
>
> This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>


From BillD at cait.wustl.edu  Fri Apr 30 16:43:58 2010
From: BillD at cait.wustl.edu (Bill Darte)
Date: Fri, 30 Apr 2010 15:43:58 -0500
Subject: [arin-ppml] Policy Proposal 112: Utilization of 10.4.2
	resources only via explicit policy
References: <4BD9ACE6.1020301@arin.net><F7EB0A7C707E39409A73CD0353242551A89266E9D4@PLSWM01C.ad.sprint.com>
	<4BDB37BB.6080603@chl.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D030879151A9@ex1.cait.wustl.edu>

Hello Joe, George, community

I am the AC's policy shepherd assigned to this policy proposal.
I will be taking a passive role in monitoring the pro's and con's, the for's and against's.  I will also take an active role if I think further or different inquiry is needed on the subject, or if I am troubled by language or concepts that I believe need clarifying.

To that later end, I wonder, Joe, at your use of the language below...suggesting that existing policy in the assignment and/or allocation of /8 addresses is a 'squandering' of those resources.

If that were true, would you not be better off to proposal policy that remedies those ills?

Bill Darte
ARIN AC


-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Joe Maimon
Sent: Fri 4/30/2010 3:04 PM
To: George, Wes E IV [NTK]
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal 112: Utilization of 10.4.2 resources only via explicit policy
 
Hi George,

This /8 is not given to ARIN based upon need. It is given based upon its 
status as the last one available from the free pool. There is no 
implicit assumption that it should go to fill needs in the same manner 
as all previous ones. I see no reason that it should be squandered in 
the same manner as all the rest have without at minimum due 
consideration as to possible alternates.

If there wont be enough time to work out policy for this last /8 while 
holding it in reserve, then there definitely will not be time to work 
out policy before it is consumed -- too late. On the other hand, the 
policy process does have the ability to move quickly, such as the 
emergency pdp process.

4.10 is possibly not enough. We do not know yet.

Joe

George, Wes E IV [NTK] wrote:
> I oppose this proposal. Justified use and allocation of IPv4 address space under ARIN's current policy is justified use regardless of whether it is the last /8 or not. I agree that there are some reasons to hold addresses in reserve for transition items, but the existing policy already makes provision for that in the form of a /10. It is impossible to say that we as a community will know (and more importantly, agree on) 100% of the reasons why addresses should be allocated in the 10.4.2 endgame and can get them all documented in the policy process in a reasonable amount of time so that this is not an overly inflexible and limiting rule for ARIN staff and users of IPv4 space.
>
> Thanks,
> Wes
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services
> Sent: Thursday, April 29, 2010 12:00 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Policy Proposal 112: Utilization of 10.4.2 resources only via explicit policy
> ## * ##
>
>
> Policy Proposal Name: Utilization of 10.4.2 resources only via explicit
> policy
>
> Proposal Originator: Joe Maimon
>
> Proposal Version: 1.0
>
> Date: 29 April 2010
>
> Proposal type: New
>
> Policy term: permanent
>
> Policy statement:
>
> Add section 4.11
>
> 4.11 Last /8 utilization
>
> Resources received from IANA under section 10.4.2 (the last /8) will be
> unavailable for any purposes not explicitly specified, such as 4.10, and
> will be held in reserve.
>
> Rationale:
>
> No reason to blow the last /8 as quickly as all the others.
>
> Timetable for implementation: Concurrently with 10.4
>
>
> This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100430/e46ad92f/attachment.htm>

From Wesley.E.George at sprint.com  Fri Apr 30 16:47:47 2010
From: Wesley.E.George at sprint.com (George, Wes E IV [NTK])
Date: Fri, 30 Apr 2010 15:47:47 -0500
Subject: [arin-ppml] Policy Proposal 112: Utilization of 10.4.2
 resources only via explicit policy
In-Reply-To: <4BDB37BB.6080603@chl.com>
References: <4BD9ACE6.1020301@arin.net>
	<F7EB0A7C707E39409A73CD0353242551A89266E9D4@PLSWM01C.ad.sprint.com>
	<4BDB37BB.6080603@chl.com>
Message-ID: <F7EB0A7C707E39409A73CD0353242551A89266EACE@PLSWM01C.ad.sprint.com>


-----Original Message-----
From: Joe Maimon [mailto:jmaimon at chl.com]
Sent: Friday, April 30, 2010 4:04 PM

This /8 is not given to ARIN based upon need. It is given based upon its
status as the last one available from the free pool.
[[WEG]] yes, but it would have been allocated based on need otherwise. This just ensures that one RIR doesn't get left out on the final /8 because their run rate cycle is a little different than the others. It's not like ARIN wasn't going to need another /8 around the time that the last ones are being allocated, it's just a question of when.

There is no implicit assumption that it should go to fill needs in the same manner
as all previous ones. I see no reason that it should be squandered in
the same manner as all the rest have without at minimum due
consideration as to possible alternates.
[[WEG]] consideration of alternatives yes, but this last /8 shouldn't be a rainy day fund. If there are alternatives that people in the community believe are not adequately covered by existing policy that we should be reserving blocks for, make specific proposals. Otherwise, using what is available in a manner consistent with ARIN policy is not squandering addresses. IETF/IANA already reserved 16 /8s for "future use" (RFC 1112) and then waited so long to unreserve them that it's now impossible to take advantage of that space because nearly every piece of networking kit on the planet considers it unusable, and the required code changes would take longer than we have left. I just don't see much point in trying to reserve big blocks for "someday" without some concrete sense of when "someday" might be, and why we should care.

If there wont be enough time to work out policy for this last /8 while
holding it in reserve, then there definitely will not be time to work
out policy before it is consumed -- too late.
[[WEG]] Exactly my point. As with your last policy, it is my opinion that it is too late to make any substantive difference in either the runout timeframe or its effects on the Internet and businesses. QOS doesn't manufacture bandwidth any more than carving up and reserving addresses manufactures address space. All of these triggered rules simply complicate things for those of us with a plan underway for transitioning to IPv6 but a need for IPv4 until those plans are completely implemented, while offering those who don't have a plan (or worse, refuse to believe that there's a problem) a false sense of hope.

On the other hand, the policy process does have the ability to move quickly, such as the
emergency pdp process.
[[WEG]] A process which if used in this context will have lots and lots of people calling foul and unfair and non-transparent, etc. Note that I am not making commentary about the absence/presence of the Emergency PDP process nor what are justified uses of it. I am simply saying that at this point, policy changes around this area need to be carefully considered, consensus-based, open, transparent, and deterministic. Otherwise, it simply invites further scrutiny because it creates the impression that ARIN is somehow changing the rules arbitrarily to the benefit of some and the detriment of others.

4.10 is possibly not enough. We do not know yet.
[[WEG]] No disagreement there, but as I said above, we're rapidly approaching the point where it really doesn't matter either way, so if there are legitimate uses, let's have them. Otherwise, run what you brung.

Thanks,
Wes


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



From jmaimon at chl.com  Fri Apr 30 17:52:36 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Fri, 30 Apr 2010 17:52:36 -0400
Subject: [arin-ppml] Policy Proposal 112: Utilization of 10.4.2
 resources only via explicit policy
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D030879151A9@ex1.cait.wustl.edu>
References: <4BD9ACE6.1020301@arin.net><F7EB0A7C707E39409A73CD0353242551A89266E9D4@PLSWM01C.ad.sprint.com>
	<4BDB37BB.6080603@chl.com>
	<EACF8B735E9CBA4B8BAF9E4165D030879151A9@ex1.cait.wustl.edu>
Message-ID: <4BDB5124.3090504@chl.com>

Hi Bill,

Current policy and intent of policy results in a reality that any 
normative need is justified. That has been and is good for the network 
and all its users and should continue up until the point where the 
resources to support it dont exist or (this is the point where we 
possibly diverge) the point where their lack of continued existence is 
imminent.

Global continued need for IPv4 will by necessity be redefined as when 
alternatives just wont work as well or at all or that their costs cannot 
be justified or borne.

If and when that mode of need comes into effect, previous utilization 
will appear in hindsight to have been profligate.

I believe we are nearing the point where foresight suggests that 
continued use of the last of the resources in the same manner of 
consumption as all the previous should be considered profligate.

This last /8 is not assigned to ARIN due to normative consumption need. 
It is assigned because it is the last of the freely available resources. 
As such, I feel it is an appropriate place to demarcate the manner of 
consumption in effect.

Normative need for IPv4 cannot continue to be satisfied for much longer 
with this last /8 anyways, so let us trade that for some security, 
insurance, save some ammo, keep a gallon of case in the can, cash under 
the carpet or whatever analogy suits your fancy, to be available if and 
when need has a much sharper definition.

Real benefit by attempting to artificially restrict normative 
utilization of IPv4 before real scarcity is at hand cannot be realized - 
just a multitude of harms. I neither support propose or advocate that.

The truth of the matter is that scarcity has been a constantly 
increasing factor, most of us recall how much easier it was to get 
larger amounts of space for comparatively less need the further back in 
time we go, even under the RiR regime and policy of similar language 
being in effect. Does nobody feel that the resources consumed then could 
have been put to much better use even at this point when there is still 
resources freely available? How would you feel ten years from now, if 
IPv6 doesnt erase IPv4 need and render this whole topic of mere historic 
interest, at best.

If IPv6 does erase IPv4 need, what was the harm? That it happened three 
months earlier?


Joe




Bill Darte wrote:
>
> Hello Joe, George, community
>
> I am the AC's policy shepherd assigned to this policy proposal.
> I will be taking a passive role in monitoring the pro's and con's, the 
> for's and against's.  I will also take an active role if I think 
> further or different inquiry is needed on the subject, or if I am 
> troubled by language or concepts that I believe need clarifying.
>
> To that later end, I wonder, Joe, at your use of the language 
> below...suggesting that existing policy in the assignment and/or 
> allocation of /8 addresses is a 'squandering' of those resources.
>
> If that were true, would you not be better off to proposal policy that 
> remedies those ills?
>
> Bill Darte
> ARIN AC
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net on behalf of Joe Maimon
> Sent: Fri 4/30/2010 3:04 PM
> To: George, Wes E IV [NTK]
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal 112: Utilization of 10.4.2 
> resources only via explicit policy
>
> Hi George,
>
> This /8 is not given to ARIN based upon need. It is given based upon its
> status as the last one available from the free pool. There is no
> implicit assumption that it should go to fill needs in the same manner
> as all previous ones. I see no reason that it should be squandered in
> the same manner as all the rest have without at minimum due
> consideration as to possible alternates.
>
> If there wont be enough time to work out policy for this last /8 while
> holding it in reserve, then there definitely will not be time to work
> out policy before it is consumed -- too late. On the other hand, the
> policy process does have the ability to move quickly, such as the
> emergency pdp process.
>
> 4.10 is possibly not enough. We do not know yet.
>
> Joe
>
> George, Wes E IV [NTK] wrote:
> > I oppose this proposal. Justified use and allocation of IPv4 address 
> space under ARIN's current policy is justified use regardless of 
> whether it is the last /8 or not. I agree that there are some reasons 
> to hold addresses in reserve for transition items, but the existing 
> policy already makes provision for that in the form of a /10. It is 
> impossible to say that we as a community will know (and more 
> importantly, agree on) 100% of the reasons why addresses should be 
> allocated in the 10.4.2 endgame and can get them all documented in the 
> policy process in a reasonable amount of time so that this is not an 
> overly inflexible and limiting rule for ARIN staff and users of IPv4 
> space.
> >
> > Thanks,
> > Wes
> >
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] 
> On Behalf Of Member Services
> > Sent: Thursday, April 29, 2010 12:00 PM
> > To: arin-ppml at arin.net
> > Subject: [arin-ppml] Policy Proposal 112: Utilization of 10.4.2 
> resources only via explicit policy
> > ## * ##
> >
> >
> > Policy Proposal Name: Utilization of 10.4.2 resources only via explicit
> > policy
> >
> > Proposal Originator: Joe Maimon
> >
> > Proposal Version: 1.0
> >
> > Date: 29 April 2010
> >
> > Proposal type: New
> >
> > Policy term: permanent
> >
> > Policy statement:
> >
> > Add section 4.11
> >
> > 4.11 Last /8 utilization
> >
> > Resources received from IANA under section 10.4.2 (the last /8) will be
> > unavailable for any purposes not explicitly specified, such as 4.10, and
> > will be held in reserve.
> >
> > Rationale:
> >
> > No reason to blow the last /8 as quickly as all the others.
> >
> > Timetable for implementation: Concurrently with 10.4
> >
> >
> > This e-mail may contain Sprint Nextel Company proprietary 
> information intended for the sole use of the recipient(s). Any use by 
> others is prohibited. If you are not the intended recipient, please 
> contact the sender and delete all copies of the message.
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
> >
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>


From jmaimon at chl.com  Fri Apr 30 18:07:41 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Fri, 30 Apr 2010 18:07:41 -0400
Subject: [arin-ppml] Policy Proposal 112: Utilization of 10.4.2
 resources only via explicit policy
In-Reply-To: <F7EB0A7C707E39409A73CD0353242551A89266EACE@PLSWM01C.ad.sprint.com>
References: <4BD9ACE6.1020301@arin.net>
	<F7EB0A7C707E39409A73CD0353242551A89266E9D4@PLSWM01C.ad.sprint.com>
	<4BDB37BB.6080603@chl.com>
	<F7EB0A7C707E39409A73CD0353242551A89266EACE@PLSWM01C.ad.sprint.com>
Message-ID: <4BDB54AD.8050303@chl.com>



George, Wes E IV [NTK] wrote:
> -----Original Message-----
> From: Joe Maimon [mailto:jmaimon at chl.com]
> Sent: Friday, April 30, 2010 4:04 PM
>
> This /8 is not given to ARIN based upon need. It is given based upon its
> status as the last one available from the free pool.
> [[WEG]] yes, but it would have been allocated based on need otherwise. This just ensures that one RIR doesn't get left out on the final /8 because their run rate cycle is a little different than the others. It's not like ARIN wasn't going to need another /8 around the time that the last ones are being allocated, it's just a question of when.
>    

I dont agree. It is a behavioral departure no matter which semantics are 
brought to bear.

> [[WEG]] consideration of alternatives yes, but this last /8 shouldn't be a rainy day fund. If there are alternatives that people in the community believe are not adequately covered by existing policy that we should be reserving blocks for, make specific proposals.


I have done so in PP110. However, it is possible that the community may 
not form consensus about what they want to use it while they may form 
consensus that they want to use it for something specific. I would not 
find those two outcomes contradictory.

> Otherwise, using what is available in a manner consistent with ARIN policy is not squandering addresses. IETF/IANA already reserved 16 /8s for "future use" (RFC 1112) and then waited so long to unreserve them that it's now impossible to take advantage of that space because nearly every piece of networking kit on the planet considers it unusable, and the required code changes would take longer than we have left. I just don't see much point in trying to reserve big blocks for "someday" without some concrete sense of when "someday" might be, and why we should care.
>
>    
The story of Class E is an egregious case of resource squandering and it 
is actually infuriating that real effort to rectify that keeps getting 
delayed by the self-fulfilling recursive argument of delay until there 
is no benefit worth the effort.

Had it been done the first time it was realistically suggested it could 
have has real effect. In fact, it might still. We dont know that it wont.

However it is unlikely that history would repeat itself with this last 
/8, in its worst case it might make it onto bogon lists -- with which we 
have lots of experience with.

> If there wont be enough time to work out policy for this last /8 while
> holding it in reserve, then there definitely will not be time to work
> out policy before it is consumed -- too late.
> [[WEG]] Exactly my point. As with your last policy, it is my opinion that it is too late to make any substantive difference in either the runout timeframe or its effects on the Internet and businesses.
It is either too late, in which case it doesnt matter if it is used or 
not. Or it is not too late, in which case it may very well matter how it 
is used. So it behooves us to be conservative in this much, at the least.


>   QOS doesn't manufacture bandwidth any more than carving up and reserving addresses manufactures address space.

QoS is worse than the alternative of more bandwidth. It is better than 
the alternative of critical services/needs being unusable/unavailable 
with your existing bandwidth.

In this fashion it _WORKS_.

Yes, you hate it. I hate it too.

>   All of these triggered rules simply complicate things for those of us with a plan underway for transitioning to IPv6 but a need for IPv4 until those plans are completely implemented, while offering those who don't have a plan (or worse, refuse to believe that there's a problem) a false sense of hope.
>    
It is a real hope and it would have a real effect if it was really 
needed. If it is not really needed, than it wasnt a big deal in the 
first place.
> On the other hand, the policy process does have the ability to move quickly, such as the
> emergency pdp process.
> [[WEG]] A process which if used in this context will have lots and lots of people calling foul and unfair and non-transparent, etc. Note that I am not making commentary about the absence/presence of the Emergency PDP process nor what are justified uses of it. I am simply saying that at this point, policy changes around this area need to be carefully considered, consensus-based, open, transparent, and deterministic. Otherwise, it simply invites further scrutiny because it creates the impression that ARIN is somehow changing the rules arbitrarily to the benefit of some and the detriment of others.
>    
Since the community has preserved the Emergency PDP, it logically 
follows that it would be responsible to preserve something to allow 
emergency policy to work with, in an emergency.
> 4.10 is possibly not enough. We do not know yet.
> [[WEG]] No disagreement there, but as I said above, we're rapidly approaching the point where it really doesn't matter either way, so if there are legitimate uses, let's have them. Otherwise, run what you brung.
>
> Thanks,
> Wes
>
>
>    
If you believe it does not matter either way, then it should be done, 
simply because you may be wrong.

Joe


From owen at delong.com  Fri Apr 30 18:52:06 2010
From: owen at delong.com (Owen DeLong)
Date: Fri, 30 Apr 2010 15:52:06 -0700
Subject: [arin-ppml] [arin-discuss] x-small IPv4 ISPs going to IPv6
In-Reply-To: <4BDB2737.70400@ipinc.net>
References: <50EE5968-A41E-4BBD-92FE-6F025765E5F2@delong.com>	<FEA070315E40A3489D38398C35FE7BB279DD04DF31@EDAMAME.arin.net>	<327D7E22-D689-4F39-9B62-80439653D126@delong.com>	<FEA070315E40A3489D38398C35FE7BB279DD3B2124@EDAMAME.arin.net>	<2B842A75-E1E6-4B8F-820D-DA3C25148C62@delong.com>
	<C3F4CA6C-5522-4822-A2ED-B39D31957A94@delong.com>
	<4BDB2737.70400@ipinc.net>
Message-ID: <7578A3B7-6ECA-4E5B-ABF5-6605B5329BD2@delong.com>

Ted,
	I attempted to present some numerical facts for the community's
consideration. I was not pushing one position or the other, merely
providing the results of research.

	There are 866 x-small IPv4 ISPs that do not have IPv6.

	Those are the current set of providers that could be subject
to a meaningful fee waiver beyond 2012.

	As things currently stand, the 50% fee waiver for them would
make IPv6 free for 2011 and 2012 anyway, since 50% of 2250 is
more than the $1,000 difference between what they pay for IPv4
now and what they would pay for IPv6. Thus, they would still pay
the larger of $1,250 (what they pay now) and $1,125 (50% of the
IPv6 fees).

	If we want to consider an extended or permanent fee waiver
for those organizations, the maximum possible impact to ARIN
revenue would be a waiver of up to $866,000 (with adjustment
for new x-small organizations that might get added).

	I'm neither speaking for or against such a waiver at this time,
merely trying to provide a clear view of the facts and potential
impacts of such a waiver and the number of organizations that
could benefit from such a waiver.

Owen



From tedm at ipinc.net  Fri Apr 30 20:17:43 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 30 Apr 2010 17:17:43 -0700
Subject: [arin-ppml] [arin-discuss] x-small IPv4 ISPs going to IPv6
In-Reply-To: <7578A3B7-6ECA-4E5B-ABF5-6605B5329BD2@delong.com>
References: <50EE5968-A41E-4BBD-92FE-6F025765E5F2@delong.com>	<FEA070315E40A3489D38398C35FE7BB279DD04DF31@EDAMAME.arin.net>	<327D7E22-D689-4F39-9B62-80439653D126@delong.com>	<FEA070315E40A3489D38398C35FE7BB279DD3B2124@EDAMAME.arin.net>	<2B842A75-E1E6-4B8F-820D-DA3C25148C62@delong.com>
	<C3F4CA6C-5522-4822-A2ED-B39D31957A94@delong.com>
	<4BDB2737.70400@ipinc.net>
	<7578A3B7-6ECA-4E5B-ABF5-6605B5329BD2@delong.com>
Message-ID: <4BDB7327.6070406@ipinc.net>



On 4/30/2010 3:52 PM, Owen DeLong wrote:
> Ted,
> 	I attempted to present some numerical facts for the community's
> consideration. I was not pushing one position or the other, merely
> providing the results of research.
>
> 	There are 866 x-small IPv4 ISPs that do not have IPv6.
>
> 	Those are the current set of providers that could be subject
> to a meaningful fee waiver beyond 2012.
>
> 	As things currently stand, the 50% fee waiver for them would
> make IPv6 free for 2011 and 2012 anyway, since 50% of 2250 is
> more than the $1,000 difference between what they pay for IPv4
> now and what they would pay for IPv6. Thus, they would still pay
> the larger of $1,250 (what they pay now) and $1,125 (50% of the
> IPv6 fees).
>

Right, that is what I've advocated in the past.  The current fee
waiver for IPv6 goes to 25% next year then 0% the year after, however.

> 	If we want to consider an extended or permanent fee waiver
> for those organizations, the maximum possible impact to ARIN
> revenue would be a waiver of up to $866,000 (with adjustment
> for new x-small organizations that might get added).
>

Yes, but you failed to mention that this is offset against
the additional $866,000 that ARIN would take in if all those
orgs for IPv6 with no waiver.

> 	I'm neither speaking for or against such a waiver at this time,
> merely trying to provide a clear view of the facts and potential
> impacts of such a waiver and the number of organizations that
> could benefit from such a waiver.
>

But ultimately there are no impacts (financial at any rate)

As I thought I explained, the "missing" .8 Mil is something that
if nothing is done, is additional fees ARIN will make in the future
when the x-smalls are forced to go to IPv6.

If something is done, then ARIN does not make those additional fees
and instead merely makes the same fees they are making now.

Also since ARIN is duty-bound to return that .8 Mil in the form of
fee DECREASES then the real argument is this, do we want the
ultimate revenue ARIN takes in to NOT increase as a result of IPv6
or do we want it to DECREASE so we all (ISPs who are NOT x-smalls)
can get a nice break on our own fees?

You made it sound like the community is losing money if we do a
waiver which is definitely not the case.  The transition to IPv6
means more numbers handed out to the same fishes,
which due to the current fee structure results in a bonus for
ARIN.  It does not increase the number of fishes and as you have
constantly harped on in the past ARIN sets fees based on how
many fishes they have to keep track of, not how much IP numbers
they have handed out.  So if your going to be consistent with
what you have beaten me over the head with in the past, you should not 
be making the financials seem like a revenue loss to continue
to do a IPv6 waiver for the x-small IPv4 set.

With financials it's all in the presentation.

Ted


> Owen
>


From mysidia at gmail.com  Fri Apr 30 20:39:18 2010
From: mysidia at gmail.com (James Hess)
Date: Fri, 30 Apr 2010 19:39:18 -0500
Subject: [arin-ppml] [arin-discuss] x-small IPv4 ISPs going to IPv6
In-Reply-To: <4BDB7327.6070406@ipinc.net>
References: <50EE5968-A41E-4BBD-92FE-6F025765E5F2@delong.com>
	<FEA070315E40A3489D38398C35FE7BB279DD04DF31@EDAMAME.arin.net>
	<327D7E22-D689-4F39-9B62-80439653D126@delong.com>
	<FEA070315E40A3489D38398C35FE7BB279DD3B2124@EDAMAME.arin.net>
	<2B842A75-E1E6-4B8F-820D-DA3C25148C62@delong.com>
	<C3F4CA6C-5522-4822-A2ED-B39D31957A94@delong.com>
	<4BDB2737.70400@ipinc.net>
	<7578A3B7-6ECA-4E5B-ABF5-6605B5329BD2@delong.com>
	<4BDB7327.6070406@ipinc.net>
Message-ID: <p2g6eb799ab1004301739qf155016ez34925832879efd1b@mail.gmail.com>

On Fri, Apr 30, 2010 at 7:17 PM, Ted Mittelstaedt <tedm at ipinc.net> wrote:
[snip]
> Also since ARIN is duty-bound to return that .8 Mil in the form of
> fee DECREASES then the real argument is this, do we want the
> ultimate revenue ARIN takes in to NOT increase as a result of IPv6
> or do we want it to DECREASE so we all (ISPs who are NOT x-smalls)
> can get a nice break on our own fees?

Why do you say ARIN is duty-bound in any way to return "that .8 Mil"?
I don't think that is right at all.


There are probably various useful ways in which ARIN could spend that
to perform ARIN's duties better.  Reducing fees or  'returning' $$ is
just one option,
but not particularly  beneficial to ARIN's  continued survival.

Also in terms offsetting  loss of IPv4 allocation-related revenue
after V4 exhaustion.

And new expenses incurred  related to managing IPv6 address space
and service enhancements,  outreach, etc...

> Ted

--
-J