From owen at delong.com  Fri Oct  1 06:29:06 2010
From: owen at delong.com (Owen DeLong)
Date: Fri, 1 Oct 2010 03:29:06 -0700
Subject: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
In-Reply-To: <C8CA739C.11F90%marty@akamai.com>
References: <C8CA739C.11F90%marty@akamai.com>
Message-ID: <21C0D35D-66DA-4755-B43E-D9A69ACBC517@delong.com>


On Sep 30, 2010, at 2:04 PM, Hannigan, Martin wrote:

> 
> 
> 
> On 9/30/10 10:12 AM, "Owen DeLong" <owen at delong.com> wrote:
> 
>> 
>> On Sep 30, 2010, at 6:59 AM, Hannigan, Martin wrote:
>> 
>>> 
>>> 
>>> 
>>> On 9/30/10 9:44 AM, "Owen DeLong" <owen at delong.com> wrote:
>>> 
> 
> 
> [ snip ]
> 
>>> Ah, no. The theoretical /25's and /18's would have been approved based on
>>> need. An equal reduction for all bolsters the equity of needs based
>>> allocations. Capping the reduction on the low side is the Robin Hood
>>> approach. 
>>> 
>> Look, at some low side point, one has to cap the reduction. If nothing else,
>> it absolutely impossible to hand out a fractional /32.
> 
> 
> Which I've demonstrated is financially objectionable especially considering
> that the cost of IPv4 address space beyond depletion is an unknown variable.
> 
>> I think it is impractical to hand out less than a /28.
>> 
>> I'll point out that you were the one in our earlier discussions who wanted to
>> raise this threshold rather than lower it.
> 
> 
> We're only discussing these low thresholds because that is how the current
> proposal is written and that's what we are discussing. The minimum
> allocation should be higher and that the reservation system mechanics are
> broken with respect to fairness.
> 
We're going in circles now. Making the minimums higher breaks fairness in
other ways.

You haven't offered a change to the mechanics that would change the
facts presented above or the fairness of the outcome, so, I'm not sure
what you have in mind.

Owen



From marty at akamai.com  Sat Oct  2 00:46:09 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Sat, 2 Oct 2010 00:46:09 -0400
Subject: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
In-Reply-To: <B651FD22-6344-4AA9-B866-4D2B879BB293@delong.com>
Message-ID: <C8CC3151.121A3%marty@akamai.com>



Not to beat a dead horse, but...


On 9/30/10 9:44 AM, "Owen DeLong" <owen at delong.com> wrote:

>> 
>> I don't believe that we're saying anything different with respect to
>> inequities. Look at it from this perspective; if you have 1M /28
>> reservations and you have 1 x /18 reservation, in order to fulfill all or
>> most of the /28's you'll eat away at the /18.
>> 
> And if you have 1,000 /25s and 1 /18 you'll eat away at the /25s in order
> to give something to the /18 guy. Correct. Not giving the entire available
> space to the first guy in line just because he got there a couple of hours
> ahead isn't my idea of unfair.


Let's look at populated sample pool with the minimum set to /25:

50% = /25
40% = /24
5% = /20
5% = /18

Let's reduce the pool by 50%

50% lose nothing
40% lose 128 addrs
5% lose 2,048 addresses
5% lose 8,192 address

Let's show cost @ $1,000 per addr to amplify the damage

128 replacement addresses = $128,000.00
2,048 replacement addresses = $2,048,000.00
8,192 replacement address = $8,192,000.00


>>>> //Examples
>>>> 
>>>> Assumptions: Normal member fees apply except when reservations reduced and
>>>> forced to the market aside from other requirements not addressed through
>>>> this proposal:
>>>> 
>>>> Cost $1,000  /32
>>>> Need: /32
>>>> Assignments=Assn1/2
>>>> 
>>>>             Assn1 Assn2 Addr Deficit Loss
>>>> Funded         10 100   $0
>>>> Reduce 10%     10  90   $10,000
>>>> Reduce 20%     10  80   $20,000
>>>> Reduce 30%     10  70   $30,000
>>>> Reduce 40%     10  60   $40,000
>>>> 

[ clip ]


>>>> Assumptions: Every address acquired through a transition proposal is a cost
>>>> savings to the network in a fair and equitable manner.
>>>> 
>>>> Cost $1,000  /32
>>>> Need1: 10      Need2:  100
>>>> 
>>>>             QTRS   Need1       Need2
>>>>             12     120         1200
>>>>   Reduced 4 8      80          800
>>>>   Reduced 4 4      40          400
>>>> 
>>>> Max Total Savings: $120,000  $1,200,000 All quarters
>>>> Min Total Savings: $40,000   $400,000 All quarters
>>>> 
>>>> You might argue that the numbers are way disparate. Since the assignments
>>>> are need evaluated, the savings delta are not overly relevant. Unless we
>>>> opt
>>>> to be communists[1].
>>>> 
>>>> If we are using a general ratio of one V6 /32 = v6 /64 with the quarterly
>>>> model we push out far more v6 that we would with the reductions as well.
>>>> Theoretical priming of the v6 pump: more is better even if shorter..
>>>> 


[ clip ]


>>> I do think your estimate of $1,000 per /32 is speculative at best.
>> 
>> What do you think that this cost is currently?
>> 
> Since I don't have any legitimate address trading data to back it up, and,
> since to the best of my knowledge, no-one has exercised 8.3 as yet,
> neither do you, I would argue that any number would be speculative
> at best.

I chose $1,000 as an amplifier since it certainly draws attention and I
think that based on what I know about the market, it's feasible.

The data at the below URL is almost three years old, but still relevant with
respect to a normative number:

http://www.ripe.net/ripe/meetings/ripe-57/presentations/van_Mook-2007-08_v3.
Pdf

I have other data points on current pricing. I'm not the market maker so
please see me at the NANOG or ARIN meeting to discuss if needed. Anyone for
that matter - if you are truly interested in what's coming down the road.

[ clip ]


>> Not sure what the relevance of the follow-up is. No one is advocating that
>> anyone be able to land grab. Any policy that allows that is deficient. I'm
>> advocating that we abandon this proposal again.
>> 
> But you're opposing this proposal specifically because it doesn't
> allow for the land grab.


Why don't you build your own financial analysis of this proposal instead of
speculating on motive then? I haven't even factored in the cost of capital
needed or the accounting method to expense the addresses which would raise
the costs higher.

Hope that makes it clearer as to why I am opposing. There simply has to be a
better way.


Best,

-M<







From owen at delong.com  Sat Oct  2 02:40:05 2010
From: owen at delong.com (Owen DeLong)
Date: Fri, 1 Oct 2010 23:40:05 -0700
Subject: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
In-Reply-To: <C8CC3151.121A3%marty@akamai.com>
References: <C8CC3151.121A3%marty@akamai.com>
Message-ID: <967DB499-FF9B-4A8A-BF02-C5B17CCC291D@delong.com>


On Oct 1, 2010, at 9:46 PM, Hannigan, Martin wrote:

> 
> 
> Not to beat a dead horse, but...
> 
> 
> On 9/30/10 9:44 AM, "Owen DeLong" <owen at delong.com> wrote:
> 
>>> 
>>> I don't believe that we're saying anything different with respect to
>>> inequities. Look at it from this perspective; if you have 1M /28
>>> reservations and you have 1 x /18 reservation, in order to fulfill all or
>>> most of the /28's you'll eat away at the /18.
>>> 
>> And if you have 1,000 /25s and 1 /18 you'll eat away at the /25s in order
>> to give something to the /18 guy. Correct. Not giving the entire available
>> space to the first guy in line just because he got there a couple of hours
>> ahead isn't my idea of unfair.
> 
> 
> Let's look at populated sample pool with the minimum set to /25:
> 
> 50% = /25
> 40% = /24
> 5% = /20
> 5% = /18
> 
> Let's reduce the pool by 50%
> 
> 50% lose nothing
> 40% lose 128 addrs
> 5% lose 2,048 addresses
> 5% lose 8,192 address
> 
> Let's show cost @ $1,000 per addr to amplify the damage
> 
> 128 replacement addresses = $128,000.00
> 2,048 replacement addresses = $2,048,000.00
> 8,192 replacement address = $8,192,000.00
> 
You forgot to populate your "populated" sample... Let's try the exercise
again with a sample population...

Another reality being ignored, of course, is that by placing the minimum
at /25 (which isn't in accordance with the proposed policy, btw), you've
got some number of organizations that lose 100% just because they're
small. If we assume a similar sliding scale of escalating usage to what
you have depicted, assuming a total population of, say, 3,000 organizations,
I get the following adjusted figures:

40% = 	Nothing -- Too small to qualify		1,200 orgs
30% =	/25					  900 orgs				
22% = 	/24					  660 orgs
4% =	/20					  120 orgs
4% =	/18					  120 orgs

This gives us a total demand of:

1200 * 16	   19,200 addresses
 900 * 128	  115,200 addresses
 660 * 256	  168,960 addresses
 120 * 4096	  491,520 addresses
 120 * 16384	1,996,080 addresses

Total		2,790,960 addresses

Let's assume we only 1,395,480 addresses available.
You're still talking about 1,200 organizations that get nothing
being short 19,200 addresses in toto.

Yes, the 900 organizations at the bottom get their full 115,200
addresses while the next 660 organizations get half of their
demand at 84,480 addresses. The next 120 organizations still
get 245,760 addresses, and, finally, the largest consuming
120 organizations still suck down 998,040 addresses. The
remaining 19,200 addresses might get spread amongst the
organizations, but, since they can't really CIDR align that,
more likely there's not a practical way to do so.

Given that the total supplied for all the other classes is
only 445,440, it's hard for me to argue that the 120
organizations facing the largest shortage while still
taking twice that many addresses themselves are somehow
getting a raw deal compared to the other 2,880
organizations, the vast majority of whom got either nothing
or a 128 address share of 115,200 addresses.

Reality is you have to determine some mechanism for deciding who
does or doesn't get the remaining addresses. Currently, other than a /10,
it's straight first-come-first serve and I'm fine with that. However, if we're
going to start creating special end-game reservation profiles, then, just
being the first one to file a reservation shouldn't allow you to override
the interests of everyone who tries for an advanced reservation behind
you.

Remember, the whole reservation system was something added to the
policy outside of my initial intent, largely advocated by you.

In the end, regardless of what makeup addresses on the market cost
if they are even available, there is still some combination of organizations
that comes out 10,368 addresses short.

All we're doing is talking about how to rearrange the address shortage
deck chairs.

Obviously, the smaller the minimum, the closer to fair this becomes,
but, I believe it is thoroughly impractical to issue smaller than a /28
to organizations even from the end space.

If we change the scenario slightly and go with the minimum being
a /28, two changes occur...

1.	The 900 organizations that would get 128 addresses now get
	64 addresses.
2.	The 1200 organizations that would have gotten nothing now
	each get a /28.

As a result, there is a larger chunk of left-over space in the alignment
problem that remains in the transition pool for additional applicants.

The primary point to consider here is that you really have to put
a lot of smaller organizations against the wall in order to provide
another bit to even a single very large organization. Even if we
took all 57,600 "remainder" addresses and tried to back-fill
the /18 organizations needs, we'd still only fully fill 4/120 before
we used up all the available space.

> 
>>>> I do think your estimate of $1,000 per /32 is speculative at best.
>>> 
>>> What do you think that this cost is currently?
>>> 
>> Since I don't have any legitimate address trading data to back it up, and,
>> since to the best of my knowledge, no-one has exercised 8.3 as yet,
>> neither do you, I would argue that any number would be speculative
>> at best.
> 
> I chose $1,000 as an amplifier since it certainly draws attention and I
> think that based on what I know about the market, it's feasible.
> 
Sure, $1,000 is better for FUD than $1. I get that.

However, no matter what price you pick, we're still short the same amount
of address space with similar consequences.

Now, whose bottom line is more directly impacted?A very large organization
that gets 8,192 of the 16,384 addresses it needed and has to spend
some amount of money to come up with 8,192 more addresses, or,
the small organization that only got 64 of the 128 addresses they needed
to and has to make up that shortfall?

I think the impact as a percentage of revenue is roughly the same.

Yes, the organizations that only needed 16 addresses get a "free ride",
but, remember, those organizations probably needed more than
16 addresses anyway, that's just what they qualified for here.
Even though this is the largest number of organizations, they still
represent a tiny fraction of the address space consumed in the
policy.

The policy spreads the pain fairly evenly. Not in absolute dollar
terms, but, in dollar/organization-size terms.

> The data at the below URL is almost three years old, but still relevant with
> respect to a normative number:
> 
> http://www.ripe.net/ripe/meetings/ripe-57/presentations/van_Mook-2007-08_v3.
> Pdf
> 
Except this only describes black-market pricing (which is notoriously higher
than legitimate market pricing because it seeks to avoid normal restrictions
for whatever purpose). There is no data available on legitimate market
transfers because none have occurred as yet.

>>> 
>>> Not sure what the relevance of the follow-up is. No one is advocating that
>>> anyone be able to land grab. Any policy that allows that is deficient. I'm
>>> advocating that we abandon this proposal again.
>>> 
>> But you're opposing this proposal specifically because it doesn't
>> allow for the land grab.
> 
> 
> Why don't you build your own financial analysis of this proposal instead of
> speculating on motive then? I haven't even factored in the cost of capital
> needed or the accounting method to expense the addresses which would raise
> the costs higher.

See above...

> Hope that makes it clearer as to why I am opposing. There simply has to be a

> better way.
> 
OK... Propose it.

Owen

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

From Marla.Azinger at FTR.com  Sun Oct  3 10:48:37 2010
From: Marla.Azinger at FTR.com (Azinger, Marla)
Date: Sun, 3 Oct 2010 10:48:37 -0400
Subject: [arin-ppml] I Oppose 2010-12: IPv6 Subsequent Allocation
In-Reply-To: <AANLkTikP7DKr0kDUTwAv97awmnQTxY-bHqZHiwH8ONHN@mail.gmail.com>
References: <AANLkTikP7DKr0kDUTwAv97awmnQTxY-bHqZHiwH8ONHN@mail.gmail.com>
Message-ID: <2E2FECEBAE57CC4BAACDE67638305F10488C4BA9CF@ROCH-EXCH1.corp.pvt>

Bill or anyone else that sees this as a missing value-

What text would you suggest to resolve what you see as a missing value? 

Thank you
Marla

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin
Sent: Monday, September 27, 2010 1:28 PM
To: arin-ppml at arin.net
Subject: [arin-ppml] I Oppose 2010-12: IPv6 Subsequent Allocation

>Draft Policy 2010-12
>IPv6 Subsequent Allocation
>
>Version/Date: 20 July 2010
>
>Policy statement:
>
>Modify 6.5.2.1 Subsequent allocation criteria. ADD the following
>sentence: Subsequent allocations will also be considered for 
>transitional technologies that cannot be accommodated by, nor were 
>accounted for, under the initial allocation.
>
>Justification for the subsequent subnet size will be based on the plan 
>and technology provided. Justification for these allocations will be 
>reviewed every 3 years and reclaimed if it is not in use. Requester 
>will be exempt from returning all or a portion of the address space if 
>they can show justification for need of this allocation for other 
>existing
>IPv6 addressing requirements be it Native V6 or some other V6 network 
>technology.

After careful consideration, I OPPOSE draft policy 2010-12 as written.
Although I agree in principle that subsequent IPv6 allocations at this early stage should be driven more by recognized addressing needs than competent consumption of the prior allocation, this particular proposal needs more work.

2010-12 offers no guidance as to how ARIN staff is supposed to sort reasonable requests for transition addresses from unreasonable ones.
Indeed, as written a small ISP with a pair of /20 IPv4 allocations could request a /15 of IPv6 addresses for the purpose of hanging a /48 off each of their IPv4 address using 32-bit mapped 6rd in one /16 with a second /16 left over for native IPv6. No language in the resulting ARIN policy would suggest that such an enormous request is in any respect improper. Indeed, the policy would fail to support ARIN staff attempting to deny such a request.

Accordingly, I can not support proposal 2010-12 until it has been rewritten in a form that offers guidance to staff as to how requests are to be evaluated and places appropriately conservative safeguards on the both the number of subsequent allocations and the raw count of allocable addresses.

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 _______________________________________________
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 rfg at tristatelogic.com  Mon Oct  4 02:37:00 2010
From: rfg at tristatelogic.com (Ronald F. Guilmette)
Date: Sun, 03 Oct 2010 23:37:00 -0700
Subject: [arin-ppml] Policy Question(s)
Message-ID: <42015.1286174220@tristatelogic.com>


Greetings,

I am having some trouble understanding this document:

     https://www.arin.net/policy/nrpm.html

and specifically, Section 8, which deals with transfers.

I'd like to ask how the policy set forth there might or might not comport
with the following scenario...

A corporation was formed in the United States in 1996.  Call it `Company A'.

In July of 1999, Company A received an IPv4 /18 allocation.  Sometime in 2004,
the original company, Company A, was merged into a second corporation...
call it `Company B'...  which was newly created that year.  As a result,
Company B effectively inherited Company A's /18.  Company B is also located
in the United States, in the same state as Company A.

Company B still exists.  It has an active web site and it is taking
orders for T1 lines.  The grand total of all IP address space that Company B
ever had, even in its heyday, was the /18, and a tiny little /29, which
was obtained out of the allocation of another provider.  Because of the
early date of /18 allocation, and the chain of inheritance, my guess is
that most probably, Company B never had to ``justify'' their use of the /18
at all, ever.  (Is that correct?)

Fast forward to October of last year, 2009.  In that month, a brand new
Limited Liability Company (LLC) was formed in the same state as Companies
A and B.  Let's call this `Company C'.  The mailing address for Company C
is the same as that for Company B.

Now, fast forward to today.  Right now, today, ARIN records show the /18
to be registered to Company C.

So I just want to know:  How does a circumstance like this come to exist,
and how does it comport with current policy?

Would it ever have been permissible for Company B to sell, to ``gift'',
or to in any other way transfer, just late last year, its /18 to this
brand new LLC, Company C?

Does it make any difference that Company B and Company C seem to be in
some sense ``sister'' companies, perhaps with a significant overlap of
management and/or ownership?

And even if such a transfer had been allowed... i.e. transfering the /18
from B to C... wouldn't there necessarily have been questions raised at
that time about Company C's _need_ for a whole /18?  I mean after all,
Company C was only formed in October of last year, and it appears that
it has not now, and never has had any other IP resources, other than
the /18 which it quite apparently got from Company B.  (Furtrhermore,
it does appear that ever since the _original_ allocation of the /18,
wasy back in 1999, that sizable allocation may perhaps never have been
``justified'', i.e. to ARIN, in any formal sense.)

I guess my question is:  Can a brand new company, with no history whatsoever,
file papers with the state, to become a legit, LLC, and then waltz in to
ARIN the very next day and get themselves a whole fresh new /18 ?  Can they
do it if the /18 in question is being transferred from a ``sister'' company?
Can they do it without any utilization review or justification whatsoever?
Is such a transfer fully consistant with current policy?


Regards,
rfg


From mcr at sandelman.ca  Mon Oct  4 09:12:38 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Mon, 04 Oct 2010 09:12:38 -0400
Subject: [arin-ppml] Policy Question(s)
In-Reply-To: <42015.1286174220@tristatelogic.com> 
References: <42015.1286174220@tristatelogic.com> 
Message-ID: <10013.1286197958@marajade.sandelman.ca>


>>>>> "Ronald" == Ronald F Guilmette <rfg at tristatelogic.com> writes:
    Ronald> Company B still exists.  It has an active web site and it is
    Ronald> taking orders for T1 lines.  The grand total of all IP
    Ronald> address space that Company B ever had, even in its heyday,
    Ronald> was the /18, and a tiny little /29, which was obtained out
    Ronald> of the allocation of another provider.  Because of the early
    Ronald> date of /18 allocation, and the chain of inheritance, my
    Ronald> guess is that most probably, Company B never had to
    Ronald> ``justify'' their use of the /18 at all, ever.  (Is that
    Ronald> correct?)

    Ronald> Fast forward to October of last year, 2009.  In that month,
    Ronald> a brand new Limited Liability Company (LLC) was formed in
    Ronald> the same state as Companies A and B.  Let's call this
    Ronald> `Company C'.  The mailing address for Company C is the same
    Ronald> as that for Company B.

    Ronald> Now, fast forward to today.  Right now, today, ARIN records
    Ronald> show the /18 to be registered to Company C.

Company B still exists, I think?  Does it still do business?
Does it still have T1 customers?  

    Ronald> Would it ever have been permissible for Company B to sell,
    Ronald> to ``gift'', or to in any other way transfer, just late last
    Ronald> year, its /18 to this brand new LLC, Company C?

It could certainly assign address space from B->C, just like it would
any other chunk.  Can it assign the entire /18, I don't know.  If it did
that, whois would still show company B in the chain.

    Ronald> Does it make any difference that Company B and Company C
    Ronald> seem to be in some sense ``sister'' companies, perhaps with
    Ronald> a significant overlap of management and/or ownership?

Yes, because it makes it much more likely to explain that Company C acquired
Company B, and that Company B is really a wholy-owned subsidiary.

    Ronald> I guess my question is: Can a brand new company, with no
    Ronald> history whatsoever, file papers with the state, to become a
    Ronald> legit, LLC, and then waltz in to ARIN the very next day and
    Ronald> get themselves a whole fresh new /18 ?  Can they do it if

yes, there are ways they could do that: having some kind of construction
contract inked and signed for some kind of network build that would be
completed within 30 days, and would use an entire allocation. 

-- 
]       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 rfg at tristatelogic.com  Mon Oct  4 14:37:31 2010
From: rfg at tristatelogic.com (Ronald F. Guilmette)
Date: Mon, 04 Oct 2010 11:37:31 -0700
Subject: [arin-ppml] Policy Question(s)
In-Reply-To: <10013.1286197958@marajade.sandelman.ca> 
Message-ID: <5157.1286217451@tristatelogic.com>


In message <10013.1286197958 at marajade.sandelman.ca>, 
Michael Richardson <mcr at sandelman.ca> wrote:

>
>>>>>> "Ronald" == Ronald F Guilmette <rfg at tristatelogic.com> writes:
>    Ronald> Company B still exists.  It has an active web site and it is
>    Ronald> taking orders for T1 lines.  The grand total of all IP
>    Ronald> address space that Company B ever had, even in its heyday,
>    Ronald> was the /18, and a tiny little /29, which was obtained out
>    Ronald> of the allocation of another provider.  Because of the early
>    Ronald> date of /18 allocation, and the chain of inheritance, my
>    Ronald> guess is that most probably, Company B never had to
>    Ronald> ``justify'' their use of the /18 at all, ever.  (Is that
>    Ronald> correct?)
>
>    Ronald> Fast forward to October of last year, 2009.  In that month,
>    Ronald> a brand new Limited Liability Company (LLC) was formed in
>    Ronald> the same state as Companies A and B.  Let's call this
>    Ronald> `Company C'.  The mailing address for Company C is the same
>    Ronald> as that for Company B.
>
>    Ronald> Now, fast forward to today.  Right now, today, ARIN records
>    Ronald> show the /18 to be registered to Company C.
>
>Company B still exists, I think?  Does it still do business?
>Does it still have T1 customers?  

Yes, yes, and yes.

>    Ronald> Would it ever have been permissible for Company B to sell,
>    Ronald> to ``gift'', or to in any other way transfer, just late last
>    Ronald> year, its /18 to this brand new LLC, Company C?
>
>It could certainly assign address space from B->C, just like it would
>any other chunk.  Can it assign the entire /18, I don't know.  If it did
>that, whois would still show company B in the chain.

And what if it doesn't?  See that's what I'm asking about.  Now, the WHOIS
record for the whole original /18 only shows Comapny C as the ``owner''.

>    Ronald> Does it make any difference that Company B and Company C
>    Ronald> seem to be in some sense ``sister'' companies, perhaps with
>    Ronald> a significant overlap of management and/or ownership?
>
>Yes, because it makes it much more likely to explain that Company C acquired
>Company B, and that Company B is really a wholy-owned subsidiary.

And what if that is NOT the case?

If Company C _did not_ wholly aquire Company B, but still, somehow, as of
now, it is only Company C's name on the WHOIS for the /18, then does this
indicate that something has happened, somewhere along the line, that
violated, or went against current policy?

See that's what I'm getting at.  May an older company (B) which has NOT
been bought out, and which is still actively in business simply ``gift''
a /18 that it happens to have lying around to a freshly-minted new company
(C) such that we wake up one day and it is only Company C's name on the
WHOIS?

Frankly, this doesn't seem right.

>    Ronald> I guess my question is: Can a brand new company, with no
>    Ronald> history whatsoever, file papers with the state, to become a
>    Ronald> legit, LLC, and then waltz in to ARIN the very next day and
>    Ronald> get themselves a whole fresh new /18 ?  Can they do it if
>
>yes, there are ways they could do that: having some kind of construction
>contract inked and signed for some kind of network build that would be
>completed within 30 days, and would use an entire allocation. 

OK.  I think I understand.  May I safely assume that if such documents
existed, and if they had been submitted... you know... to ARIN... as part
of justifying the assignment/aquisition of a /18, that those would be
treated as confidential, and not be in any sense part of the public
record?

And separately, if such documents existed... documents which would justify
Company C's immediate need for a whole /18, then those would be sufficient,
nder existing policy, for ARIN to assign a whole new _fresh_ /18 to the
company for its use, right?  So in that case, Company C wouldn't have had
to ``beggar'' Comapny B for _its_ old /18, because it has justification
in hand for a whole _new_ /18, right?  So if Company C ended up with
what was (past tense) Company B's old /18 under this scenario, then that
would be rather... ummm... odd, yes?

(Forgive me for continuing to use pseudonyms for the three companies I've
discussed.  I just don't want to cast any aspersions on any actual companies
until I understand what is and what isn't conformant to policy.  I mean
maybe none of these companies had done anything out of the ordinary at
all, nor anything counter to current policy.  I don't know yet, but it
sure all does look mighty odd.)


Regards,
rfg


From mark at townsley.net  Mon Oct  4 16:13:06 2010
From: mark at townsley.net (Mark Townsley)
Date: Mon, 04 Oct 2010 22:13:06 +0200
Subject: [arin-ppml] I Oppose 2010-12: IPv6 Subsequent Allocation
In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F10488C4BA9CF@ROCH-EXCH1.corp.pvt>
References: <AANLkTikP7DKr0kDUTwAv97awmnQTxY-bHqZHiwH8ONHN@mail.gmail.com>
	<2E2FECEBAE57CC4BAACDE67638305F10488C4BA9CF@ROCH-EXCH1.corp.pvt>
Message-ID: <4CAA3552.7080505@townsley.net>

 On 10/3/10 4:48 PM, Azinger, Marla wrote:
> Bill or anyone else that sees this as a missing value-
>
> What text would you suggest to resolve what you see as a missing value? 

The largest 6rd deployment today provides a /60 its residential
subscribers. Thus, 6rd uses a /28 (in this case from within a /26 for
the whole ISP).

This is the first example listed here:

http://lists.arin.net/pipermail/arin-ppml/2010-September/018175.html

I have seen only one ISP go as short as /56 with 6rd. In this case, the
provider happened to have sufficient allocation to do so long before 6rd
was even invented.

The most common alternative besides /60 I see is a single /64 in order
to operate within a /32 minimum allocation. This of course denies
routing in the home (leading to IPv6 NAT) and not something I think we
want to see more of.

Of these three (/24, /28, or /32), /28 would seem the best balance.

- Mark


> Thank you
> Marla
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin
> Sent: Monday, September 27, 2010 1:28 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] I Oppose 2010-12: IPv6 Subsequent Allocation
>
>> Draft Policy 2010-12
>> IPv6 Subsequent Allocation
>>
>> Version/Date: 20 July 2010
>>
>> Policy statement:
>>
>> Modify 6.5.2.1 Subsequent allocation criteria. ADD the following
>> sentence: Subsequent allocations will also be considered for 
>> transitional technologies that cannot be accommodated by, nor were 
>> accounted for, under the initial allocation.
>>
>> Justification for the subsequent subnet size will be based on the plan 
>> and technology provided. Justification for these allocations will be 
>> reviewed every 3 years and reclaimed if it is not in use. Requester 
>> will be exempt from returning all or a portion of the address space if 
>> they can show justification for need of this allocation for other 
>> existing
>> IPv6 addressing requirements be it Native V6 or some other V6 network 
>> technology.
> After careful consideration, I OPPOSE draft policy 2010-12 as written.
> Although I agree in principle that subsequent IPv6 allocations at this early stage should be driven more by recognized addressing needs than competent consumption of the prior allocation, this particular proposal needs more work.
>
> 2010-12 offers no guidance as to how ARIN staff is supposed to sort reasonable requests for transition addresses from unreasonable ones.
> Indeed, as written a small ISP with a pair of /20 IPv4 allocations could request a /15 of IPv6 addresses for the purpose of hanging a /48 off each of their IPv4 address using 32-bit mapped 6rd in one /16 with a second /16 left over for native IPv6. No language in the resulting ARIN policy would suggest that such an enormous request is in any respect improper. Indeed, the policy would fail to support ARIN staff attempting to deny such a request.

> Accordingly, I can not support proposal 2010-12 until it has been rewritten in a form that offers guidance to staff as to how requests are to be evaluated and places appropriately conservative safeguards on the both the number of subsequent allocations and the raw count of allocable addresses.


> 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 _______________________________________________
> 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 Wesley.E.George at sprint.com  Mon Oct  4 17:53:02 2010
From: Wesley.E.George at sprint.com (George, Wes E IV [NTK])
Date: Mon, 4 Oct 2010 16:53:02 -0500
Subject: [arin-ppml] I Oppose 2010-12: IPv6 Subsequent Allocation
In-Reply-To: <4CAA3552.7080505@townsley.net>
References: <AANLkTikP7DKr0kDUTwAv97awmnQTxY-bHqZHiwH8ONHN@mail.gmail.com>
	<2E2FECEBAE57CC4BAACDE67638305F10488C4BA9CF@ROCH-EXCH1.corp.pvt>
	<4CAA3552.7080505@townsley.net>
Message-ID: <F7EB0A7C707E39409A73CD0353242551A8C1E2A089@PLSWM01C.ad.sprint.com>


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Mark Townsley
Sent: Monday, October 04, 2010 4:13 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] I Oppose 2010-12: IPv6 Subsequent Allocation

 On 10/3/10 4:48 PM, Azinger, Marla wrote:
> Bill or anyone else that sees this as a missing value-
>
> What text would you suggest to resolve what you see as a missing value?

The largest 6rd deployment today...[snip]


[[WEG]] Why are we using 6rd as an example for 2010-12 when 6rd has a specific policy proposal on the table? I reiterate my earlier comment that I would like to see 2010-9 and 2010-12 merged into one common (and less 6RD-specific) policy.

Thanks
Wes George

- Mark

> Thank you
> Marla
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin
> Sent: Monday, September 27, 2010 1:28 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] I Oppose 2010-12: IPv6 Subsequent Allocation
>
>> Draft Policy 2010-12
>> IPv6 Subsequent Allocation
>>
>> Version/Date: 20 July 2010
>>
>> Policy statement:
>>
>> Modify 6.5.2.1 Subsequent allocation criteria. ADD the following
>> sentence: Subsequent allocations will also be considered for
>> transitional technologies that cannot be accommodated by, nor were
>> accounted for, under the initial allocation.
>>
>> Justification for the subsequent subnet size will be based on the plan
>> and technology provided. Justification for these allocations will be
>> reviewed every 3 years and reclaimed if it is not in use. Requester
>> will be exempt from returning all or a portion of the address space if
>> they can show justification for need of this allocation for other
>> existing
>> IPv6 addressing requirements be it Native V6 or some other V6 network
>> technology.
> After careful consideration, I OPPOSE draft policy 2010-12 as written.
> Although I agree in principle that subsequent IPv6 allocations at this early stage should be driven more by recognized addressing needs than competent consumption of the prior allocation, this particular proposal needs more work.
>
> 2010-12 offers no guidance as to how ARIN staff is supposed to sort reasonable requests for transition addresses from unreasonable ones.
> Indeed, as written a small ISP with a pair of /20 IPv4 allocations could request a /15 of IPv6 addresses for the purpose of hanging a /48 off each of their IPv4 address using 32-bit mapped 6rd in one /16 with a second /16 left over for native IPv6. No language in the resulting ARIN policy would suggest that such an enormous request is in any respect improper. Indeed, the policy would fail to support ARIN staff attempting to deny such a request.

> Accordingly, I can not support proposal 2010-12 until it has been rewritten in a form that offers guidance to staff as to how requests are to be evaluated and places appropriately conservative safeguards on the both the number of subsequent allocations and the raw count of allocable addresses.


> 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 _______________________________________________
> 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.


This e-mail may contain Sprint Nextel 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 bill at herrin.us  Mon Oct  4 19:35:11 2010
From: bill at herrin.us (William Herrin)
Date: Mon, 4 Oct 2010 19:35:11 -0400
Subject: [arin-ppml] I Oppose 2010-12: IPv6 Subsequent Allocation
In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F10488C4BA9CF@ROCH-EXCH1.corp.pvt>
References: <AANLkTikP7DKr0kDUTwAv97awmnQTxY-bHqZHiwH8ONHN@mail.gmail.com>
	<2E2FECEBAE57CC4BAACDE67638305F10488C4BA9CF@ROCH-EXCH1.corp.pvt>
Message-ID: <AANLkTik4opowWpe1sOwzfv5DmK=ogw+jbDKUyNBunHTz@mail.gmail.com>

On Sun, Oct 3, 2010 at 10:48 AM, Azinger, Marla <Marla.Azinger at ftr.com> wrote:
> Bill or anyone else that sees this as a missing value-
> What text would you suggest to resolve what you see as a missing value?

Hi Marla,

I need to think about it some more, but off the cuff I think I'd place
a few limits:

1. No organization can justify holding total IPv6 allocations that
exceed /26 under this policy.

Rationale: If you think you need more than that, you haven't thought
it through well enough.

2. No organization can justify more than two disaggregate allocations
under this policy irrespective of individual or total size.

Rationale: You get a couple tries but then you have to clear out and
return one of your earlier tries before you can make attempt number
three.

3. Unless organization is mapping more than, and I'm picking a number
out of my hat here, 5 disaggregate IPv4 allocations with the
transition mechanism the the largest additional allocation they can
justify is a /32.

Rationale: you shouldn't be mapping the full 32 bits of the Ipv4
address into the upper 64 bits of address space unless you're juggling
so many different IPv4 allocations that it just isn't practical to do
it any other way... And transition mechanisms that need to consume
ARIN allocations but must map the full 32 bit address aren't credible.


Also I suggest ditching the 3-year resource review. We barely review
V4 resources as we approach a critical shortage. We're not seriously
going to review IPv6 allocations for a long, long time.

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 michael.dillon at bt.com  Tue Oct  5 02:31:48 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 5 Oct 2010 07:31:48 +0100
Subject: [arin-ppml] Policy Question(s)
In-Reply-To: <5157.1286217451@tristatelogic.com>
References: <10013.1286197958@marajade.sandelman.ca>
	<5157.1286217451@tristatelogic.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B42393777FABA@EMV01-UKBR.domain1.systemhost.net>

> >    Ronald> Would it ever have been permissible for Company B to sell,
> >    Ronald> to ``gift'', or to in any other way transfer, just late
> last
> >    Ronald> year, its /18 to this brand new LLC, Company C?

Companies often divest part of their operations to another company.
Sometimes they just sell network assets which would include a functioning
network and its IP addresses and customers.

The receiving company generally has its own network and integrates the
two networks, reusing the old addresses on the integrated network before
decommissioning the purchased one.

Truth is stranger than fiction which means that a lot of oddities are
perfectly normal.

--Michael Dillon



From owen at delong.com  Tue Oct  5 03:56:39 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 5 Oct 2010 00:56:39 -0700
Subject: [arin-ppml] I Oppose 2010-12: IPv6 Subsequent Allocation
In-Reply-To: <AANLkTik4opowWpe1sOwzfv5DmK=ogw+jbDKUyNBunHTz@mail.gmail.com>
References: <AANLkTikP7DKr0kDUTwAv97awmnQTxY-bHqZHiwH8ONHN@mail.gmail.com>
	<2E2FECEBAE57CC4BAACDE67638305F10488C4BA9CF@ROCH-EXCH1.corp.pvt>
	<AANLkTik4opowWpe1sOwzfv5DmK=ogw+jbDKUyNBunHTz@mail.gmail.com>
Message-ID: <6352E671-A11E-446F-9088-CBA2BF5A1F5D@delong.com>

I would actually support these changes. I'd put the upper bound at /24 rather than /26, as I
believe we should stop issuing things on non-nibble boundaries in general.


Owen

On Oct 4, 2010, at 4:35 PM, William Herrin wrote:

> On Sun, Oct 3, 2010 at 10:48 AM, Azinger, Marla <Marla.Azinger at ftr.com> wrote:
>> Bill or anyone else that sees this as a missing value-
>> What text would you suggest to resolve what you see as a missing value?
> 
> Hi Marla,
> 
> I need to think about it some more, but off the cuff I think I'd place
> a few limits:
> 
> 1. No organization can justify holding total IPv6 allocations that
> exceed /26 under this policy.
> 
> Rationale: If you think you need more than that, you haven't thought
> it through well enough.
> 
> 2. No organization can justify more than two disaggregate allocations
> under this policy irrespective of individual or total size.
> 
> Rationale: You get a couple tries but then you have to clear out and
> return one of your earlier tries before you can make attempt number
> three.
> 
> 3. Unless organization is mapping more than, and I'm picking a number
> out of my hat here, 5 disaggregate IPv4 allocations with the
> transition mechanism the the largest additional allocation they can
> justify is a /32.
> 
> Rationale: you shouldn't be mapping the full 32 bits of the Ipv4
> address into the upper 64 bits of address space unless you're juggling
> so many different IPv4 allocations that it just isn't practical to do
> it any other way... And transition mechanisms that need to consume
> ARIN allocations but must map the full 32 bit address aren't credible.
> 
> 
> Also I suggest ditching the 3-year resource review. We barely review
> V4 resources as we approach a critical shortage. We're not seriously
> going to review IPv6 allocations for a long, long time.
> 
> 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
> _______________________________________________
> 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 rfg at tristatelogic.com  Tue Oct  5 05:22:41 2010
From: rfg at tristatelogic.com (Ronald F. Guilmette)
Date: Tue, 05 Oct 2010 02:22:41 -0700
Subject: [arin-ppml] Policy Question(s)
In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B42393777FABA@EMV01-UKBR.domain1.systemhost.net>
Message-ID: <16567.1286270561@tristatelogic.com>


In message <0F29D1BA57992E4CAB5AD2C9AE7B42393777FABA at EMV01-UKBR.domain1.systemh
ost.net>, michael.dillon at bt.com wrote:

>> >    Ronald> Would it ever have been permissible for Company B to sell,
>> >    Ronald> to ``gift'', or to in any other way transfer, just late
>> last
>> >    Ronald> year, its /18 to this brand new LLC, Company C?
>
>Companies often divest part of their operations to another company.
>Sometimes they just sell network assets which would include a functioning
>network and its IP addresses and customers.

I'm sorry. I wasn't clear.  I left out some important details.

As far as I can tell there was no transfer of customers, nor of any networking
hardware, not of any ``hosts''.  Just the IP space.

Now, is _this_ scenario considered usual & customary?

Is it considered acceptable, under current policy?

>The receiving company generally has its own network and integrates the
>two networks, reusing the old addresses on the integrated network before
>decommissioning the purchased one.

Again, I may not have been clear.  The ``receiving'' company (C) in this case
was only born in October of last year.  It had no network of its own prior
to that, nor any customers, prior to that, nor any IP addresses, prior to that.
As far as I can tell, all it ever has had was the /18 it was given (as a
birthday gift?) by Company B.

So now, as I have clarified it, is _this_ scenario considered usual & customary?

Is it considered acceptable, under current policy?

>Truth is stranger than fiction which means that a lot of oddities are
>perfectly normal.

Yes, however this one is looking like a Greek god...

  ``Athena leaped from Zeus's head, fully grown and armed -- with a shout...''

Company C only came into being in October of last year, and yet presto-changeo!
It seems to have been born fully formed, like Athena, with its own /18 (which,
it would seem, may never have been justified or audited in any way, despite
its being non-legacy space).

(Remember, this is _not_ ``legacy'' space we are talking about.  The /18 in
question was first allocated... presumaby by ARIN, under an RSA... in July,
1999.)

So my question remains... if _someone_ creates a brand new, fresh, newly
manufactured LLC, can some other company that happens to have an unused
/18 lying around just ``gift'' that /18 to this new legal entity the
very next day?

And if that does happen, shouldn't ARIN balk at putting the new entity's
name into the WHOIS record as the new legal ``owner'' of the block?


From michael.dillon at bt.com  Tue Oct  5 06:05:05 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 5 Oct 2010 11:05:05 +0100
Subject: [arin-ppml] Policy Question(s)
In-Reply-To: <16567.1286270561@tristatelogic.com>
References: <0F29D1BA57992E4CAB5AD2C9AE7B42393777FABA@EMV01-UKBR.domain1.systemhost.net>
	<16567.1286270561@tristatelogic.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B42393777FCBE@EMV01-UKBR.domain1.systemhost.net>


> So my question remains... 

You ask too many questions. 
ARIN has a fraud reporting page at <https://www.arin.net/resources/fraud/>.

Use it and stop asking so many silly repetitive questions.

Oh, by the way, this list is for discussing ARIN policy, not for haranging
people about stuff that is unrelated to policy and is, in fact, already
being handled by ARIN staff.

--Michael Dillon



From rfg at tristatelogic.com  Tue Oct  5 08:05:54 2010
From: rfg at tristatelogic.com (Ronald F. Guilmette)
Date: Tue, 05 Oct 2010 05:05:54 -0700
Subject: [arin-ppml] Policy Question(s)
In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B42393777FCBE@EMV01-UKBR.domain1.systemhost.net>
Message-ID: <20225.1286280354@tristatelogic.com>


In message <0F29D1BA57992E4CAB5AD2C9AE7B42393777FCBE at EMV01-UKBR.domain1.systemh
ost.net>, michael.dillon at bt.com wrote:

>> So my question remains... 
>
>You ask too many questions. 

I want to learn what the policy is.  If you have a better way for me to
do that, please indicate that to me.

I have read the applicable documents available on the ARIN web site. They
are ambiguous at best.  They do not answer these questions.

>ARIN has a fraud reporting page at <https://www.arin.net/resources/fraud/>.

Who said anything about fraud??

Why would I use that ``fraud'' form when, as far as I can make out, nothing
in the least bit fradulent has occured, i.e. in the case I have described
here?

>Use it and stop asking so many silly repetitive questions.

I wasn't aware my questions were repetitive.

>Oh, by the way, this list is for discussing ARIN policy,

Sir, I have been looking all night at a rather lengthy discussion that
took place ON THIS LIST just two short years ago in which several
participants debated what the policies should be, specifically for
legacy blocks.  That debate was vigorous and, as I say, lengthy.
And from my reading of it, it is not at all clear that the policy was
at all well defined, either at the end of that discussion, or since.

Regardless, it does seem as though you are ORDERING me, unilaterally,
not to discuss something on this list that quite clearly was an appropriate
topic of discussion, right here, on this very list, just two short years
ago.

If you can enlighten me as to why you think I'm off-topic for this list,
I'm all ears.

But first allow me to poinyt out that the several gentlemen behind this
endeavor:

     http://www.depository.net/

would like, it seems, to foster a marketplace for IP addresses.  I would
like to do likewise, considering how easy it _appears_ to be to buy and
sell sizable IP address blocks at the current moment.  Here is another
entity that seems to already be peddling /24s openly, as we speak:

    http://www.jump.ro/ip.html

I have money to invest, and I am ready to proceed.  I would like to start
buying and selling IP addresses, in bulk.

Now, can you just tell me please:  Will I be thwarted in this business venture
by _secret_ unpublished rules regarding  inter-company IP address block
transfers... secret unwritten rules that appear, magically, out of thin air,
just _after_ I have invested my time, effort, and money in this venture?

Maybe you understand what I'm getting at, or maybe you don't, or maybe you
just don't care, because these are not ARIN-related policy questions that
happen to affect you or be of interest to you.  But maybe I'm actually not
the only person on this planet who might be curious, as I am, as to whether
or not a ``marketplace'' in IP address blocks _already_ does exist within
the ARIN region, as this example (and others) would tend to indicate:

   NET-216-59-128-0-1

and also, whether this current ``marketplace'' is something that ARIN is
merely tolerating for the moment, or whether this marketplace is in fact
now ready for people to make investments (e.g. in brokerage businesses)
without fear that ARIN is going to come in, in the ninth inning as it were,
and, like some modern day Elloit Ness, raid the game and take away all of
the chips...  unilaterally and suddenly.  (Obviously, if this is a real
possibility, then one would have to be a fool to invest in an IP brokerage
business at this time.)

Note:  The above indicated IP address block is quite certainly _not_ the
only example I have in hand where there was apparently a sale (or a
``gifting'') of a sizable IP block... apparently sanctioned in some way
by ARIN... although it is more than a little bit unclear exactly _how_
that might have occurred, under the existing policies.  (Do some entities
get special, preferential treatment?  Do you?  Will I?)

So, to quote Shakespere  ``Methinks the lady doth protest too much!''
Your extraordinary hostility towards even allowing a discussion of this
subject to take place, in this very appropriate venue, actually just
piques my interest even more!

Why is this policy question too ``touchy'' a subject... you know... the
question about the policy by which ARIN sanctions some IP block sales,
even while, apparently denying others...  why is that too touchy a POLICY
subject to be discussed on this list?

Despite your claims to the contrary, I _have_ been asking policy questions.
And I have been asking them here on this thing that's titled the ``public''
policy mailing list.  (Did I misread that ``public'' part?)  It's clear
that for some parties, these questions might be uncomfortable.  I understand
that.   And it's equally clear to me that those same interests can stiffle
and prevent these questions from even being asked, here or elsewhere.  But
let's not kid ourselves.  I have been asking serious on-topic policy questions.
I'm sure if you work at it, you'll be able to successfully gag the messsenger,
but if your only basis for gagging me is the clearly false claim that I've
been in the least bit off-topic... well then I hope this will be seen for
what it is, i.e. just gagging of somebdoy who asked questions that made
certain folks uncomfortable... NOT because I was at all off-topic.  (And
there are reams and reams of discussions in the archives of this list where
these same questions about buying and selling IPs, and the complex problems
of legacy block ownerhsip and transfers been discussed...  and not just a
little, a lot.)

>... not for haranging people...

I haven't been ``haranging'' anybody!  I clarified my question just a tiny bit,
just so that I could maybe have some hope of actually finding out what the
bloody rules are, that's all!  (And it's pretty clear that not all of them are
even written down.)

So why is your reaction so hot?

I am honestly perplexed.

>... about stuff that is unrelated to policy and is, in fact, already
>being handled by ARIN staff.

What is?  What exactly do you think is ``already being handled by ARIN staff'' ?

I have no idea what you are talking about.  Seriously.  Can you explain?
Are either you or ARIN so prescient that you knew about NET-216-59-128-0-1,
in particular, before I even mentioned it???

Hey!  That's a neat trick!

So I'm guessing then that you already know all about the other three blocks
I was going to mention (and I guess ARIN does too, even though I've never
once mentioned them before to anybody), and that's Good, because then you
can educate me as regards to how _those_ sales got formally blessed.


Regards,
rfg


P.S.  I _do_ understand that quite a lot of people... probably a majority
in fact, both here and elsewhere... actually loath and despise the whole
idea of IP address block ``brokerages''.  Acutally, despite what I said
above, I do too.  But you know, like it or not, the evidence is in, and it
seems to be going on already, right now, anyway.  And as the character
Yoasarian often said in Joseph Heller's `Catch-22' ``If everybody else
was doing it, then I'd be a damn fool to do any different.''  And at this
moment, it _does_ appear to me that everybody else is already doing it.

So if that's the case, then why should _I_ be the only one who _isn't_
climbing on board the gravy train?  I mean seriously, why?  Just because
I'm not an ``insider'' and an old established member of the club?


From scottleibrand at gmail.com  Tue Oct  5 09:34:56 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 5 Oct 2010 09:34:56 -0400
Subject: [arin-ppml] Policy Question(s)
In-Reply-To: <16567.1286270561@tristatelogic.com>
References: <0F29D1BA57992E4CAB5AD2C9AE7B42393777FABA@EMV01-UKBR.domain1.systemhost.net>
	<16567.1286270561@tristatelogic.com>
Message-ID: <00bc01cb6492$1a955c30$4fc01490$@com>

Ronald,

It sounds like you've got a fairly good handle on the policy.  As I think
you mentioned, the operative policy is in section 8:
https://www.arin.net/policy/nrpm.html#eight

8.2 covers transfers due to Mergers and Acquisitions, which is traditionally
the policy applied to situations like this.  It requires that "the new
entity has acquired assets that used the transferred resources from the
current registrant", and that the addresses remain justified under current
ARIN policy.

It's also possible to transfer IPv4 addresses using 8.3, which doesn't
require M&A, but must be "received under RSA by organizations that are
within the ARIN region and can demonstrate the need for such resources, as a
single aggregate, in the exact amount which they can justify under current
ARIN policies."

If you have information to indicate that company C does not have justified
need for the /18 under current policy (and/or didn't at the time they became
the registrant in ARIN's database), please do provide your information to
ARIN (https://www.arin.net/resources/fraud/) so they can investigate.  The
information they received at the time of the transfer is confidential, but
they can take your tip, investigate, and institute a section 12 Resource
Review (https://www.arin.net/policy/nrpm.html#twelve) if justified.

It might also be worth noting that there is a policy proposal on the docket
this week in Atlanta to require ARIN to institute resource reviews under
various circumstances, including "Upon receipt by ARIN of one or more
credible reports of fraud":
https://www.arin.net/policy/proposals/2010_11.html  If you have an opinion
on whether that would be good policy, I would encourage you to participate
in the meeting discussion, either in person or remotely:
https://www.arin.net/participate/meetings/ARIN-XXVI/remote.html

Thanks,
Scott

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Ronald F. Guilmette
Sent: Tuesday, October 05, 2010 5:23 AM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Question(s)


In message
<0F29D1BA57992E4CAB5AD2C9AE7B42393777FABA at EMV01-UKBR.domain1.systemh
ost.net>, michael.dillon at bt.com wrote:

>> >    Ronald> Would it ever have been permissible for Company B to sell,
>> >    Ronald> to ``gift'', or to in any other way transfer, just late
>> last
>> >    Ronald> year, its /18 to this brand new LLC, Company C?
>
>Companies often divest part of their operations to another company.
>Sometimes they just sell network assets which would include a functioning
>network and its IP addresses and customers.

I'm sorry. I wasn't clear.  I left out some important details.

As far as I can tell there was no transfer of customers, nor of any
networking
hardware, not of any ``hosts''.  Just the IP space.

Now, is _this_ scenario considered usual & customary?

Is it considered acceptable, under current policy?

>The receiving company generally has its own network and integrates the
>two networks, reusing the old addresses on the integrated network before
>decommissioning the purchased one.

Again, I may not have been clear.  The ``receiving'' company (C) in this
case
was only born in October of last year.  It had no network of its own prior
to that, nor any customers, prior to that, nor any IP addresses, prior to
that.
As far as I can tell, all it ever has had was the /18 it was given (as a
birthday gift?) by Company B.

So now, as I have clarified it, is _this_ scenario considered usual &
customary?

Is it considered acceptable, under current policy?

>Truth is stranger than fiction which means that a lot of oddities are
>perfectly normal.

Yes, however this one is looking like a Greek god...

  ``Athena leaped from Zeus's head, fully grown and armed -- with a
shout...''

Company C only came into being in October of last year, and yet
presto-changeo!
It seems to have been born fully formed, like Athena, with its own /18
(which,
it would seem, may never have been justified or audited in any way, despite
its being non-legacy space).

(Remember, this is _not_ ``legacy'' space we are talking about.  The /18 in
question was first allocated... presumaby by ARIN, under an RSA... in July,
1999.)

So my question remains... if _someone_ creates a brand new, fresh, newly
manufactured LLC, can some other company that happens to have an unused
/18 lying around just ``gift'' that /18 to this new legal entity the
very next day?

And if that does happen, shouldn't ARIN balk at putting the new entity's
name into the WHOIS record as the new legal ``owner'' of the block?
_______________________________________________
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 petre5 at yahoo.com  Tue Oct  5 13:04:28 2010
From: petre5 at yahoo.com (Peet D)
Date: Tue, 5 Oct 2010 10:04:28 -0700 (PDT)
Subject: [arin-ppml] Policy Question(s)
In-Reply-To: <00bc01cb6492$1a955c30$4fc01490$@com>
Message-ID: <582007.48024.qm@web54505.mail.re2.yahoo.com>

The guy has a good point, so arin get your docs out and answer him.  

*Confidentiality Notice: 

This E-Mail is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you have received this communication in error, please do not distribute, and delete the original message. 

Thank you for your compliance!


--- On Tue, 10/5/10, Scott Leibrand <scottleibrand at gmail.com> wrote:

> From: Scott Leibrand <scottleibrand at gmail.com>
> Subject: Re: [arin-ppml] Policy Question(s)
> To: "'Ronald F. Guilmette'" <rfg at tristatelogic.com>, arin-ppml at arin.net
> Date: Tuesday, October 5, 2010, 7:34 AM
> Ronald,
> 
> It sounds like you've got a fairly good handle on the
> policy.? As I think
> you mentioned, the operative policy is in section 8:
> https://www.arin.net/policy/nrpm.html#eight
> 
> 8.2 covers transfers due to Mergers and Acquisitions, which
> is traditionally
> the policy applied to situations like this.? It
> requires that "the new
> entity has acquired assets that used the transferred
> resources from the
> current registrant", and that the addresses remain
> justified under current
> ARIN policy.
> 
> It's also possible to transfer IPv4 addresses using 8.3,
> which doesn't
> require M&A, but must be "received under RSA by
> organizations that are
> within the ARIN region and can demonstrate the need for
> such resources, as a
> single aggregate, in the exact amount which they can
> justify under current
> ARIN policies."
> 
> If you have information to indicate that company C does not
> have justified
> need for the /18 under current policy (and/or didn't at the
> time they became
> the registrant in ARIN's database), please do provide your
> information to
> ARIN (https://www.arin.net/resources/fraud/) so
> they can investigate.? The
> information they received at the time of the transfer is
> confidential, but
> they can take your tip, investigate, and institute a
> section 12 Resource
> Review (https://www.arin.net/policy/nrpm.html#twelve) if
> justified.
> 
> It might also be worth noting that there is a policy
> proposal on the docket
> this week in Atlanta to require ARIN to institute resource
> reviews under
> various circumstances, including "Upon receipt by ARIN of
> one or more
> credible reports of fraud":
> https://www.arin.net/policy/proposals/2010_11.html?
> If you have an opinion
> on whether that would be good policy, I would encourage you
> to participate
> in the meeting discussion, either in person or remotely:
> https://www.arin.net/participate/meetings/ARIN-XXVI/remote.html
> 
> Thanks,
> Scott
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net
> [mailto:arin-ppml-bounces at arin.net]
> On
> Behalf Of Ronald F. Guilmette
> Sent: Tuesday, October 05, 2010 5:23 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Question(s)
> 
> 
> In message
> <0F29D1BA57992E4CAB5AD2C9AE7B42393777FABA at EMV01-UKBR.domain1.systemh
> ost.net>, michael.dillon at bt.com
> wrote:
> 
> >> >? ? Ronald> Would it ever have
> been permissible for Company B to sell,
> >> >? ? Ronald> to ``gift'', or to in
> any other way transfer, just late
> >> last
> >> >? ? Ronald> year, its /18 to this
> brand new LLC, Company C?
> >
> >Companies often divest part of their operations to
> another company.
> >Sometimes they just sell network assets which would
> include a functioning
> >network and its IP addresses and customers.
> 
> I'm sorry. I wasn't clear.? I left out some important
> details.
> 
> As far as I can tell there was no transfer of customers,
> nor of any
> networking
> hardware, not of any ``hosts''.? Just the IP space.
> 
> Now, is _this_ scenario considered usual & customary?
> 
> Is it considered acceptable, under current policy?
> 
> >The receiving company generally has its own network and
> integrates the
> >two networks, reusing the old addresses on the
> integrated network before
> >decommissioning the purchased one.
> 
> Again, I may not have been clear.? The ``receiving''
> company (C) in this
> case
> was only born in October of last year.? It had no
> network of its own prior
> to that, nor any customers, prior to that, nor any IP
> addresses, prior to
> that.
> As far as I can tell, all it ever has had was the /18 it
> was given (as a
> birthday gift?) by Company B.
> 
> So now, as I have clarified it, is _this_ scenario
> considered usual &
> customary?
> 
> Is it considered acceptable, under current policy?
> 
> >Truth is stranger than fiction which means that a lot
> of oddities are
> >perfectly normal.
> 
> Yes, however this one is looking like a Greek god...
> 
> ? ``Athena leaped from Zeus's head, fully grown and
> armed -- with a
> shout...''
> 
> Company C only came into being in October of last year, and
> yet
> presto-changeo!
> It seems to have been born fully formed, like Athena, with
> its own /18
> (which,
> it would seem, may never have been justified or audited in
> any way, despite
> its being non-legacy space).
> 
> (Remember, this is _not_ ``legacy'' space we are talking
> about.? The /18 in
> question was first allocated... presumaby by ARIN, under an
> RSA... in July,
> 1999.)
> 
> So my question remains... if _someone_ creates a brand new,
> fresh, newly
> manufactured LLC, can some other company that happens to
> have an unused
> /18 lying around just ``gift'' that /18 to this new legal
> entity the
> very next day?
> 
> And if that does happen, shouldn't ARIN balk at putting the
> new entity's
> name into the WHOIS record as the new legal ``owner'' of
> the block?
> _______________________________________________
> 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 jcurran at arin.net  Tue Oct  5 18:14:06 2010
From: jcurran at arin.net (John Curran)
Date: Tue, 5 Oct 2010 18:14:06 -0400
Subject: [arin-ppml] Policy Question(s)
In-Reply-To: <16567.1286270561@tristatelogic.com>
References: <16567.1286270561@tristatelogic.com>
Message-ID: <6E785560-2860-4180-8192-4B95B7308314@arin.net>

On Oct 5, 2010, at 5:22 AM, "Ronald F. Guilmette" <rfg at tristatelogic.com> wrote:

> So my question remains... if _someone_ creates a brand new, fresh, newly
> manufactured LLC, can some other company that happens to have an unused
> /18 lying around just ``gift'' that /18 to this new legal entity the
> very next day?

Ron -

    If you believe that resources were transferred contrary to the policies as shown in the Network Resource Policy Manual, section 8 (Transfers), then report it on the already noted ARIN Fraud reporting link and we'll investigate and correct the Whois entries if changed contrary to community policy.

Thanks!
/John

From rfg at tristatelogic.com  Tue Oct  5 19:14:42 2010
From: rfg at tristatelogic.com (Ronald F. Guilmette)
Date: Tue, 05 Oct 2010 16:14:42 -0700
Subject: [arin-ppml] Policy Question(s)
In-Reply-To: <6E785560-2860-4180-8192-4B95B7308314@arin.net> 
Message-ID: <24732.1286320482@tristatelogic.com>


In message <6E785560-2860-4180-8192-4B95B7308314 at arin.net>, 
John Curran <jcurran at arin.net> wrote:

>On Oct 5, 2010, at 5:22 AM, "Ronald F. Guilmette" <rfg at tristatelogic.com> w=
>rote:
>
>> So my question remains... if _someone_ creates a brand new, fresh, newly
>> manufactured LLC, can some other company that happens to have an unused
>> /18 lying around just ``gift'' that /18 to this new legal entity the
>> very next day?
>
>Ron -
>
>    If you believe that resources were transferred contrary to the policies=
> as shown in the Network Resource Policy Manual, section 8 (Transfers), the=
>n report it on the already noted ARIN Fraud reporting link and we'll invest=
>igate and correct the Whois entries if changed contrary to community policy=


Thank you John.  Believe me, despite my reservations about what you
folks may or may not consider to be the specific types of fraud that
you feel are within your portfolio to look into, I most certainly
would (and will) accept your invitation, and report to you, via the form,
anything that, as you say, looks to me to have been contrary to the policy
as laid out in Section 8 of the NRPM.

But see, here's the problem... In this case in particular... and also
in at least one other I'm aware of... I honestly am having trouble
interpreting what the words... specifically in Section 8.3... actually
mean.  Can you please give me just a tiny bit of help with that?

    8.3. Transfers to Specified Recipients

    In addition to transfers under section 8.2, IPv4 number resources within
    the ARIN region may be released to ARIN by the authorized resource holder,
    in whole or in part, for transfer to another specified organizational
    recipient. 

This passage appears on the face of it to give you (ARIN) pretty much
carte blanche to approve inter-company transfers as you think best,
or not, as you think best.  (Note the use of the word "may".)  The above
would appear to make ARIN judge, jury, and executioner for all inter-company
and/or inter-organization transfer requests.  (Does that sound about right?
Or am I misreading it?)

So anyway, is this what happened with regards to 216.59.128.0/18 ?  I mean
did you folks simply elect, within your reasonable and authorized discretion,
to allow a older company to transfer this 11 year old block to a company
that was newly formed only last year, in October of 2009 ?

If that's all that happened here, then gosh no!  In that case there's
certainly no fraud and nothing for me to report.  (And in fact, my
lawyer tells me that if there's no fraud, and if I nontheless report
something to you via your ``fraud'' form, then that act, on my part,
could very well be actionable.  Yikes!)

So again, this is a policy question:  May a company which is still very
much alive and kicking request that ARIN transfer some block it owns
to some brand new, newly manufactured company with no history whatsoever?
Is that permissible under ARIN's discretion granted in 8.3. as set forth
above?  And even if it is permissible for some company to _request_ such
a transfer, is it permissible, under the policy, for ARIN to _grant_ such
a request?   And if it is actually permissible under 8.3. to do that exact
thing, then may *I* go forth now and start buying up blocks of ARIN region
IP space, you know, as an investment, with equal confidence that you will
willingly transfer any blocks that I might buy to _my_ new company, just
as, it would appear, ARIN did in the case of 216.59.128.0/18 ?

And if the answers to all of the above questions are "no", then really,
I would very much like to know how an 11 year old block that belonged
to a company that is very much still alive (http://globalitcom.com/)
ended up registered to a shadowy mystery company that has no web site
and that, according to California Secretary of State online records,
was only formed just late last year (i.e. orangeisp.com[1]).

This is only marginally a question about what policies did or did not
allow _these companies_ to effect or to request this transfer.  It is
really more a question about what policy or policies _ARIN_ was being
guided by when it approved and allowed this transfer.

(Note: I rather doubt that Orange County Networks, LLC sent you ARIN folks
any fradulent documents claiming to be an 11 year old company, and even
if they had done so, it would have been easy enough for you folks to check
and disprove that online, in just a few seconds.  So it would appear that
ARIN knowingly approved the transfer of an 11-year-old /18 block to what it
knew, or could easily have known, was a brand new... albeit somewhat dubious...
company.)

So anyway, that's really the crux of the matter, from my perspective.  And
any light you can shed on the specific policy verbage, within Section 8,
that may have either authorized or mandated ARIN to effect this transfer
will be much appreciated.  (Obviously, as I've noted, the exact policies
ARIN is actually following with respect to inter-organization transfers
have some potentially HUGE financial implications... implications that,
in time, may ultimately affect everyone within the ARIN region.)


Regards,
rfg


========
[1]  John, at least, and maybe some others here, already know what types of
companies I tend to pay special attention to on the Internet.  People can,
I suspect, draw proper inferences from that, without me having to say any-
thing else explicitly.


From jcurran at arin.net  Tue Oct  5 21:42:22 2010
From: jcurran at arin.net (John Curran)
Date: Tue, 5 Oct 2010 21:42:22 -0400
Subject: [arin-ppml] Policy Question(s)
In-Reply-To: <24732.1286320482@tristatelogic.com>
References: <24732.1286320482@tristatelogic.com>
Message-ID: <9BA834B5-C1E2-48B9-A99D-6354CAB94693@arin.net>

On Oct 5, 2010, at 7:14 PM, Ronald F. Guilmette wrote:

> But see, here's the problem... In this case in particular... and also
> in at least one other I'm aware of... I honestly am having trouble
> interpreting what the words... specifically in Section 8.3... actually
> mean.  Can you please give me just a tiny bit of help with that?
> 
>    8.3. Transfers to Specified Recipients
> 
>    In addition to transfers under section 8.2, IPv4 number resources within
>    the ARIN region may be released to ARIN by the authorized resource holder,
>    in whole or in part, for transfer to another specified organizational
>    recipient. 
> 
> This passage appears on the face of it to give you (ARIN) pretty much
> carte blanche to approve inter-company transfers as you think best,
> or not, as you think best.  (Note the use of the word "may".)  The above
> would appear to make ARIN judge, jury, and executioner for all inter-company
> and/or inter-organization transfer requests.  (Does that sound about right?
> Or am I misreading it?)

You somehow omitted the second sentence of the policy, shown below for 
reference:

     Such transferred number resources may only be received under RSA
     by organizations that are within the ARIN region and can demonstrate 
     the need for such resources, as a single aggregate, in the exact 
     amount which they can justify under current ARIN policies.

So, your answer is "No", i.e. ARIN can only approve transfers from one 
party to another once the receiving organization has been approved for
those resources in the same amount as under current address allocation 
policy.

> So anyway, is this what happened with regards to 216.59.128.0/18 ?  I mean
> did you folks simply elect, within your reasonable and authorized discretion,
> to allow a older company to transfer this 11 year old block to a company
> that was newly formed only last year, in October of 2009 ?

Ron - I'm happy to discuss how any section of the policy manual is 
implemented (although we have a registration services help desk which 
is available, both via phone and in person at the ARIN meetings, which 
can help answer any of your questions as well, and is more appropriate
than using the PPML as a help desk...)

In any case, we cannot discuss specific resource actions for another 
party in any circumstance; the information regarding such actions is 
subject to the NDA between ARIN and each resource holder.

> ...
> So again, this is a policy question:  May a company which is still very
> much alive and kicking request that ARIN transfer some block it owns
> to some brand new, newly manufactured company with no history whatsoever?

ARIN will approve a transfer to the new entity of the same amount of space
that it can qualify for today under current policies.  (Since we still
have address space available, it might be simply for them once so approved
to simply accept from ARIN's resource pool, yes?)

> So it would appear that ARIN knowingly approved the transfer of an
> 11-year-old /18 block to what it knew, or could easily have known,
> was a brand new... albeit somewhat dubious... company.)

To repeat for clarity: If you believe that resources were transferred 
contrary to the policies as shown in the Network Resource Policy Manual, 
section 8 (Transfers), then report it on the already noted ARIN Fraud 
reporting link and we'll investigate and correct the Whois entries if 
changed contrary to community policy. 

Thanks!
/John

John Curran
President and CEO
ARIN



From michael.dillon at bt.com  Wed Oct  6 02:45:15 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 6 Oct 2010 07:45:15 +0100
Subject: [arin-ppml] Policy Question(s)
In-Reply-To: <9BA834B5-C1E2-48B9-A99D-6354CAB94693@arin.net>
References: <24732.1286320482@tristatelogic.com>
	<9BA834B5-C1E2-48B9-A99D-6354CAB94693@arin.net>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423937780141@EMV01-UKBR.domain1.systemhost.net>


> To repeat for clarity: If you believe that resources were transferred
> contrary to the policies as shown in the Network Resource Policy
> Manual,
> section 8 (Transfers), then report it on the already noted ARIN Fraud
> reporting link and we'll investigate and correct the Whois entries if
> changed contrary to community policy.

He is not the first person to misinterpret the word "fraud" in this
context. What needs to be done to change the name of that link
and reporting tool to "Suspicious Address Records Reporting"
so that we can ask people to report anything suspicious?

--Michael Dillon




From tedm at ipinc.net  Wed Oct  6 04:53:52 2010
From: tedm at ipinc.net (tedm at ipinc.net)
Date: Wed, 6 Oct 2010 01:53:52 -0700 (PDT)
Subject: [arin-ppml] Policy Question(s)
In-Reply-To: <20225.1286280354@tristatelogic.com>
Message-ID: <alpine.BSF.2.00.1010060153520.57601@atlas.ipinc.net>




On Tue, 5 Oct 2010, Ronald F. Guilmette wrote:

>
> In message <0F29D1BA57992E4CAB5AD2C9AE7B42393777FCBE at EMV01-UKBR.domain1.systemh
> ost.net>, michael.dillon at bt.com wrote:
>
>>> So my question remains...
>>
>> You ask too many questions.
>
> I want to learn what the policy is.  If you have a better way for me to
> do that, please indicate that to me.
>
> I have read the applicable documents available on the ARIN web site. They
> are ambiguous at best.

That is because much of ARIN policy comes from committee.  It is the nature
of politics that you can often not get consensus on specific policy that
prohibits something where you CAN get consensus on GENERAL policy that
when interpreted, will prohibit that very same thing.  To put it succinctly,
people often don't know what they are voting for.

The US Constitution for example states "we the people.....secure the blessings of
liberty to ourselves.."   This was signed, you recall, by slavers, among others.
It never would have been signed if it stated "we the white and colored male
and female people..."  Yet, if you read the writings of the authors of the US Constitution it is clear that the abolitionists among those authors intended that phrase to apply to both
white and black people.  They knew the current interpretation of that would
not allow it to apply to both - but they hoped that future interpretation would.
Which of course, it eventually did.  And, further future interpretations redefined
"people" to include both men and women - something that I think NO Constitution
author expected.

Possibly some of the slavers who signed the US Constitution were also aware of
this possible future interpretation - but they of course hoped it would never
come about.

You really cannot fully understand all ARIN policy unless you understand that
ARIN policy consists both of the written policy - and the interpretation of
that written policy.

>  They do not answer these questions.
>
>> ARIN has a fraud reporting page at <https://www.arin.net/resources/fraud/>.
>
> Who said anything about fraud??
>
> Why would I use that ``fraud'' form when, as far as I can make out, nothing
> in the least bit fradulent has occured, i.e. in the case I have described
> here?
>
>> Use it and stop asking so many silly repetitive questions.
>
> I wasn't aware my questions were repetitive.
>
>> Oh, by the way, this list is for discussing ARIN policy,
>
> Sir, I have been looking all night at a rather lengthy discussion that
> took place ON THIS LIST just two short years ago in which several
> participants debated what the policies should be, specifically for
> legacy blocks.  That debate was vigorous and, as I say, lengthy.
> And from my reading of it, it is not at all clear that the policy was
> at all well defined, either at the end of that discussion, or since.
>
> Regardless, it does seem as though you are ORDERING me, unilaterally,
> not to discuss something on this list that quite clearly was an appropriate
> topic of discussion, right here, on this very list, just two short years
> ago.
>
> If you can enlighten me as to why you think I'm off-topic for this list,
> I'm all ears.
>
> But first allow me to poinyt out that the several gentlemen behind this
> endeavor:
>
>     http://www.depository.net/
>
> would like, it seems, to foster a marketplace for IP addresses.  I would
> like to do likewise, considering how easy it _appears_ to be to buy and
> sell sizable IP address blocks at the current moment.  Here is another
> entity that seems to already be peddling /24s openly, as we speak:
>
>    http://www.jump.ro/ip.html
>
> I have money to invest, and I am ready to proceed.  I would like to start
> buying and selling IP addresses, in bulk.
>
> Now, can you just tell me please:  Will I be thwarted in this business venture
> by _secret_ unpublished rules regarding  inter-company IP address block
> transfers... secret unwritten rules that appear, magically, out of thin air,
> just _after_ I have invested my time, effort, and money in this venture?
>

My interpretation of ARIN policy is that you WILL.  Not because of any 
'secret unpublished rules" but because as of yet ARIN has not openly
declared war on these "IP address peddlers"

There's no question that any reasonable reading of the policy allows
ARIN to hang these people up to dry.  All it would take is for ARIN to
deny a WHOIS entry for a block that depository.net "sold" and the
"buyer" of the block from depository.net would start screaming, demanding
their money back, and depository.net would go down the drain.

But, I don't think ARIN is doing this yet for a very simple reason - there
are addresses still available.  Instead I think what is happening is
that if Mr. Smith shows up on ARIN's door with a block that he "bought"
from depository.net, AND with justification for it, that ARIN's hostmaster
is granting the transfer but also saying "by the way, you did NOT need to
spend $$$ with depository.net, you could have got the IP numbers from
us, FREE"

Now, with all of that said, also in my interpretation of the policy, NOTHING
is wrong with setting youself up as an "IP address broker" that is, someone
who gets a fee for facilitating an IP address transfer from one entity to
another.

For example you could approach a legacy address holder who has obviously
abandonded their legacy holdings or is sparsely using them, and say
"If you sign a contract with me saying that I'm your exclusive IP address
rep. I'll guarentee you will get XXX dollars for every block of yours
I help you to transfer"

> Maybe you understand what I'm getting at, or maybe you don't, or maybe you
> just don't care, because these are not ARIN-related policy questions that
> happen to affect you or be of interest to you.  But maybe I'm actually not
> the only person on this planet who might be curious, as I am, as to whether
> or not a ``marketplace'' in IP address blocks _already_ does exist within
> the ARIN region, as this example (and others) would tend to indicate:
>
>   NET-216-59-128-0-1
>
> and also, whether this current ``marketplace'' is something that ARIN is
> merely tolerating for the moment, or whether this marketplace is in fact
> now ready for people to make investments (e.g. in brokerage businesses)
> without fear that ARIN is going to come in, in the ninth inning as it were,
> and, like some modern day Elloit Ness, raid the game and take away all of
> the chips...  unilaterally and suddenly.  (Obviously, if this is a real
> possibility, then one would have to be a fool to invest in an IP brokerage
> business at this time.)
>

Well I think here you have a lot of problems with either very sloppy use of
terminology or a fundamental lack of understanding of how things work.

A "brokerage house" does not own anything.  What a broker does is they
use other people's money to buy and sell things and they make a
commission on the deal.  An "IP brokerage" business would be nothing more
than a boiler room operation with a bunch of guys dialing for dollars,
trying to make transfers between people who are willing to shed IP
addresses and people wanting to acquire IP addresses.  This is permissible
under ARIN policy, in my opinion.

of course, recognise that an org with extra IP does not need to use
a broker to dispose of IP.  In this way it's a bit different than
the stock market, since the stock market requires stock transactions to
be done by a broker, thus (in my opinion) guarenteeing an income stream
to people who basically sit on their ass all day long, wrecking the
US economy.  But an "IP Brokerage" house could argue that they have the
contacts to be able to rapidly dispose of extra IP for a much higher amount
of money, plus the expertise to help the org to do it.  So maybe such
an operation could catch some flies that way.

But, an "IP Investment bank" which operated as a straight broker plus
also gained ownership over IP address blocks (like how many stock brokerage
houses which also played the market did with stocks not too long ago)
in order to "sell" them would be a violation, in my interpretation.

IMHO you would be a fool to attempt to invest or setup an "IP investment
bank"  But an "IP Brokerage" that's a horse of a different color.

> Note:  The above indicated IP address block is quite certainly _not_ the
> only example I have in hand where there was apparently a sale (or a
> ``gifting'') of a sizable IP block... apparently sanctioned in some way
> by ARIN... although it is more than a little bit unclear exactly _how_
> that might have occurred, under the existing policies.  (Do some entities
> get special, preferential treatment?  Do you?  Will I?)
>
> So, to quote Shakespere  ``Methinks the lady doth protest too much!''
> Your extraordinary hostility towards even allowing a discussion of this
> subject to take place, in this very appropriate venue, actually just
> piques my interest even more!
>
> Why is this policy question too ``touchy'' a subject... you know... the
> question about the policy by which ARIN sanctions some IP block sales,
> even while, apparently denying others...  why is that too touchy a POLICY
> subject to be discussed on this list?
>

It is not, if you would actually use correct terminology.  Starting with
the sentence "IP block sales"  You cannot "sell" an IP block because IP
addresses are not property and thus cannot be owned.  It may be convenient
to bandy about such sloppy terminology when marketing to the ignorant but
if you went to your local DMV and
start loudly demanding that you "own" the alphanumeric characters on your
vanity license plate and thus shouldn't have to pay extra to register them
I think you would find yourself booted out on your ass.

> Despite your claims to the contrary, I _have_ been asking policy questions.
> And I have been asking them here on this thing that's titled the ``public''
> policy mailing list.  (Did I misread that ``public'' part?)  It's clear
> that for some parties, these questions might be uncomfortable.  I understand
> that.   And it's equally clear to me that those same interests can stiffle
> and prevent these questions from even being asked, here or elsewhere.  But
> let's not kid ourselves.  I have been asking serious on-topic policy questions.
> I'm sure if you work at it, you'll be able to successfully gag the messsenger,
> but if your only basis for gagging me is the clearly false claim that I've
> been in the least bit off-topic... well then I hope this will be seen for
> what it is, i.e. just gagging of somebdoy who asked questions that made
> certain folks uncomfortable... NOT because I was at all off-topic.  (And
> there are reams and reams of discussions in the archives of this list where
> these same questions about buying and selling IPs, and the complex problems
> of legacy block ownerhsip and transfers been discussed...  and not just a
> little, a lot.)
>

whaa whaa whaa I didn't get my lollypop at the bank.  Just drop the victim
ranting, please.  It doesen't add anything.  When they start censoring
you THEN you can complain.

>> ... not for haranging people...
>
> I haven't been ``haranging'' anybody!  I clarified my question just a tiny bit,
> just so that I could maybe have some hope of actually finding out what the
> bloody rules are, that's all!  (And it's pretty clear that not all of them are
> even written down.)
>
> So why is your reaction so hot?
>
> I am honestly perplexed.
>
>> ... about stuff that is unrelated to policy and is, in fact, already
>> being handled by ARIN staff.
>
> What is?  What exactly do you think is ``already being handled by ARIN staff'' ?
>
> I have no idea what you are talking about.  Seriously.  Can you explain?
> Are either you or ARIN so prescient that you knew about NET-216-59-128-0-1,
> in particular, before I even mentioned it???
>
> Hey!  That's a neat trick!
>
> So I'm guessing then that you already know all about the other three blocks
> I was going to mention (and I guess ARIN does too, even though I've never
> once mentioned them before to anybody), and that's Good, because then you
> can educate me as regards to how _those_ sales got formally blessed.
>

The RIR (unfortunately, IMHO) at the current time does not owe you or I or anyone an explanation of why a particular block ownership has suddenly changed.  I personally
and professionally wish this was not the case.  But the problem is that so many
of the players out there regard this sort of data as competitive secrets data
that the RIR is in the position where it absolutely MUST guarentee the parties
involved in block transfers confidentiality under a legal NDA or practically
nobody would deal at all with ARIN.

So you will get nowhere by demanding to know why NET-216-59-128-0-1 seems to
have magically changed ownership from one entity to another.  If ARIN knows
why they are contractually prevented from telling you even if they wanted to.
The rest of us in the ARIN community undertand why this is.  We long ago
decided that it was much more important for the Internet to use a single
WHOIS database that was authoratative so that everyone would agree on who
was allowed to use what, than it was to have transparency in how any particular
entity manages to justify why they deserve what IP addresses they have.  So
we compromised and sacrificed transparency so that we could get compliance.

>
> Regards,
> rfg
>
>
> P.S.  I _do_ understand that quite a lot of people... probably a majority
> in fact, both here and elsewhere... actually loath and despise the whole
> idea of IP address block ``brokerages''.  Acutally, despite what I said
> above, I do too.  But you know, like it or not, the evidence is in, and it
> seems to be going on already, right now, anyway.  And as the character
> Yoasarian often said in Joseph Heller's `Catch-22' ``If everybody else
> was doing it, then I'd be a damn fool to do any different.''  And at this
> moment, it _does_ appear to me that everybody else is already doing it.
>
> So if that's the case, then why should _I_ be the only one who _isn't_
> climbing on board the gravy train?  I mean seriously, why?  Just because
> I'm not an ``insider'' and an old established member of the club?

I think that this is a rather amusing interpretation of what's going on.
I am quite sure that there's no "gravy train" out there, at least, not
yet.  I'm also quite sure that a lot of these people like this depository.net
are hoping that there might be a gravy train and are trying to put their
claim in it, should such train ever come down the tracks.

I will say this, though.  A good "IP Broker" or "IP realtor" or "IP sales agent"
or whatever you want to call yourself, COULD HELP greatly during the
upcoming IPv4 endgame.  Such a person would have to at the least, be
able to do the following:

1) Assist orgs with existing holdings in shrinking their existing usage,
whether that means renumbering, or increased use of NAT or other network
restructuring, in a way that would free up a block that would meet criteria
to be elegible for transfer.

2) Be familiar with the paperwork involved in the transfer process itself
to be able to help the "shedding" org and the "acquiring" org to deal
with ARIN or other RIR, plus deregister the old org's use of the block
from it's upstreams and help the new org register the block usage with it's
upstreams.

3) Be able to qualify "acquiring" orgs to meet justification criteria for
obtaining the transfer block in the first place.

4) Be able to develop a list of "shedding" orgs of different sizes of
IP blocks so that "acquiring" orgs would be able to select the appropriate
sized block.

5) Be able to assist in escrowing funds from the "acquiring" org intended
to be paid to the "shedding" org on completion of successful block transfer.

If you could do that, you would be a help.  You could make money doing it.
It would NOT be a huge pile of money.  But it would be no less profitable than
any other honest work of this type out there - such as being a Realtor or upscale used
car salesman, etc.

But the idea that all you need to do is throw up a Wordpress website with a
few IP transfer templates on it and sit back and have oodles of money
rolling in for doing nothing is a lot of baloney.  It's not going to happen.

Ted




From rfg at tristatelogic.com  Wed Oct  6 06:46:13 2010
From: rfg at tristatelogic.com (Ronald F. Guilmette)
Date: Wed, 06 Oct 2010 03:46:13 -0700
Subject: [arin-ppml] Policy Question(s)
In-Reply-To: <alpine.BSF.2.00.1010060153520.57601@atlas.ipinc.net> 
Message-ID: <30271.1286361973@tristatelogic.com>


In message <alpine.BSF.2.00.1010060153520.57601 at atlas.ipinc.net>, 
tedm at ipinc.net wrote:

>> I have read the applicable documents available on the ARIN web site. They
>> are ambiguous at best.
>
>That is because much of ARIN policy comes from committee.  It is the nature
>of politics that you can often not get consensus on specific policy that
>prohibits something where you CAN get consensus on GENERAL policy that
>when interpreted, will prohibit that very same thing.  To put it succinctly,
>people often don't know what they are voting for.

Well, thank you.  You know, for plain simple honesty.

I well and truly understand... and abide... that every law or rule must be
interpreted.  And for that, we have things like ARIN and the U.S. Judiciary.

But of course, in the case of the judiciary, when _they_ get done interpreting
one of their rules, that interpretation quite often gets published, in public,
and becomes ``binding''.  This is great because then, in future, everybody
knows where they stand and what they can do and not do.

But apparently, every time ARIN interprets one of its rules... you know...
like the judiciary would... to fit some new and novel set of facts... then
*their* decision gets burried under layers of NDAs, and is never heard from
again.

Am I the only one who sees a potential problem with this?

>You really cannot fully understand all ARIN policy unless you understand that
>ARIN policy consists both of the written policy - and the interpretation of
>that written policy.

Right.  Believe me, I understood that part before I even posted here the
first time, and in fact that is precisely _why_ I posted here the first
time... because I have first-hand knowledge that there is, on the one hand,
the law, as written, and then there is, on the other hand, the interpretation
of the law, with respect to various sets of facts, and the two are different
and separate.

>But, I don't think ARIN is doing this yet for a very simple reason - there
>are addresses still available.  Instead I think what is happening is
>that if Mr. Smith shows up on ARIN's door with a block that he "bought"
>from depository.net, AND with justification for it, that ARIN's hostmaster
>is granting the transfer but also saying "by the way, you did NOT need to
>spend $$$ with depository.net, you could have got the IP numbers from
>us, FREE"

Free???  Did you say FREE??  Hay!  That just happens to be my favorite number!

But seriously folks, was I asleep?  Did I fail to get the memo?  Is ARIN
actually not charging for IP space anymore?  Funny, I could have sworn
I saw a fee chart on their web site just the other day.  And I was
thinking, hay, if I could talk somebody out of their (fee-free?) legacy
/16, and if I could keep it and ``monitize'' it for, say, ten years, then,
you know, without going thru all of the fancy schmancy ``present value''
calculations that people who play with money for a living know about,
my very rough estimate is that that would be worth approximately
10 * $4,500 == $45k.   That's minimum, of course, because that only
represents how much you'd save on fees, you know, relative to your
competitors who have non-legacy blocks.

>For example you could approach a legacy address holder who has obviously
>abandonded their legacy holdings or is sparsely using them, and say
>"If you sign a contract with me saying that I'm your exclusive IP address
>rep. I'll guarentee you will get XXX dollars for every block of yours
>I help you to transfer"

May I say to them instead ``I'll give you $10k right now for all rights
and title to that legacy /16 you have lying over there in the corner,
collecting dust.'' ?

See, like you said, there's middlemen, and then there's players.  Middlemen
just facilitate transfers from A to B.  Players actually buy and hold
_themselves_ hoping for the price to go up.

I wanna be a player.  So now I just need to know if ARIN will let me put
_my_ name on any legacy /16 I manage to aquire all existing rights and
title to, you know, from the original owner, and of course, I'd also
like to know if they will also delegate reverse DNS to me.

>But, an "IP Investment bank" which operated as a straight broker plus
>also gained ownership over IP address blocks (like how many stock brokerage
>houses which also played the market did with stocks not too long ago)
>in order to "sell" them would be a violation, in my interpretation.

A violation of what, exactly?

I guess you mean of NRPM section 8, but I don't think I saw anything really
concrete in there that was an actual prohibition.  (Can you quote me the
actual prohibition language out of the NRPM?)

And again, are we talking about the letter of the law, or are we talking
about its interpretation, and existing precedents?

>IMHO you would be a fool to attempt to invest or setup an "IP investment
>bank"

Well, that's what seemed to me might be a profitable thing to do, and I
am not at all persuaded that ARIN could really stop me (or anyone) if
somebody did that, and if they were dealing only in legacy blocks.

>You cannot "sell" an IP block because IP
>addresses are not property and thus cannot be owned.

Ok, ok.  So I'll use the terms ``leased'' and ``sub-leased'' instead.
Or ``sub-leased right-to-use'' or whatever the lawyers decide to call
it.  Will that work?

(This is starting to remind me of the old bar joke... you know... Nobody
ever actually ``buys'' beer.  You just rent it.  I guess that we could
say that about everything, because we'll all die eventually, and all that
beer we drank and all that food we consumed, and all of those PlayStations
we threw into the dumpster after they stopped working will all be returned
to the earth someday, one way or the other.)

>When they start censoring you THEN you can complain.

Ummm... I guess you don't see the rather obvious logical falacy in what
you just said...

... but as I look at it some more, what you just said is actually awfully
darned humorous.  Did you copyright that, or may I use it as a .sig?

>The RIR (unfortunately, IMHO) at the current time does not owe you or I or any
>one an explanation of why a particular block ownership has suddenly changed.  
>I personally
>and professionally wish this was not the case.  But the problem is that so man
>y
>of the players out there regard this sort of data as competitive secrets data
>that the RIR is in the position where it absolutely MUST guarentee the parties
>involved in block transfers confidentiality under a legal NDA or practically
>nobody would deal at all with ARIN.

Yes.

So much for ``open'' Internet governance.

>we compromised and sacrificed transparency so that we could get compliance.

I'm wondering if it occured to anybody, during the making of that decision,
that what such a decision inevitably yields is an impenetrable Star Chamber,
making un-reviewable decisions, in secret, that nobody ever even finds out
about, let alone being able to question or understand.

I mean yes, I'm quite sure that all the people involved are of sound and
good character... I take that as a given.  I'm sure they're all good
people trying their best to do the right thing.  But the very _notion_
of secrecy rubs the wrong way for some people.  I just happen to be one
of them.

>I think that this is a rather amusing interpretation of what's going on.
>I am quite sure that there's no "gravy train" out there, at least, not
>yet.

Well, that's your view, based on what you know... But how do you know?
I mean how does anybody know?  As you've noted, all these decisions
about what may or may not get transfered, and to whom, are being made at
this point, and have been made, since ARIN took over, with the same level
of secrecy as the election of the next pope, i.e. total.  Right?  Because
everybody (or at any rate, a majority) wanted it that way.  OK fine. I
get that part.  But now, here we are, and you actually can't tell me
for certain, one way or the other, whether or not there's some Internet
version of Gordon Gecko out there already, buying up IP real estate,
quietly and secretly, and getting all those blocks quietly transfered
to himself... or rather to his various paper subsidiaries... , again,
very quietly.  (Perhaps this sounds far fetched, but do you happen to
know about a company called Tactara?  Do you know how much IP real
estate they've managed to amass, by hook or by crook?)

Am I saying this _is_ happening _generally_ and other than in the one
special case I just mentioned?  Of course not.  Not at all. Am I saying
that anyone at ARIN is giving unfair advantage to any one party, or even
to any set of favored parties?  Again, no, of course not.  Not at all.
What I _am_ saying is that secrecy breeds suspicion.

>I'm also quite sure that a lot of these people like this depository.net
>are hoping that there might be a gravy train and are trying to put their
>claim in it, should such train ever come down the tracks.

As far as we know, the train is already rolling.  Secrecy, remember?
Everything is under a thick warm fuzzy blanket of NDAs.

What I _can_ tell you is that I've made a special study of so-called
snowshoe spammers.  These people consume (and lay waste to) IP space
just like the proverbial stuff-through-a-goose.  And when I find...
within the IPv4 space... another one of these operations... of which
there are hundreds, as we speak, sometimes it is obvious where they
are getting their IP space, i.e. from crooked ISPs that are lying to
ARIN about their sub-allocations and their effective utilization rates.
But at other times, it is not at all obvious how one of these criminals
managed to glom onto a big fat hunk of IP space in a time of alleged shortage.

Such cases perplex me.  And I would argue that secrecy in these cases
not only doesn't provide an answer to me personally, more importantly,
in my opinion, it is counter to the best interests of the community.
It's like saying that child molesters have a right-of-privacy, and so
we ain't gonna tell you when one moves in two doors down from you.
That used to be acceptable, but in a lot of places, it isn't anymore.

Well, ok, I didn't actually intend to get off on this at all.  I know
full well that the secrecy isn't going away anytime soon.  And I don't
fault anybody at ARIN for its existance, because, as you noted, it was
a ``community'' decision, made long ago, and basically, the lawyers won.
(Note: *Not* ARIN's lawyers... everybody else's.)  But to say that it's
a done deal and a fully settled matter, decided long long ago...  well...
that's what a lot of people used to say about the privacy rights of
child molesters. In short, times change, and rules evolve.  I can hope
anyway.

And a whole lot less secrecy wouldn't just help to get more spammers
off the streets.  It also seems to me to be a prerequsite for the
development of a fair and open marketplace for IP space... a marketplace
that even ARIN itself floated a proposal for a couple of years ago.  I
mean can you really imagine being a business man and investing your
own money in an environment where your major assets, your stock in
trade, may be subject to effective confiscation at any moment by a
secretive Star Chamber whose decisions are un-reviewable?  No investor
in his right mind would put his money into THAT!  Well... no _ordinary_
investor.  So what we will predictably end up with, as the exhaustion
end game starts to unfold, will be some real slick operators... definite
black market types that will charge people truly astronomical prices
for even a tiny bit of IP turf.  They'll have to, in order to make up
for their potentially very high ``breakage'' rate.

>But the idea that all you need to do is throw up a Wordpress website with a
>few IP transfer templates on it and sit back and have oodles of money
>rolling in for doing nothing is a lot of baloney.  It's not going to happen.

Me personally?  I never had anything like THAT even remotely in mind.
I'm old fashioned.  I believe in making money the old fashion way,
earning it.

Regards,
rfg


From tom.greenhaw at novalibra.com  Wed Oct  6 08:49:47 2010
From: tom.greenhaw at novalibra.com (Tom Greenhaw)
Date: Wed, 06 Oct 2010 07:49:47 -0500
Subject: [arin-ppml] Policy Question(s)
In-Reply-To: 20225.1286280354@tristatelogic.com
Message-ID: <20101006124947.7cee700c@mail.novalibra.com>

Address space resellers and the original owners of that address space are in clear violation of their justification commitments to ARIN and the Internet community at large.

Legitimate use of IPV4 space can be substantially lengthened by enforcement of the existing justification policies.

How nice of these fine people to aggregate nice large blocks of fraudulently obtained space making it easy to locate. I would applaud a sting operation targeting address space squatters to return their ill gotten addresses back to legitimate users.

Tom Greenhaw




----- Original Message -----
From: Ronald F. Guilmette
[mailto:rfg at tristatelogic.com]
To: arin-ppml at arin.net
Sent: Tue, 05 Oct 2010
07:05:54 -0500
Subject: Re: [arin-ppml] Policy Question(s)


> 
> In message
> <0F29D1BA57992E4CAB5AD2C9AE7B42393777FCBE at EMV01-UKBR.domain1.systemh
> ost.net>, michael.dillon at bt.com wrote:
> 
> >> So my question remains... 
> >
> >You ask too many questions. 
> 
> I want to learn what the policy is.  If you have a better way for me to
> do that, please indicate that to me.
> 
> I have read the applicable documents available on the ARIN web site. They
> are ambiguous at best.  They do not answer these questions.
> 
> >ARIN has a fraud reporting page at <https://www.arin.net/resources/fraud/>.
> 
> Who said anything about fraud??
> 
> Why would I use that ``fraud'' form when, as far as I can make out, nothing
> in the least bit fradulent has occured, i.e. in the case I have described
> here?
> 
> >Use it and stop asking so many silly repetitive questions.
> 
> I wasn't aware my questions were repetitive.
> 
> >Oh, by the way, this list is for discussing ARIN policy,
> 
> Sir, I have been looking all night at a rather lengthy discussion that
> took place ON THIS LIST just two short years ago in which several
> participants debated what the policies should be, specifically for
> legacy blocks.  That debate was vigorous and, as I say, lengthy.
> And from my reading of it, it is not at all clear that the policy was
> at all well defined, either at the end of that discussion, or since.
> 
> Regardless, it does seem as though you are ORDERING me, unilaterally,
> not to discuss something on this list that quite clearly was an appropriate
> topic of discussion, right here, on this very list, just two short years
> ago.
> 
> If you can enlighten me as to why you think I'm off-topic for this list,
> I'm all ears.
> 
> But first allow me to poinyt out that the several gentlemen behind this
> endeavor:
> 
>      http://www.depository.net/
> 
> would like, it seems, to foster a marketplace for IP addresses.  I would
> like to do likewise, considering how easy it _appears_ to be to buy and
> sell sizable IP address blocks at the current moment.  Here is another
> entity that seems to already be peddling /24s openly, as we speak:
> 
>     http://www.jump.ro/ip.html
> 
> I have money to invest, and I am ready to proceed.  I would like to start
> buying and selling IP addresses, in bulk.
> 
> Now, can you just tell me please:  Will I be thwarted in this business
> venture
> by _secret_ unpublished rules regarding  inter-company IP address block
> transfers... secret unwritten rules that appear, magically, out of thin air,
> just _after_ I have invested my time, effort, and money in this venture?
> 
> Maybe you understand what I'm getting at, or maybe you don't, or maybe you
> just don't care, because these are not ARIN-related policy questions that
> happen to affect you or be of interest to you.  But maybe I'm actually not
> the only person on this planet who might be curious, as I am, as to whether
> or not a ``marketplace'' in IP address blocks _already_ does exist within
> the ARIN region, as this example (and others) would tend to indicate:
> 
>    NET-216-59-128-0-1
> 
> and also, whether this current ``marketplace'' is something that ARIN is
> merely tolerating for the moment, or whether this marketplace is in fact
> now ready for people to make investments (e.g. in brokerage businesses)
> without fear that ARIN is going to come in, in the ninth inning as it were,
> and, like some modern day Elloit Ness, raid the game and take away all of
> the chips...  unilaterally and suddenly.  (Obviously, if this is a real
> possibility, then one would have to be a fool to invest in an IP brokerage
> business at this time.)
> 
> Note:  The above indicated IP address block is quite certainly _not_ the
> only example I have in hand where there was apparently a sale (or a
> ``gifting'') of a sizable IP block... apparently sanctioned in some way
> by ARIN... although it is more than a little bit unclear exactly _how_
> that might have occurred, under the existing policies.  (Do some entities
> get special, preferential treatment?  Do you?  Will I?)
> 
> So, to quote Shakespere  ``Methinks the lady doth protest too much!''
> Your extraordinary hostility towards even allowing a discussion of this
> subject to take place, in this very appropriate venue, actually just
> piques my interest even more!
> 
> Why is this policy question too ``touchy'' a subject... you know... the
> question about the policy by which ARIN sanctions some IP block sales,
> even while, apparently denying others...  why is that too touchy a POLICY
> subject to be discussed on this list?
> 
> Despite your claims to the contrary, I _have_ been asking policy questions.
> And I have been asking them here on this thing that's titled the ``public''
> policy mailing list.  (Did I misread that ``public'' part?)  It's clear
> that for some parties, these questions might be uncomfortable.  I understand
> that.   And it's equally clear to me that those same interests can stiffle
> and prevent these questions from even being asked, here or elsewhere.  But
> let's not kid ourselves.  I have been asking serious on-topic policy
> questions.
> I'm sure if you work at it, you'll be able to successfully gag the
> messsenger,
> but if your only basis for gagging me is the clearly false claim that I've
> been in the least bit off-topic... well then I hope this will be seen for
> what it is, i.e. just gagging of somebdoy who asked questions that made
> certain folks uncomfortable... NOT because I was at all off-topic.  (And
> there are reams and reams of discussions in the archives of this list where
> these same questions about buying and selling IPs, and the complex problems
> of legacy block ownerhsip and transfers been discussed...  and not just a
> little, a lot.)
> 
> >... not for haranging people...
> 
> I haven't been ``haranging'' anybody!  I clarified my question just a tiny
> bit,
> just so that I could maybe have some hope of actually finding out what the
> bloody rules are, that's all!  (And it's pretty clear that not all of them
> are
> even written down.)
> 
> So why is your reaction so hot?
> 
> I am honestly perplexed.
> 
> >... about stuff that is unrelated to policy and is, in fact, already
> >being handled by ARIN staff.
> 
> What is?  What exactly do you think is ``already being handled by ARIN
> staff'' ?
> 
> I have no idea what you are talking about.  Seriously.  Can you explain?
> Are either you or ARIN so prescient that you knew about NET-216-59-128-0-1,
> in particular, before I even mentioned it???
> 
> Hey!  That's a neat trick!
> 
> So I'm guessing then that you already know all about the other three blocks
> I was going to mention (and I guess ARIN does too, even though I've never
> once mentioned them before to anybody), and that's Good, because then you
> can educate me as regards to how _those_ sales got formally blessed.
> 
> 
> Regards,
> rfg
> 
> 
> P.S.  I _do_ understand that quite a lot of people... probably a majority
> in fact, both here and elsewhere... actually loath and despise the whole
> idea of IP address block ``brokerages''.  Acutally, despite what I said
> above, I do too.  But you know, like it or not, the evidence is in, and it
> seems to be going on already, right now, anyway.  And as the character
> Yoasarian often said in Joseph Heller's `Catch-22' ``If everybody else
> was doing it, then I'd be a damn fool to do any different.''  And at this
> moment, it _does_ appear to me that everybody else is already doing it.
> 
> So if that's the case, then why should _I_ be the only one who _isn't_
> climbing on board the gravy train?  I mean seriously, why?  Just because
> I'm not an ``insider'' and an old established member of the club?
> _______________________________________________
> 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 woody at pch.net  Wed Oct  6 08:52:30 2010
From: woody at pch.net (Bill Woodcock)
Date: Wed, 6 Oct 2010 05:52:30 -0700
Subject: [arin-ppml] Policy Question(s)
In-Reply-To: <20101006124947.7cee700c@mail.novalibra.com>
References: <20101006124947.7cee700c@mail.novalibra.com>
Message-ID: <5942C566-F2A1-4CED-B779-0AD4E9F12D24@pch.net>


On Oct 6, 2010, at 5:49 AM, Tom Greenhaw wrote:
> Legitimate use of IPV4 space can be substantially lengthened by enforcement of the existing justification policies.

...for extremely small values of "substantially."

                                -Bill







From michael.dillon at bt.com  Wed Oct  6 08:59:39 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 6 Oct 2010 13:59:39 +0100
Subject: [arin-ppml] Policy Question(s)
In-Reply-To: <30271.1286361973@tristatelogic.com>
References: <alpine.BSF.2.00.1010060153520.57601@atlas.ipinc.net>
	<30271.1286361973@tristatelogic.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423937811658@EMV01-UKBR.domain1.systemhost.net>

> Am I the only one who sees a potential problem with this?

Yes.

The rest of us sign NDAs, and ask others to sign NDAs, as a normal
part of business life.

> >You really cannot fully understand all ARIN policy unless you
> understand that
> >ARIN policy consists both of the written policy - and the
> interpretation of
> >that written policy.

I you are doing business with ARIN, you don't need to understand policy
and its interpretation because you can just ask ARIN staff. I have done
so myself on several occasions for current and former employers.

If you are not doing business with ARIN, then your ability to understand
ARIN is your problem. There is no shortage of people out there who
have had dealings with ARIN, who you can talk to. Come to an ARIN meeting
and hang out in the corridors, for instance. It is your responsibility
to educate yourself.

By the way, ARIN is in no way, like the U.S. judiciary, or the 
Supreme Court of the Russian Federation or the Court of Appeal
of the British Antarctic Territory. 

> because I have first-hand knowledge that there is, on the one
> hand,
> the law, as written, and then there is, on the other hand, the
> interpretation
> of the law, with respect to various sets of facts, and the two are
> different
> and separate.

ARIN policy is not the law.


> But seriously folks, was I asleep?  Did I fail to get the memo?  Is
> ARIN
> actually not charging for IP space anymore? 

ARIN has never charged a fee for IP address allocations.

> Funny, I could have sworn
> I saw a fee chart on their web site just the other day. 

You seem to have missed the part where it says that the fee is a 
flat rate annual subscription fee for ARIN services that members
must pay to maintain their membership in good standing. And that
the fees, unlike ARIN policies, are set by the members themselves.

You spend too much time writing flights of fancy and too little time
reading and studying that which you appear to want to understand.

ARIN may be an unusual non-profit organization, but it is not that
unusual. It functions much like any corporate entity according to
its charter, its bylaws and its policies. The most unusual thing
about ARIN is that it allows the general public to participate in
setting those policies. Other than that, it is a pretty ordinary
non-profit corporate entity.

--Michael Dillon




From jcurran at arin.net  Wed Oct  6 09:00:15 2010
From: jcurran at arin.net (John Curran)
Date: Wed, 6 Oct 2010 09:00:15 -0400
Subject: [arin-ppml] Policy Question(s)
In-Reply-To: <30271.1286361973@tristatelogic.com>
References: <30271.1286361973@tristatelogic.com>
Message-ID: <ADD5B70F-8EC8-42AA-BD30-F9A3DEBD05E4@arin.net>

On Oct 6, 2010, at 6:46 AM, Ronald F. Guilmette wrote:
> 
> I guess you mean of NRPM section 8, but I don't think I saw anything really
> concrete in there that was an actual prohibition.  (Can you quote me the
> actual prohibition language out of the NRPM?)

Ron - Regarding violations in transfer of address space, if indeed you are
suggesting transfers independent of merger/acquisition (section 8.2) and 
independent of documented need (section 8.3) then that would be a violation
of number resource policy.  These are the only two transfer policies that 
have been adopted at this time.

>> IMHO you would be a fool to attempt to invest or setup an "IP investment
>> bank"
> 
> Well, that's what seemed to me might be a profitable thing to do, and I
> am not at all persuaded that ARIN could really stop me (or anyone) if
> somebody did that, and if they were dealing only in legacy blocks.

ARIN will maintain the Whois database according to the policies adopted by 
the community.  I'd suggest considering that when planning any endeavor,
and working with community using the policy development process to change 
the existing policy if it does not meet your needs today.  You are the
best judge of whether today's policies are suitable to your specific 
proposed business model.

> So much for ``open'' Internet governance.

The database entries are publicly visible, but the supporting material
for individual changes is not (as it often contains business sensitive
material.)  This too may be changed, as simpler policies don't require 
such material and/or it is quite possible for the community to decide 
that the requests and supporting documentation be public.  That's not
the current situation, and you'd need to work with others and make use
of the policy development process if you wish to make it so.

> I'm wondering if it occured to anybody, during the making of that decision,
> that what such a decision inevitably yields is an impenetrable Star Chamber,
> making un-reviewable decisions, in secret, that nobody ever even finds out
> about, let alone being able to question or understand.

To the contrary, all of the results are publicly visible, and we will review
any of resource action if someone believes that it is incorrect.

> Well, that's your view, based on what you know... But how do you know?
> I mean how does anybody know?  As you've noted, all these decisions
> about what may or may not get transfered, and to whom, are being made at
> this point, and have been made, since ARIN took over, with the same level
> of secrecy as the election of the next pope, i.e. total.  Right?  

Incorrect - all resources are publicly shown.  There's even an RSS feed 
of all the blocks issued or returned to ARIN daily if you want to watch 
transactions at that level of detail.

> Because
> everybody (or at any rate, a majority) wanted it that way.  OK fine. I
> get that part.  But now, here we are, and you actually can't tell me
> for certain, one way or the other, whether or not there's some Internet
> version of Gordon Gecko out there already, buying up IP real estate,
> quietly and secretly, and getting all those blocks quietly transfered
> to himself... or rather to his various paper subsidiaries... , again,
> very quietly.

If that's occurring, then hypothetical Mr. Gecko and his paper 
subsidiaries are supplying a significant amount of self-consistent 
information to qualify for address space per community policy.
Hopefully, they'd eventually stumble in their application process
or would raise suspicion in the community due to the publicly 
visible results and would be reported as an potential case of
fraudulent number resource assignments.  

> What I _can_ tell you is that I've made a special study of so-called
> snowshoe spammers.  These people consume (and lay waste to) IP space
> just like the proverbial stuff-through-a-goose.  And when I find...
> within the IPv4 space... another one of these operations... of which
> there are hundreds, as we speak, sometimes it is obvious where they
> are getting their IP space, i.e. from crooked ISPs that are lying to
> ARIN about their sub-allocations and their effective utilization rates.

> But at other times, it is not at all obvious how one of these criminals
> managed to glom onto a big fat hunk of IP space in a time of alleged shortage.

As reported earlier, we *do* take active measures to verify company
names, incorporation details, customers; but it is not always going
to be sufficient.  If you'd like to propose a different process for 
how we vet these applications based on your wisdom in this space,
feel free to do so.  If it has the support of the community, I will
make it happen at ARIN in record time.

> Such cases perplex me.  And I would argue that secrecy in these cases
> not only doesn't provide an answer to me personally, more importantly,
> in my opinion, it is counter to the best interests of the community.
> It's like saying that child molesters have a right-of-privacy, and so
> we ain't gonna tell you when one moves in two doors down from you.
> That used to be acceptable, but in a lot of places, it isn't anymore.

Ron - Propose a policy change to address this as you feel most appropriate.

Thanks!
/John

John Curran
President and CEO
ARIN

From info at arin.net  Wed Oct  6 09:17:10 2010
From: info at arin.net (ARIN)
Date: Wed, 06 Oct 2010 09:17:10 -0400
Subject: [arin-ppml] Draft Policy 2010-11: Required Resource Reviews
Message-ID: <4CAC76D6.3030807@arin.net>

We have an update for the following:
> B. ARIN General Counsel
>
> Pending

Counsel found no significant legal issues with this draft policy.

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)



> -----Original Message-----

> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On

> Behalf Of Member Services

> Sent: Tuesday, July 20, 2010 2:12 PM

> To: arin-ppml at arin.net

> Subject: [arin-ppml] Draft Policy 2010-11: Required Resource Reviews

>

> Draft Policy 2010-11

> Required Resource Reviews

>

> On 15 July 2010 the ARIN Advisory Council (AC) selected "Required

> Resource Reviews" as a draft policy for adoption discussion on the PPML

> and at the Public Policy Meeting in Atlanta in October.

>

> The draft was developed by the AC from policy proposal "117. Required

> Resource Reviews". Per the Policy Development Process the AC submitted

> text to ARIN for a staff and legal assessment prior to its selection as

> a draft policy. Below the draft policy is the ARIN staff and legal

> assessment, followed by the text that was submitted by the AC.

>

> Draft Policy 2010-11 is below and can be found at:

> https://www.arin.net/policy/proposals/2010_11.html

>

> You are encouraged to discuss Draft Policy 2010-11 on the PPML prior to

> the October Public Policy Meeting. Both the discussion on the list and

> at the meeting will be used by the ARIN Advisory Council to determine

> the community consensus for adopting this as policy.

>

> The ARIN Policy Development Process can be found at:

> https://www.arin.net/policy/pdp.html

>

> Draft Policies and Proposals under discussion can be found at:

> https://www.arin.net/policy/proposals/index.html

>

> Regards,

>

> Member Services

> American Registry for Internet Numbers (ARIN)

>

>

> ## * ##

>

>

> Draft Policy 2010-11

> Required Resource Reviews

>

> Version/Date: 20 July 2010

>

> Policy statement:

>

> Replace the text "under sections 4-6" in section 12, paragraph 7 with

> "under paragraphs 12.4 through 12.6"

>

> Add to section 12 the following text:

>

> 10. Except as provided below, resource reviews are conducted at the

> discretion of the ARIN staff. In any of the circumstances mentioned

> below, a resource review must be initiated by ARIN staff:

>

> a. Report or discovery of an acquisition, merger, transfer, trade or

> sale in which the infrastructure and customer base of a network move

> from one organization to another organization, but, the applicable IP

> resources are not transferred. In this case, the organization retaining

> the IP resources must be reviewed. The organization receiving the

> customers may also be reviewed at the discretion of the ARIN staff.

>

> b. Upon receipt by ARIN of one or more credible reports of fraud or

> abuse of an IP address block. Abuse shall be defined as use of the

> block

> in violation of the RSA or other ARIN policies and shall not extend to

> include general reports of host conduct which are not within ARIN's

> scope.

>

> c. In the case where an organization wishes to act as recipient of

> resources pursuant to a transfer under section 8.3, unless otherwise

> prohibited by paragraph 12.2(c).

>

> d. An organization which submits a request for additional resources

> when

> more than 25% of their existing resources are obscured in SWIP or

> RWHOIS

> pursuant to section 4.2.3.7.6 (residential customer privacy).

>

> e. Other than as specified in 12.10(c), paragraph 12.2(c) does not

> exempt organizations from the reviews required under section 12.10.

>

> Rationale:

>

> The first change is a minor correction which improves clarity and

> consistency of the original policy without changing the meaning.

>

> The addition of 12.10 (a) through (e) serves to create a set of

> circumstances under which a resource review is required, rather than

> optional and entirely at ARIN staff discretion.

>

> The majority of early comments on this proposal focused on 12.10 (e).

> Mostly it was confusion about the exact ramifications. This section

> will

> cause ARIN to maintain greater scrutiny only in cases where a given ISP

> issues more than 25% of their total space to residential customers who

> wish to remain anonymous and receive network blocks of /29 or larger.

> To

> the best of my knowledge, there are not currently any ISPs which meet

> this criteria. Additionally, it would only apply that scrutiny to IPv4,

> and will not carry forward into IPv6 residential assignments.

>

> This policy should improve the compliance verification of ARIN policies

> and may result in the improved reclamation of under-utilized IP address

> space. It should also serve as a deterrent to certain address hoarding

> tactics which have come to light in recent history.

>

> Timetable for implementation: Immediately upon ratification by the

> Board

>

>

> #####

>

>

> STAFF ASSESSMENT

>

> Proposal: (117) Required Resource Reviews

> Proposal Version (Date): 07 July 2010

> Date of Assessment: 14 July 2010

>

> 1. Proposal Summary (Staff Understanding)

>

> This draft policy establishes new criteria to enact NRPM 12 resource

> reviews. It requires ARIN staff to initiate resource reviews when M&A

> activity occurs but IP addresses are not transferred to the acquirer;

> when fraud or abuse is reported to ARIN, either about a specific IP

> address range or about an OrgID; when any NRPM 8.3 transfer occurs; or

> when staff are reviewing an additional IP address request and find that

> more than a quarter of an OrgID's downstream SWIPs are covered under

> the

> Residential Customer Privacy policy.

>

> 2. Comments

>

> A. ARIN Staff Comments

>

> ? This proposal could cause ARIN staff to conduct resource reviews on

> a

> more frequent basis. Any prescription for prioritizing such reviews

> could delay other important registration activities from being

> processed

> in a timely manner.

>

> B. ARIN General Counsel

>

> Pending

>

>

> 3. Resource Impact

>

> This policy would have moderate resource impact. It is estimated that

> implementation would occur within 6 months after ratification by the

> ARIN Board of Trustees. The following would be needed in order to

> implement:

>

> ? Resource reviews, audits, and fraud research require many man-hours.

> These new requirements to conduct audits on a much more regular basis

> could necessitate hiring and training additional registration staff.

> ? Changes to current business practices

> ? Staff training

> ? Updated guidelines

>

>

> 4. Proposal Text

>

> Policy statement:

>

> Replace the text "under sections 4-6" in section 12, paragraph 7 with

> "under paragraphs 12.4 through 12.6"

> Add to section 12 the following text:

>

> 10. Except as provided below, resource reviews are conducted at the

> discretion of the ARIN staff. In any of the circumstances mentioned

> below, a resource review must be initiated by ARIN staff:

> a. Report or discovery of an acquisition, merger, transfer, trade or

> sale in which the infrastructure and customer base of a network move

> from one organization to another organization, but, the applicable IP

> resources are not transferred. In this case, the organization retaining

> the IP resources must be reviewed. The organization receiving the

> customers may also be reviewed at the discretion of the ARIN staff.

> b. Upon receipt by ARIN of one or more credible reports of fraud or

> abuse of an IP address block. Abuse shall be defined as use of the

> block

> in violation of the RSA or other ARIN policies and shall not extend to

> include general reports of host conduct which are not within ARIN's

> scope.

> c. In the case where an organization wishes to act as recipient of

> resources pursuant to a transfer under section 8.3, unless otherwise

> prohibited by paragraph 12.2(c).

> d. An organization which submits a request for additional resources

> when more than 25% of their existing resources are obscured in SWIP or

> RWHOIS pursuant to section 4.2.3.7.6 (residential customer privacy).

> e. Other than as specified in 12.10(c), paragraph 12.2(c) does not

> exempt organizations from the reviews required under section 12.10.

>

> Rationale:

>

> The first change is a minor correction which improves clarity and

> consistency of the original policy without changing the meaning.

> The addition of 12.10 (a) through (e) serves to create a set of

> circumstances under which a resource review is required, rather than

> optional and entirely at ARIN staff discretion.

>

> The majority of early comments on this proposal focused on 12.10 (e).

> Mostly it was confusion about the exact ramifications. This section

> will

> cause ARIN to maintain greater scrutiny only in cases where a given ISP

> issues more than 25% of their total space to residential customers who

> wish to remain anonymous and receive network blocks of /29 or larger.

> To

> the best of my knowledge, there are not currently any ISPs which meet

> this criteria. Additionally, it would only apply that scrutiny to IPv4,

> and will not carry forward into IPv6 residential assignments.

>

> This policy should improve the compliance verification of ARIN policies

> and may result in the improved reclamation of under-utilized IP address

> space. It should also serve as a deterrent to certain address hoarding

> tactics which have come to light in recent history.

>

>

>

>

>

>

> _______________________________________________

> 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 Oct  6 10:13:42 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 6 Oct 2010 07:13:42 -0700
Subject: [arin-ppml] Policy Question(s)
In-Reply-To: <24732.1286320482@tristatelogic.com>
References: <24732.1286320482@tristatelogic.com>
Message-ID: <C27B0C1F-815B-49F2-8672-D11C430A690C@delong.com>


On Oct 5, 2010, at 4:14 PM, Ronald F. Guilmette wrote:

> 
> In message <6E785560-2860-4180-8192-4B95B7308314 at arin.net>, 
> John Curran <jcurran at arin.net> wrote:
> 
>> On Oct 5, 2010, at 5:22 AM, "Ronald F. Guilmette" <rfg at tristatelogic.com> w=
>> rote:
>> 
>>> So my question remains... if _someone_ creates a brand new, fresh, newly
>>> manufactured LLC, can some other company that happens to have an unused
>>> /18 lying around just ``gift'' that /18 to this new legal entity the
>>> very next day?
>> 
>> Ron -
>> 
>>   If you believe that resources were transferred contrary to the policies=
>> as shown in the Network Resource Policy Manual, section 8 (Transfers), the=
>> n report it on the already noted ARIN Fraud reporting link and we'll invest=
>> igate and correct the Whois entries if changed contrary to community policy=
> 
> 
> Thank you John.  Believe me, despite my reservations about what you
> folks may or may not consider to be the specific types of fraud that
> you feel are within your portfolio to look into, I most certainly
> would (and will) accept your invitation, and report to you, via the form,
> anything that, as you say, looks to me to have been contrary to the policy
> as laid out in Section 8 of the NRPM.
> 
> But see, here's the problem... In this case in particular... and also
> in at least one other I'm aware of... I honestly am having trouble
> interpreting what the words... specifically in Section 8.3... actually
> mean.  Can you please give me just a tiny bit of help with that?
> 
>    8.3. Transfers to Specified Recipients
> 
>    In addition to transfers under section 8.2, IPv4 number resources within
>    the ARIN region may be released to ARIN by the authorized resource holder,
>    in whole or in part, for transfer to another specified organizational
>    recipient. 
> 
Try actually including the full passage...

8.3. Transfers to Specified Recipients

In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies.


> This passage appears on the face of it to give you (ARIN) pretty much
> carte blanche to approve inter-company transfers as you think best,
> or not, as you think best.  (Note the use of the word "may".)  The above
> would appear to make ARIN judge, jury, and executioner for all inter-company
> and/or inter-organization transfer requests.  (Does that sound about right?
> Or am I misreading it?)
> 
That's because you left off fully half of the policy.

Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies.
The requirement for RSA and demonstrated need basically refers
back to NRPM section 4 (even though it does not spell that out).
The only mechanisms ARIN has for determining "demonstrated
need" is specified in NRPM 4 (IPv4) and NPRM 6 (IPv6).
> 
> 
> So again, this is a policy question:  May a company which is still very
> much alive and kicking request that ARIN transfer some block it owns
> to some brand new, newly manufactured company with no history whatsoever?
> Is that permissible under ARIN's discretion granted in 8.3. as set forth
> above?  And even if it is permissible for some company to _request_ such
> a transfer, is it permissible, under the policy, for ARIN to _grant_ such
> a request?   And if it is actually permissible under 8.3. to do that exact
> thing, then may *I* go forth now and start buying up blocks of ARIN region
> IP space, you know, as an investment, with equal confidence that you will
> willingly transfer any blocks that I might buy to _my_ new company, just
> as, it would appear, ARIN did in the case of 216.59.128.0/18 ?
> 
If that newly manufactured company can show demonstrated need
under NRPM 4, then, yes. If that company cannot, then, no.

Again, read ALL of 8.3 instead of just the first half and it helps a lot.
The answer to your second question is no.

Since the first and second questions are "no", then third question is
also, by extension no. Policy prohibits it unless you fit the criteria
expressed above. This has been said multiple times.

> And if the answers to all of the above questions are "no", then really,
> I would very much like to know how an 11 year old block that belonged
> to a company that is very much still alive (http://globalitcom.com/)
> ended up registered to a shadowy mystery company that has no web site
> and that, according to California Secretary of State online records,
> was only formed just late last year (i.e. orangeisp.com[1]).
> 
In separate off list email I have sent you no less than 4 possible ways
this could have occurred.

> This is only marginally a question about what policies did or did not
> allow _these companies_ to effect or to request this transfer.  It is
> really more a question about what policy or policies _ARIN_ was being
> guided by when it approved and allowed this transfer.
> 
This isn't necessarily a matter of public record, so, I don't know whether
ARIN is able to directly answer that specific question or not.

> (Note: I rather doubt that Orange County Networks, LLC sent you ARIN folks
> any fradulent documents claiming to be an 11 year old company, and even
> if they had done so, it would have been easy enough for you folks to check
> and disprove that online, in just a few seconds.  So it would appear that
> ARIN knowingly approved the transfer of an 11-year-old /18 block to what it
> knew, or could easily have known, was a brand new... albeit somewhat dubious...
> company.)
> 
Claiming to be 11 years old, probably not. Claiming to be the new successor
organization to an 11 year old company, however, is  a different matter.

Owen

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

From alex.ryu at kdlinc.com  Wed Oct  6 14:57:20 2010
From: alex.ryu at kdlinc.com (Alex Ryu)
Date: Wed, 6 Oct 2010 13:57:20 -0500
Subject: [arin-ppml] Draft Policy 2010-11: Required Resource Reviews
In-Reply-To: <4CAC76D6.3030807@arin.net>
References: <4CAC76D6.3030807@arin.net>
Message-ID: <278B5E4BCD5E654385A9F83C7CA6D517F17B707377@MAILBOX-01.qcommcorp.ad>

I oppose this based on following thought.

1) how can we differentiate /32 assignment for residential customers or /29 or large assignment? 
A lot of cable modem or triple play ISP (start-up?) use /24 using Residential Privacy method per market. 
/32 assignment is not obligated to report through SWIP or RWHOIS. 
So the judgement for 25% is pretty much vague. 
And mostly triple-play ISP or cable modem provider may be affected by this 25% triggers in most case.
So it may be target for specific industry if this is mandated trigger. 
A lot of triple-play markets under RUS funding may be most of their customers are residential, and no business customers at all given that their market will be tier-3/4 rural area. 


2) I don't see the any exception for repeated audit triggered by this policy if any ISP's business model is really residential ISP...
If this policy is mandating the audit for triggered conditions without exceptions, they may be penalted unfairly under this policy. 

Alex


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
Sent: Wednesday, October 06, 2010 9:17 AM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy 2010-11: Required Resource Reviews

We have an update for the following:
> B. ARIN General Counsel
>
> Pending

Counsel found no significant legal issues with this draft policy.

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)



> -----Original Message-----

> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On

> Behalf Of Member Services

> Sent: Tuesday, July 20, 2010 2:12 PM

> To: arin-ppml at arin.net

> Subject: [arin-ppml] Draft Policy 2010-11: Required Resource Reviews

>

> Draft Policy 2010-11

> Required Resource Reviews

>

> On 15 July 2010 the ARIN Advisory Council (AC) selected "Required

> Resource Reviews" as a draft policy for adoption discussion on the PPML

> and at the Public Policy Meeting in Atlanta in October.

>

> The draft was developed by the AC from policy proposal "117. Required

> Resource Reviews". Per the Policy Development Process the AC submitted

> text to ARIN for a staff and legal assessment prior to its selection as

> a draft policy. Below the draft policy is the ARIN staff and legal

> assessment, followed by the text that was submitted by the AC.

>

> Draft Policy 2010-11 is below and can be found at:

> https://www.arin.net/policy/proposals/2010_11.html

>

> You are encouraged to discuss Draft Policy 2010-11 on the PPML prior to

> the October Public Policy Meeting. Both the discussion on the list and

> at the meeting will be used by the ARIN Advisory Council to determine

> the community consensus for adopting this as policy.

>

> The ARIN Policy Development Process can be found at:

> https://www.arin.net/policy/pdp.html

>

> Draft Policies and Proposals under discussion can be found at:

> https://www.arin.net/policy/proposals/index.html

>

> Regards,

>

> Member Services

> American Registry for Internet Numbers (ARIN)

>

>

> ## * ##

>

>

> Draft Policy 2010-11

> Required Resource Reviews

>

> Version/Date: 20 July 2010

>

> Policy statement:

>

> Replace the text "under sections 4-6" in section 12, paragraph 7 with

> "under paragraphs 12.4 through 12.6"

>

> Add to section 12 the following text:

>

> 10. Except as provided below, resource reviews are conducted at the

> discretion of the ARIN staff. In any of the circumstances mentioned

> below, a resource review must be initiated by ARIN staff:

>

> a. Report or discovery of an acquisition, merger, transfer, trade or

> sale in which the infrastructure and customer base of a network move

> from one organization to another organization, but, the applicable IP

> resources are not transferred. In this case, the organization retaining

> the IP resources must be reviewed. The organization receiving the

> customers may also be reviewed at the discretion of the ARIN staff.

>

> b. Upon receipt by ARIN of one or more credible reports of fraud or

> abuse of an IP address block. Abuse shall be defined as use of the

> block

> in violation of the RSA or other ARIN policies and shall not extend to

> include general reports of host conduct which are not within ARIN's

> scope.

>

> c. In the case where an organization wishes to act as recipient of

> resources pursuant to a transfer under section 8.3, unless otherwise

> prohibited by paragraph 12.2(c).

>

> d. An organization which submits a request for additional resources

> when

> more than 25% of their existing resources are obscured in SWIP or

> RWHOIS

> pursuant to section 4.2.3.7.6 (residential customer privacy).

>

> e. Other than as specified in 12.10(c), paragraph 12.2(c) does not

> exempt organizations from the reviews required under section 12.10.

>

> Rationale:

>

> The first change is a minor correction which improves clarity and

> consistency of the original policy without changing the meaning.

>

> The addition of 12.10 (a) through (e) serves to create a set of

> circumstances under which a resource review is required, rather than

> optional and entirely at ARIN staff discretion.

>

> The majority of early comments on this proposal focused on 12.10 (e).

> Mostly it was confusion about the exact ramifications. This section

> will

> cause ARIN to maintain greater scrutiny only in cases where a given ISP

> issues more than 25% of their total space to residential customers who

> wish to remain anonymous and receive network blocks of /29 or larger.

> To

> the best of my knowledge, there are not currently any ISPs which meet

> this criteria. Additionally, it would only apply that scrutiny to IPv4,

> and will not carry forward into IPv6 residential assignments.

>

> This policy should improve the compliance verification of ARIN policies

> and may result in the improved reclamation of under-utilized IP address

> space. It should also serve as a deterrent to certain address hoarding

> tactics which have come to light in recent history.

>

> Timetable for implementation: Immediately upon ratification by the

> Board

>

>

> #####

>

>

> STAFF ASSESSMENT

>

> Proposal: (117) Required Resource Reviews

> Proposal Version (Date): 07 July 2010

> Date of Assessment: 14 July 2010

>

> 1. Proposal Summary (Staff Understanding)

>

> This draft policy establishes new criteria to enact NRPM 12 resource

> reviews. It requires ARIN staff to initiate resource reviews when M&A

> activity occurs but IP addresses are not transferred to the acquirer;

> when fraud or abuse is reported to ARIN, either about a specific IP

> address range or about an OrgID; when any NRPM 8.3 transfer occurs; or

> when staff are reviewing an additional IP address request and find that

> more than a quarter of an OrgID's downstream SWIPs are covered under

> the

> Residential Customer Privacy policy.

>

> 2. Comments

>

> A. ARIN Staff Comments

>

> * This proposal could cause ARIN staff to conduct resource reviews on

> a

> more frequent basis. Any prescription for prioritizing such reviews

> could delay other important registration activities from being

> processed

> in a timely manner.

>

> B. ARIN General Counsel

>

> Pending

>

>

> 3. Resource Impact

>

> This policy would have moderate resource impact. It is estimated that

> implementation would occur within 6 months after ratification by the

> ARIN Board of Trustees. The following would be needed in order to

> implement:

>

> * Resource reviews, audits, and fraud research require many man-hours.

> These new requirements to conduct audits on a much more regular basis

> could necessitate hiring and training additional registration staff.

> * Changes to current business practices

> * Staff training

> * Updated guidelines

>

>

> 4. Proposal Text

>

> Policy statement:

>

> Replace the text "under sections 4-6" in section 12, paragraph 7 with

> "under paragraphs 12.4 through 12.6"

> Add to section 12 the following text:

>

> 10. Except as provided below, resource reviews are conducted at the

> discretion of the ARIN staff. In any of the circumstances mentioned

> below, a resource review must be initiated by ARIN staff:

> a. Report or discovery of an acquisition, merger, transfer, trade or

> sale in which the infrastructure and customer base of a network move

> from one organization to another organization, but, the applicable IP

> resources are not transferred. In this case, the organization retaining

> the IP resources must be reviewed. The organization receiving the

> customers may also be reviewed at the discretion of the ARIN staff.

> b. Upon receipt by ARIN of one or more credible reports of fraud or

> abuse of an IP address block. Abuse shall be defined as use of the

> block

> in violation of the RSA or other ARIN policies and shall not extend to

> include general reports of host conduct which are not within ARIN's

> scope.

> c. In the case where an organization wishes to act as recipient of

> resources pursuant to a transfer under section 8.3, unless otherwise

> prohibited by paragraph 12.2(c).

> d. An organization which submits a request for additional resources

> when more than 25% of their existing resources are obscured in SWIP or

> RWHOIS pursuant to section 4.2.3.7.6 (residential customer privacy).

> e. Other than as specified in 12.10(c), paragraph 12.2(c) does not

> exempt organizations from the reviews required under section 12.10.

>

> Rationale:

>

> The first change is a minor correction which improves clarity and

> consistency of the original policy without changing the meaning.

> The addition of 12.10 (a) through (e) serves to create a set of

> circumstances under which a resource review is required, rather than

> optional and entirely at ARIN staff discretion.

>

> The majority of early comments on this proposal focused on 12.10 (e).

> Mostly it was confusion about the exact ramifications. This section

> will

> cause ARIN to maintain greater scrutiny only in cases where a given ISP

> issues more than 25% of their total space to residential customers who

> wish to remain anonymous and receive network blocks of /29 or larger.

> To

> the best of my knowledge, there are not currently any ISPs which meet

> this criteria. Additionally, it would only apply that scrutiny to IPv4,

> and will not carry forward into IPv6 residential assignments.

>

> This policy should improve the compliance verification of ARIN policies

> and may result in the improved reclamation of under-utilized IP address

> space. It should also serve as a deterrent to certain address hoarding

> tactics which have come to light in recent history.

>

>

>

>

>

>

> _______________________________________________

> 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  Wed Oct  6 15:51:18 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 6 Oct 2010 12:51:18 -0700
Subject: [arin-ppml] Draft Policy 2010-11: Required Resource Reviews
In-Reply-To: <278B5E4BCD5E654385A9F83C7CA6D517F17B707377@MAILBOX-01.qcommcorp.ad>
References: <4CAC76D6.3030807@arin.net>
	<278B5E4BCD5E654385A9F83C7CA6D517F17B707377@MAILBOX-01.qcommcorp.ad>
Message-ID: <1F143BED-4354-4B27-8805-FA46C498E63B@delong.com>


On Oct 6, 2010, at 11:57 AM, Alex Ryu wrote:

> I oppose this based on following thought.
> 
> 1) how can we differentiate /32 assignment for residential customers or /29 or large assignment? 
> A lot of cable modem or triple play ISP (start-up?) use /24 using Residential Privacy method per market. 
> /32 assignment is not obligated to report through SWIP or RWHOIS. 
> So the judgement for 25% is pretty much vague. 

Not at all... Since they wouldn't SWIP the space for the /32, /31, or /30 assignments, there's
no obfuscation of that space under residential customer privacy.

If 75% of their space is in residential /32s, infrastructure, etc. they still don't trigger.

A /24 for a market should _NOT_ be SWIP'd as residential privacy. It should be counted as
a market-serving DHCP range registered to the provider. So, if they're doing incorrect SWIPs
a resource review is legitimate.

> And mostly triple-play ISP or cable modem provider may be affected by this 25% triggers in most case.
> So it may be target for specific industry if this is mandated trigger. 

No, the trigger does not target them if they keep their records correctly.

> A lot of triple-play markets under RUS funding may be most of their customers are residential, and no business customers at all given that their market will be tier-3/4 rural area. 
> 
That still doesn't result in the trigger. Again, they shouldn't be SWIPing the space they use in the
manner you describe, so, it wouldn't affect the trigger.

> 
> 2) I don't see the any exception for repeated audit triggered by this policy if any ISP's business model is really residential ISP...
> If this policy is mandating the audit for triggered conditions without exceptions, they may be penalted unfairly under this policy. 

No. See me at the break and I will explain this to you in detail. It really does not afflict them in the
manner you are describing if they are keeping their records correctly.

Owen

> 
> Alex
> 
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
> Sent: Wednesday, October 06, 2010 9:17 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy 2010-11: Required Resource Reviews
> 
> We have an update for the following:
>> B. ARIN General Counsel
>> 
>> Pending
> 
> Counsel found no significant legal issues with this draft policy.
> 
> Regards,
> 
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> 
>> -----Original Message-----
> 
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> 
>> Behalf Of Member Services
> 
>> Sent: Tuesday, July 20, 2010 2:12 PM
> 
>> To: arin-ppml at arin.net
> 
>> Subject: [arin-ppml] Draft Policy 2010-11: Required Resource Reviews
> 
>> 
> 
>> Draft Policy 2010-11
> 
>> Required Resource Reviews
> 
>> 
> 
>> On 15 July 2010 the ARIN Advisory Council (AC) selected "Required
> 
>> Resource Reviews" as a draft policy for adoption discussion on the PPML
> 
>> and at the Public Policy Meeting in Atlanta in October.
> 
>> 
> 
>> The draft was developed by the AC from policy proposal "117. Required
> 
>> Resource Reviews". Per the Policy Development Process the AC submitted
> 
>> text to ARIN for a staff and legal assessment prior to its selection as
> 
>> a draft policy. Below the draft policy is the ARIN staff and legal
> 
>> assessment, followed by the text that was submitted by the AC.
> 
>> 
> 
>> Draft Policy 2010-11 is below and can be found at:
> 
>> https://www.arin.net/policy/proposals/2010_11.html
> 
>> 
> 
>> You are encouraged to discuss Draft Policy 2010-11 on the PPML prior to
> 
>> the October Public Policy Meeting. Both the discussion on the list and
> 
>> at the meeting will be used by the ARIN Advisory Council to determine
> 
>> the community consensus for adopting this as policy.
> 
>> 
> 
>> The ARIN Policy Development Process can be found at:
> 
>> https://www.arin.net/policy/pdp.html
> 
>> 
> 
>> Draft Policies and Proposals under discussion can be found at:
> 
>> https://www.arin.net/policy/proposals/index.html
> 
>> 
> 
>> Regards,
> 
>> 
> 
>> Member Services
> 
>> American Registry for Internet Numbers (ARIN)
> 
>> 
> 
>> 
> 
>> ## * ##
> 
>> 
> 
>> 
> 
>> Draft Policy 2010-11
> 
>> Required Resource Reviews
> 
>> 
> 
>> Version/Date: 20 July 2010
> 
>> 
> 
>> Policy statement:
> 
>> 
> 
>> Replace the text "under sections 4-6" in section 12, paragraph 7 with
> 
>> "under paragraphs 12.4 through 12.6"
> 
>> 
> 
>> Add to section 12 the following text:
> 
>> 
> 
>> 10. Except as provided below, resource reviews are conducted at the
> 
>> discretion of the ARIN staff. In any of the circumstances mentioned
> 
>> below, a resource review must be initiated by ARIN staff:
> 
>> 
> 
>> a. Report or discovery of an acquisition, merger, transfer, trade or
> 
>> sale in which the infrastructure and customer base of a network move
> 
>> from one organization to another organization, but, the applicable IP
> 
>> resources are not transferred. In this case, the organization retaining
> 
>> the IP resources must be reviewed. The organization receiving the
> 
>> customers may also be reviewed at the discretion of the ARIN staff.
> 
>> 
> 
>> b. Upon receipt by ARIN of one or more credible reports of fraud or
> 
>> abuse of an IP address block. Abuse shall be defined as use of the
> 
>> block
> 
>> in violation of the RSA or other ARIN policies and shall not extend to
> 
>> include general reports of host conduct which are not within ARIN's
> 
>> scope.
> 
>> 
> 
>> c. In the case where an organization wishes to act as recipient of
> 
>> resources pursuant to a transfer under section 8.3, unless otherwise
> 
>> prohibited by paragraph 12.2(c).
> 
>> 
> 
>> d. An organization which submits a request for additional resources
> 
>> when
> 
>> more than 25% of their existing resources are obscured in SWIP or
> 
>> RWHOIS
> 
>> pursuant to section 4.2.3.7.6 (residential customer privacy).
> 
>> 
> 
>> e. Other than as specified in 12.10(c), paragraph 12.2(c) does not
> 
>> exempt organizations from the reviews required under section 12.10.
> 
>> 
> 
>> Rationale:
> 
>> 
> 
>> The first change is a minor correction which improves clarity and
> 
>> consistency of the original policy without changing the meaning.
> 
>> 
> 
>> The addition of 12.10 (a) through (e) serves to create a set of
> 
>> circumstances under which a resource review is required, rather than
> 
>> optional and entirely at ARIN staff discretion.
> 
>> 
> 
>> The majority of early comments on this proposal focused on 12.10 (e).
> 
>> Mostly it was confusion about the exact ramifications. This section
> 
>> will
> 
>> cause ARIN to maintain greater scrutiny only in cases where a given ISP
> 
>> issues more than 25% of their total space to residential customers who
> 
>> wish to remain anonymous and receive network blocks of /29 or larger.
> 
>> To
> 
>> the best of my knowledge, there are not currently any ISPs which meet
> 
>> this criteria. Additionally, it would only apply that scrutiny to IPv4,
> 
>> and will not carry forward into IPv6 residential assignments.
> 
>> 
> 
>> This policy should improve the compliance verification of ARIN policies
> 
>> and may result in the improved reclamation of under-utilized IP address
> 
>> space. It should also serve as a deterrent to certain address hoarding
> 
>> tactics which have come to light in recent history.
> 
>> 
> 
>> Timetable for implementation: Immediately upon ratification by the
> 
>> Board
> 
>> 
> 
>> 
> 
>> #####
> 
>> 
> 
>> 
> 
>> STAFF ASSESSMENT
> 
>> 
> 
>> Proposal: (117) Required Resource Reviews
> 
>> Proposal Version (Date): 07 July 2010
> 
>> Date of Assessment: 14 July 2010
> 
>> 
> 
>> 1. Proposal Summary (Staff Understanding)
> 
>> 
> 
>> This draft policy establishes new criteria to enact NRPM 12 resource
> 
>> reviews. It requires ARIN staff to initiate resource reviews when M&A
> 
>> activity occurs but IP addresses are not transferred to the acquirer;
> 
>> when fraud or abuse is reported to ARIN, either about a specific IP
> 
>> address range or about an OrgID; when any NRPM 8.3 transfer occurs; or
> 
>> when staff are reviewing an additional IP address request and find that
> 
>> more than a quarter of an OrgID's downstream SWIPs are covered under
> 
>> the
> 
>> Residential Customer Privacy policy.
> 
>> 
> 
>> 2. Comments
> 
>> 
> 
>> A. ARIN Staff Comments
> 
>> 
> 
>> * This proposal could cause ARIN staff to conduct resource reviews on
> 
>> a
> 
>> more frequent basis. Any prescription for prioritizing such reviews
> 
>> could delay other important registration activities from being
> 
>> processed
> 
>> in a timely manner.
> 
>> 
> 
>> B. ARIN General Counsel
> 
>> 
> 
>> Pending
> 
>> 
> 
>> 
> 
>> 3. Resource Impact
> 
>> 
> 
>> This policy would have moderate resource impact. It is estimated that
> 
>> implementation would occur within 6 months after ratification by the
> 
>> ARIN Board of Trustees. The following would be needed in order to
> 
>> implement:
> 
>> 
> 
>> * Resource reviews, audits, and fraud research require many man-hours.
> 
>> These new requirements to conduct audits on a much more regular basis
> 
>> could necessitate hiring and training additional registration staff.
> 
>> * Changes to current business practices
> 
>> * Staff training
> 
>> * Updated guidelines
> 
>> 
> 
>> 
> 
>> 4. Proposal Text
> 
>> 
> 
>> Policy statement:
> 
>> 
> 
>> Replace the text "under sections 4-6" in section 12, paragraph 7 with
> 
>> "under paragraphs 12.4 through 12.6"
> 
>> Add to section 12 the following text:
> 
>> 
> 
>> 10. Except as provided below, resource reviews are conducted at the
> 
>> discretion of the ARIN staff. In any of the circumstances mentioned
> 
>> below, a resource review must be initiated by ARIN staff:
> 
>> a. Report or discovery of an acquisition, merger, transfer, trade or
> 
>> sale in which the infrastructure and customer base of a network move
> 
>> from one organization to another organization, but, the applicable IP
> 
>> resources are not transferred. In this case, the organization retaining
> 
>> the IP resources must be reviewed. The organization receiving the
> 
>> customers may also be reviewed at the discretion of the ARIN staff.
> 
>> b. Upon receipt by ARIN of one or more credible reports of fraud or
> 
>> abuse of an IP address block. Abuse shall be defined as use of the
> 
>> block
> 
>> in violation of the RSA or other ARIN policies and shall not extend to
> 
>> include general reports of host conduct which are not within ARIN's
> 
>> scope.
> 
>> c. In the case where an organization wishes to act as recipient of
> 
>> resources pursuant to a transfer under section 8.3, unless otherwise
> 
>> prohibited by paragraph 12.2(c).
> 
>> d. An organization which submits a request for additional resources
> 
>> when more than 25% of their existing resources are obscured in SWIP or
> 
>> RWHOIS pursuant to section 4.2.3.7.6 (residential customer privacy).
> 
>> e. Other than as specified in 12.10(c), paragraph 12.2(c) does not
> 
>> exempt organizations from the reviews required under section 12.10.
> 
>> 
> 
>> Rationale:
> 
>> 
> 
>> The first change is a minor correction which improves clarity and
> 
>> consistency of the original policy without changing the meaning.
> 
>> The addition of 12.10 (a) through (e) serves to create a set of
> 
>> circumstances under which a resource review is required, rather than
> 
>> optional and entirely at ARIN staff discretion.
> 
>> 
> 
>> The majority of early comments on this proposal focused on 12.10 (e).
> 
>> Mostly it was confusion about the exact ramifications. This section
> 
>> will
> 
>> cause ARIN to maintain greater scrutiny only in cases where a given ISP
> 
>> issues more than 25% of their total space to residential customers who
> 
>> wish to remain anonymous and receive network blocks of /29 or larger.
> 
>> To
> 
>> the best of my knowledge, there are not currently any ISPs which meet
> 
>> this criteria. Additionally, it would only apply that scrutiny to IPv4,
> 
>> and will not carry forward into IPv6 residential assignments.
> 
>> 
> 
>> This policy should improve the compliance verification of ARIN policies
> 
>> and may result in the improved reclamation of under-utilized IP address
> 
>> space. It should also serve as a deterrent to certain address hoarding
> 
>> tactics which have come to light in recent history.
> 
>> 
> 
>> 
> 
>> 
> 
>> 
> 
>> 
> 
>> 
> 
>> _______________________________________________
> 
>> 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 marty at akamai.com  Wed Oct  6 17:16:40 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Wed, 6 Oct 2010 17:16:40 -0400
Subject: [arin-ppml] Policy Question(s)
In-Reply-To: <20101006124947.7cee700c@mail.novalibra.com>
Message-ID: <C8D25F78.127CF%marty@akamai.com>




On 10/6/10 8:49 AM, "Tom Greenhaw" <tom.greenhaw at novalibra.com> wrote:

> Address space resellers and the original owners of that address space are in
> clear violation of their justification commitments to ARIN and the Internet
> community at large.
> 
> Legitimate use of IPV4 space can be substantially lengthened by enforcement of
> the existing justification policies.

Substantial has many meanings with respect to lengthening. We need as many
addresses as possible "IN" the system.


http://www.nanog.org/meetings/nanog50/presentations/Tuesday/NANOG50.Talk64.h
annigan-ltalk-50.pdf

http://www.nanog.org/meetings/nanog50/presentations/Tuesday/NANOG50.Talk64.h
annigan-ltalk-50.xls

Plug in your own numbers with respect to cost. That should demonstrate the
substantiality well enough.


Best,

-M<



From mpetach at netflight.com  Wed Oct  6 23:57:44 2010
From: mpetach at netflight.com (Matthew Petach)
Date: Wed, 6 Oct 2010 20:57:44 -0700
Subject: [arin-ppml] 2010.10.06 ARIN26 notes day 1
Message-ID: <AANLkTimpJS0kqFpmwh0oAZrJvdiWDiP0GGS17QskzvXy@mail.gmail.com>

As ARIN has formal transcripts made of the meetings,
I hadn't originally been thinking of making my notes
available, but I was asked by a few people at the
social tonight if I would, so I've put them up at
http://kestrel3.netflight.com/2010.10.06-ARIN26-afternoon-notes.txt
They're just my notes, and not a formal transcript
or anything, so please, just use them if you want
a quick cheat sheet for tomorrow, but do recognize
I was running on only 2 hours of sleep, so there's
bound to be large gaps where I nodded off for a bit.  ^_^;;

Matt


From mark at townsley.net  Thu Oct  7 07:21:03 2010
From: mark at townsley.net (Mark Townsley)
Date: Thu, 07 Oct 2010 07:21:03 -0400
Subject: [arin-ppml] I Oppose 2010-12: IPv6 Subsequent Allocation
In-Reply-To: <6352E671-A11E-446F-9088-CBA2BF5A1F5D@delong.com>
References: <AANLkTikP7DKr0kDUTwAv97awmnQTxY-bHqZHiwH8ONHN@mail.gmail.com>	<2E2FECEBAE57CC4BAACDE67638305F10488C4BA9CF@ROCH-EXCH1.corp.pvt>	<AANLkTik4opowWpe1sOwzfv5DmK=ogw+jbDKUyNBunHTz@mail.gmail.com>
	<6352E671-A11E-446F-9088-CBA2BF5A1F5D@delong.com>
Message-ID: <4CADAD1F.3010507@townsley.net>


I could live with these changes.

Shall I summarize them in a proposal for the meeting this afternoon?

- Mark

On 10/5/10 3:56 AM, Owen DeLong wrote:
> I would actually support these changes. I'd put the upper bound at /24 rather than /26, as I
> believe we should stop issuing things on non-nibble boundaries in general.
>
>
> Owen
>
> On Oct 4, 2010, at 4:35 PM, William Herrin wrote:
>
>> On Sun, Oct 3, 2010 at 10:48 AM, Azinger, Marla <Marla.Azinger at ftr.com> wrote:
>>> Bill or anyone else that sees this as a missing value-
>>> What text would you suggest to resolve what you see as a missing value?
>> Hi Marla,
>>
>> I need to think about it some more, but off the cuff I think I'd place
>> a few limits:
>>
>> 1. No organization can justify holding total IPv6 allocations that
>> exceed /26 under this policy.
>>
>> Rationale: If you think you need more than that, you haven't thought
>> it through well enough.
>>
>> 2. No organization can justify more than two disaggregate allocations
>> under this policy irrespective of individual or total size.
>>
>> Rationale: You get a couple tries but then you have to clear out and
>> return one of your earlier tries before you can make attempt number
>> three.
>>
>> 3. Unless organization is mapping more than, and I'm picking a number
>> out of my hat here, 5 disaggregate IPv4 allocations with the
>> transition mechanism the the largest additional allocation they can
>> justify is a /32.
>>
>> Rationale: you shouldn't be mapping the full 32 bits of the Ipv4
>> address into the upper 64 bits of address space unless you're juggling
>> so many different IPv4 allocations that it just isn't practical to do
>> it any other way... And transition mechanisms that need to consume
>> ARIN allocations but must map the full 32 bit address aren't credible.
>>
>>
>> Also I suggest ditching the 3-year resource review. We barely review
>> V4 resources as we approach a critical shortage. We're not seriously
>> going to review IPv6 allocations for a long, long time.
>>
>> 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
>> _______________________________________________
>> 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 scottleibrand at gmail.com  Thu Oct  7 09:34:03 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 7 Oct 2010 09:34:03 -0400
Subject: [arin-ppml] I Oppose 2010-12: IPv6 Subsequent Allocation
In-Reply-To: <4CADAD1F.3010507@townsley.net>
References: <AANLkTikP7DKr0kDUTwAv97awmnQTxY-bHqZHiwH8ONHN@mail.gmail.com>
	<2E2FECEBAE57CC4BAACDE67638305F10488C4BA9CF@ROCH-EXCH1.corp.pvt>
	<AANLkTik4opowWpe1sOwzfv5DmK=ogw+jbDKUyNBunHTz@mail.gmail.com>
	<6352E671-A11E-446F-9088-CBA2BF5A1F5D@delong.com>
	<4CADAD1F.3010507@townsley.net>
Message-ID: <54A499BD-BC4D-4668-82D4-C3DA94C04808@gmail.com>

I can't speak for Owen, Marla, or anyone else, but IMO it's always helpful to have actual text for any suggested changes. Keep in mind that the text of the draft policy is frozen through the end of this week's meeting. 

Scott

On Oct 7, 2010, at 7:21 AM, Mark Townsley <mark at townsley.net> wrote:

> 
> I could live with these changes.
> 
> Shall I summarize them in a proposal for the meeting this afternoon?
> 
> - Mark
> 
> On 10/5/10 3:56 AM, Owen DeLong wrote:
>> I would actually support these changes. I'd put the upper bound at /24 rather than /26, as I
>> believe we should stop issuing things on non-nibble boundaries in general.
>> 
>> 
>> Owen
>> 
>> On Oct 4, 2010, at 4:35 PM, William Herrin wrote:
>> 
>>> On Sun, Oct 3, 2010 at 10:48 AM, Azinger, Marla <Marla.Azinger at ftr.com> wrote:
>>>> Bill or anyone else that sees this as a missing value-
>>>> What text would you suggest to resolve what you see as a missing value?
>>> Hi Marla,
>>> 
>>> I need to think about it some more, but off the cuff I think I'd place
>>> a few limits:
>>> 
>>> 1. No organization can justify holding total IPv6 allocations that
>>> exceed /26 under this policy.
>>> 
>>> Rationale: If you think you need more than that, you haven't thought
>>> it through well enough.
>>> 
>>> 2. No organization can justify more than two disaggregate allocations
>>> under this policy irrespective of individual or total size.
>>> 
>>> Rationale: You get a couple tries but then you have to clear out and
>>> return one of your earlier tries before you can make attempt number
>>> three.
>>> 
>>> 3. Unless organization is mapping more than, and I'm picking a number
>>> out of my hat here, 5 disaggregate IPv4 allocations with the
>>> transition mechanism the the largest additional allocation they can
>>> justify is a /32.
>>> 
>>> Rationale: you shouldn't be mapping the full 32 bits of the Ipv4
>>> address into the upper 64 bits of address space unless you're juggling
>>> so many different IPv4 allocations that it just isn't practical to do
>>> it any other way... And transition mechanisms that need to consume
>>> ARIN allocations but must map the full 32 bit address aren't credible.
>>> 
>>> 
>>> Also I suggest ditching the 3-year resource review. We barely review
>>> V4 resources as we approach a critical shortage. We're not seriously
>>> going to review IPv6 allocations for a long, long time.
>>> 
>>> 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
>>> _______________________________________________
>>> 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 owen at delong.com  Thu Oct  7 09:45:19 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 7 Oct 2010 06:45:19 -0700
Subject: [arin-ppml] I Oppose 2010-12: IPv6 Subsequent Allocation
In-Reply-To: <54A499BD-BC4D-4668-82D4-C3DA94C04808@gmail.com>
References: <AANLkTikP7DKr0kDUTwAv97awmnQTxY-bHqZHiwH8ONHN@mail.gmail.com>
	<2E2FECEBAE57CC4BAACDE67638305F10488C4BA9CF@ROCH-EXCH1.corp.pvt>
	<AANLkTik4opowWpe1sOwzfv5DmK=ogw+jbDKUyNBunHTz@mail.gmail.com>
	<6352E671-A11E-446F-9088-CBA2BF5A1F5D@delong.com>
	<4CADAD1F.3010507@townsley.net>
	<54A499BD-BC4D-4668-82D4-C3DA94C04808@gmail.com>
Message-ID: <3C99B52B-9B81-4E19-BFEE-35D060379B04@delong.com>

Yes, but, amendments can be proposed at the microphone and the AC can consider
those amendments.

Having text of such an amendment on the list ahead of time is, indeed, useful.

Owen

On Oct 7, 2010, at 6:34 AM, Scott Leibrand wrote:

> I can't speak for Owen, Marla, or anyone else, but IMO it's always helpful to have actual text for any suggested changes. Keep in mind that the text of the draft policy is frozen through the end of this week's meeting. 
> 
> Scott
> 
> On Oct 7, 2010, at 7:21 AM, Mark Townsley <mark at townsley.net> wrote:
> 
>> 
>> I could live with these changes.
>> 
>> Shall I summarize them in a proposal for the meeting this afternoon?
>> 
>> - Mark
>> 
>> On 10/5/10 3:56 AM, Owen DeLong wrote:
>>> I would actually support these changes. I'd put the upper bound at /24 rather than /26, as I
>>> believe we should stop issuing things on non-nibble boundaries in general.
>>> 
>>> 
>>> Owen
>>> 
>>> On Oct 4, 2010, at 4:35 PM, William Herrin wrote:
>>> 
>>>> On Sun, Oct 3, 2010 at 10:48 AM, Azinger, Marla <Marla.Azinger at ftr.com> wrote:
>>>>> Bill or anyone else that sees this as a missing value-
>>>>> What text would you suggest to resolve what you see as a missing value?
>>>> Hi Marla,
>>>> 
>>>> I need to think about it some more, but off the cuff I think I'd place
>>>> a few limits:
>>>> 
>>>> 1. No organization can justify holding total IPv6 allocations that
>>>> exceed /26 under this policy.
>>>> 
>>>> Rationale: If you think you need more than that, you haven't thought
>>>> it through well enough.
>>>> 
>>>> 2. No organization can justify more than two disaggregate allocations
>>>> under this policy irrespective of individual or total size.
>>>> 
>>>> Rationale: You get a couple tries but then you have to clear out and
>>>> return one of your earlier tries before you can make attempt number
>>>> three.
>>>> 
>>>> 3. Unless organization is mapping more than, and I'm picking a number
>>>> out of my hat here, 5 disaggregate IPv4 allocations with the
>>>> transition mechanism the the largest additional allocation they can
>>>> justify is a /32.
>>>> 
>>>> Rationale: you shouldn't be mapping the full 32 bits of the Ipv4
>>>> address into the upper 64 bits of address space unless you're juggling
>>>> so many different IPv4 allocations that it just isn't practical to do
>>>> it any other way... And transition mechanisms that need to consume
>>>> ARIN allocations but must map the full 32 bit address aren't credible.
>>>> 
>>>> 
>>>> Also I suggest ditching the 3-year resource review. We barely review
>>>> V4 resources as we approach a critical shortage. We're not seriously
>>>> going to review IPv6 allocations for a long, long time.
>>>> 
>>>> 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
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From bill at herrin.us  Thu Oct  7 09:54:00 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 7 Oct 2010 09:54:00 -0400
Subject: [arin-ppml] I Oppose 2010-12: IPv6 Subsequent Allocation
In-Reply-To: <6352E671-A11E-446F-9088-CBA2BF5A1F5D@delong.com>
References: <AANLkTikP7DKr0kDUTwAv97awmnQTxY-bHqZHiwH8ONHN@mail.gmail.com>
	<2E2FECEBAE57CC4BAACDE67638305F10488C4BA9CF@ROCH-EXCH1.corp.pvt>
	<AANLkTik4opowWpe1sOwzfv5DmK=ogw+jbDKUyNBunHTz@mail.gmail.com>
	<6352E671-A11E-446F-9088-CBA2BF5A1F5D@delong.com>
Message-ID: <AANLkTi=Gc0f2m7f9UiKU0ujboyK26nEOtKE63qK6FL_C@mail.gmail.com>

On Tue, Oct 5, 2010 at 3:56 AM, Owen DeLong <owen at delong.com> wrote:
> I would actually support these changes. I'd put the upper bound at /24 rather than /26, as I
> believe we should stop issuing things on non-nibble boundaries in general.

Hi Owen,

I'd rather see it at /28 but I concede the existence of credible cases
where a particular transition scheme needs to consume a full /28. It's
not unreasonable to expect that an ISP might want non-transition space
in the same allocation (pushing it to /27) and the ISP might usefully
try a second transition scheme without decommissioning the first
(needing another /28, thus pushing the whole thing to /26.)

Barring a classification of a address pools where the next pool bigger
than /28 allocates /24s, I'd prefer not to see allocation for
transition addresses exceed /26. Past that a network is getting rather
firmly embedded in the "I'm sloppy with my network management and I
want everybody else to pay for it" territory.

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 jmaimon at chl.com  Thu Oct  7 10:45:26 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Thu, 07 Oct 2010 10:45:26 -0400
Subject: [arin-ppml] I oppose 2010-10 Global Policy for IPv4 Allocations by
 the IANA Post Exhaustion
Message-ID: <4CADDD06.9040408@chl.com>

But mostly due only to the hard coding of /10, which would make it 
difficult for ARIN to enlarge 4.10 should it wish to do so.

Joe



From jmaimon at chl.com  Thu Oct  7 10:45:40 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Thu, 07 Oct 2010 10:45:40 -0400
Subject: [arin-ppml] Global Transfer policy
Message-ID: <4CADDD14.6000701@chl.com>

I did have a simple thought on the matter.

Global policy that specifies that any transfer between any two RiR needs 
to conform to the policies of both should be a simple enough solution.

Joe


From scottleibrand at gmail.com  Thu Oct  7 10:51:24 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 7 Oct 2010 10:51:24 -0400
Subject: [arin-ppml] Global Transfer policy
In-Reply-To: <4CADDD14.6000701@chl.com>
References: <4CADDD14.6000701@chl.com>
Message-ID: <01db01cb662f$1e516d20$5af44760$@com>

Joe: yes, that is an idea we've been batting around.  I'd be happy to work
with you and any other interested parties, here and especially in other
regions, to draft simple policy along those lines to allow inter-RIR
transfers.

Do people think that now is a good time to start discussing globally (or
inter-RIR) coordinated transfer policy?

-Scott

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Joe Maimon
Sent: Thursday, October 07, 2010 10:46 AM
To: ppml at arin.net
Subject: [arin-ppml] Global Transfer policy

I did have a simple thought on the matter.

Global policy that specifies that any transfer between any two RiR needs 
to conform to the policies of both should be a simple enough solution.

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.



From bill at herrin.us  Thu Oct  7 10:50:45 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 7 Oct 2010 10:50:45 -0400
Subject: [arin-ppml] Draft Policy 2010-14: Standardize IP Reassignment
 Registration Requirements
In-Reply-To: <4C61C448.7090403@arin.net>
References: <4C61C448.7090403@arin.net>
Message-ID: <AANLkTimBMoNfeBhJWE2T4vfYf7Pd8O3JiW8yrHBx2XLA@mail.gmail.com>

On Tue, Aug 10, 2010 at 5:27 PM, ARIN <info at arin.net> wrote:
> Draft Policy 2010-14
> Standardize IP Reassignment Registration Requirements
>
> ## IPv6 ##
> 6.5.5.1. Reassignment information
>
> Each IPv6 assignment containing a /64 or more addresses shall be
> registered in the WHOIS directory via SWIP or a distributed service

Hi folks,

At the mic yesterday I offered to mild applause, a view that requiring
-more- IPv6 paperwork was not a timely thing to consider. As we
struggle to put IPv6 in users' hands, we need extra red tape like a we
need holes in the head.

On the other hand, our friends in law enforcement offered persuasive
arguments for the value of good and open reassignment documentation,
while wiser folks than I pointed out the value of knowing up front
what documentation will be expected and when.

So, I propose this compromise:

Let's optimize the documentation requirements and let's publish them.
But let's include this caveat:

"In the interests of facilitating IPv6 deployment, IPv6 reassignment
documentation requirements shall not be enforced before 1/1/2015."

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 jmaimon at chl.com  Thu Oct  7 11:15:20 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Thu, 07 Oct 2010 11:15:20 -0400
Subject: [arin-ppml] Global Transfer policy
In-Reply-To: <01db01cb662f$1e516d20$5af44760$@com>
References: <4CADDD14.6000701@chl.com> <01db01cb662f$1e516d20$5af44760$@com>
Message-ID: <4CADE408.3020405@chl.com>

Scott,

Do I think its a good time to start that one up?

Only in as much that global consensus on anything post depletion seems 
to depend on hammering out that detail.

Joe

Scott Leibrand wrote:
> Joe: yes, that is an idea we've been batting around.  I'd be happy to work
> with you and any other interested parties, here and especially in other
> regions, to draft simple policy along those lines to allow inter-RIR
> transfers.
>
> Do people think that now is a good time to start discussing globally (or
> inter-RIR) coordinated transfer policy?
>
> -Scott
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Joe Maimon
> Sent: Thursday, October 07, 2010 10:46 AM
> To: ppml at arin.net
> Subject: [arin-ppml] Global Transfer policy
>
> I did have a simple thought on the matter.
>
> Global policy that specifies that any transfer between any two RiR needs
> to conform to the policies of both should be a simple enough solution.
>
> 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.
>
>
>    


From owen at delong.com  Thu Oct  7 11:24:36 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 7 Oct 2010 08:24:36 -0700
Subject: [arin-ppml] Draft Policy 2010-14: Standardize IP Reassignment
	Registration Requirements
In-Reply-To: <AANLkTimBMoNfeBhJWE2T4vfYf7Pd8O3JiW8yrHBx2XLA@mail.gmail.com>
References: <4C61C448.7090403@arin.net>
	<AANLkTimBMoNfeBhJWE2T4vfYf7Pd8O3JiW8yrHBx2XLA@mail.gmail.com>
Message-ID: <2E4BD4EB-F651-4DDB-BECD-6A0D1BCBB56B@delong.com>

> 
> 
> "In the interests of facilitating IPv6 deployment, IPv6 reassignment
> documentation requirements shall not be enforced before 1/1/2015."
> 
I could support 1/1/2012. 2015 is too far out.

Owen



From bill at herrin.us  Thu Oct  7 11:46:17 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 7 Oct 2010 11:46:17 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
Message-ID: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>

Hi folks,

Over the course of the week I've had the opportunity to talk to a
number of wonderful folks in the operator community here at the
meeting in Atlanta. As expected we often talked of IPv6 and in some
cases the conversation wandered to a question that has puzzled me for
some time:

"Why not look in the BGP table, take every announced ARIN AS number
and preemptively assign IPv6 addresses to each associated organization
that doesn't already have them? Not forever of course... give it three
years and then the assignments evaporate unless claimed by signing an
RSA and paying the annual fees."

When I posed this question the responses were largely variants on,
"That would make too much sense."

So I put it to the list. Have we some stick rammed far enough up our
collective backside that we're willing to tell people: you MUST deploy
IPv6, it alone will save the Internet's soul. And oh by the way you
need our permission to start for real. So fill out the form, make your
checks payable and we'll get back to you.

For your consideration,
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 tdurack at gmail.com  Thu Oct  7 12:00:41 2010
From: tdurack at gmail.com (Tim Durack)
Date: Thu, 7 Oct 2010 12:00:41 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
Message-ID: <AANLkTi=LU5yFz9fWQtAdtHqBFjoe7z7rO9mSD5ts4DGM@mail.gmail.com>

On Thu, Oct 7, 2010 at 11:46 AM, William Herrin <bill at herrin.us> wrote:

> "Why not look in the BGP table, take every announced ARIN AS number
> and preemptively assign IPv6 addresses to each associated organization
> that doesn't already have them? Not forever of course... give it three
> years and then the assignments evaporate unless claimed by signing an
> RSA and paying the annual fees."
>
> When I posed this question the responses were largely variants on,
> "That would make too much sense."
>
> So I put it to the list. Have we some stick rammed far enough up our
> collective backside that we're willing to tell people: you MUST deploy
> IPv6, it alone will save the Internet's soul. And oh by the way you
> need our permission to start for real. So fill out the form, make your
> checks payable and we'll get back to you.
>
> For your consideration,
> Bill Herrin
>

Great idea...

Back in time, 10/04/2010 21:36, Tim Durack wrote:
> Notify all holders of a currently active AS they have been
> allocated/assigned a /32. No fees. No questions.
>
> To accept the allocation/assignment, it must be advertised within a 24
> month period.
>
> There is no shortage of available /32s in 2000::/3. There is a serious
> shortage of meaningful deployment.

-- 
Tim:>


From mpetach at netflight.com  Thu Oct  7 12:11:28 2010
From: mpetach at netflight.com (Matthew Petach)
Date: Thu, 7 Oct 2010 09:11:28 -0700
Subject: [arin-ppml] 2010.10.07 ARIN26 day 2 morning notes
Message-ID: <AANLkTinKhXOH4pw8nct-t4CpgUbgyRJFOXNJYHKyYXz2@mail.gmail.com>

I posted my quickie notes from the morning session at today's
ARIN meeting at
http://kestrel3.netflight.com/2010.10.07-ARIN26-morning-notes.txt
It's not an official transcript or anything, but just what I jotted down
as it went flying past.  I think people drank too much coffee, as the
slides were flying fast and furious all morning.  ^_^;

Matt


From Brian.Knight at us.mizuho-sc.com  Thu Oct  7 12:37:46 2010
From: Brian.Knight at us.mizuho-sc.com (Knight, Brian)
Date: Thu, 7 Oct 2010 12:37:46 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
Message-ID: <54777E145E97BE4E8C5A26DD78EFB11B04F5650E@EXMAIL.usi.mizuho-sc.com>

Bill

By having ARIN assign these resources pre-emptively, are you advocating that
the assignment fee for all entities, both end-users and service providers, be
waived?

I don't think that fee would be a show-stopper for my end-user organization
when v6 becomes mission-critical.  However, it does prevent me from reserving
our assignments now to start doing integration tests and trials.  If we could
get an assignment now, for free, it would give technical folk here more time
to prepare for dual-stacking.

Having already signed an RSA for our v4 and AS number resources, and given
that we already pay the yearly fee, the v6 assignment would cost us nothing
more.  I can easily justify that.

IIRC many of the objections over providing free space to end-users centered
around multihoming.  Since it seems clear that multihoming using BGP will
continue at least for now, at least those objections should be quieted.

-Brian Knight 
Sr. Network Engineer 
Mizuho Securities USA Inc
http://www.mizuhosecurities.com/ 


* Please note that I do not speak for my employer - only for myself. 

** Please also note that all ARIN PPML list members and archive readers may
consider themselves Recipients of this message, in reference to the appended
disclaimer.  (I don't add it myself and can't control it, sorry.)


> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin
> Sent: Thursday, October 07, 2010 10:46 AM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Preemptive IPv6 assignment
> 
> Hi folks,
> 
> Over the course of the week I've had the opportunity to talk 
> to a number of wonderful folks in the operator community here 
> at the meeting in Atlanta. As expected we often talked of 
> IPv6 and in some cases the conversation wandered to a 
> question that has puzzled me for some time:
> 
> "Why not look in the BGP table, take every announced ARIN AS 
> number and preemptively assign IPv6 addresses to each 
> associated organization that doesn't already have them? Not 
> forever of course... give it three years and then the 
> assignments evaporate unless claimed by signing an RSA and 
> paying the annual fees."
> 
> When I posed this question the responses were largely 
> variants on, "That would make too much sense."
> 
> So I put it to the list. Have we some stick rammed far enough 
> up our collective backside that we're willing to tell people: 
> you MUST deploy IPv6, it alone will save the Internet's soul. 
> And oh by the way you need our permission to start for real. 
> So fill out the form, make your checks payable and we'll get 
> back to you.
> 
> For your consideration,
> 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 
> _______________________________________________
> 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.
> 
CONFIDENTIAL: This e-mail, including its contents and attachments,
if any, are confidential. It is neither an offer to buy or sell,
nor a solicitation of an offer to buy or sell, any securities or
any related financial instruments mentioned in it. If you are not
the named recipient please notify the sender and immediately delete
it. You may not disseminate, distribute, or forward this e-mail
message or disclose its contents to anybody else. Unless otherwise
indicated, copyright and any other intellectual property rights in
its contents are the sole property of Mizuho Securities USA Inc.
     E-mail transmission cannot be guaranteed to be secure or
error-free. The sender therefore does not accept liability for any
errors or omissions in the contents of this message which arise as
a result of e-mail transmission.  If verification is required
please request a hard-copy version.
     Although we routinely screen for viruses, addressees should
check this e-mail and any attachments for viruses. We make no
representation or warranty as to the absence of viruses in this
e-mail or any attachments. Please note that to ensure regulatory
compliance and for the protection of our customers and business, we
may monitor and read e-mails sent to and from our server(s).
#####################################################################################


From charityg at diplomacy.edu  Thu Oct  7 13:43:18 2010
From: charityg at diplomacy.edu (Charity Gamboa)
Date: Thu, 7 Oct 2010 12:43:18 -0500
Subject: [arin-ppml] 2010.10.07 ARIN26 day 2 morning notes
In-Reply-To: <AANLkTinKhXOH4pw8nct-t4CpgUbgyRJFOXNJYHKyYXz2@mail.gmail.com>
References: <AANLkTinKhXOH4pw8nct-t4CpgUbgyRJFOXNJYHKyYXz2@mail.gmail.com>
Message-ID: <AANLkTikZ8y6vyZdphwUv8YRXGotOW5JRMEP_3PY4c0Uz@mail.gmail.com>

Thank you for the notes Matthew. It does help..especially for someone like
me trying to catch up. Keep it coming and I'll tweet it to my community.
(",)

Charity

On Thu, Oct 7, 2010 at 11:11 AM, Matthew Petach <mpetach at netflight.com>wrote:

> I posted my quickie notes from the morning session at today's
> ARIN meeting at
> http://kestrel3.netflight.com/2010.10.07-ARIN26-morning-notes.txt
> It's not an official transcript or anything, but just what I jotted down
> as it went flying past.  I think people drank too much coffee, as the
> slides were flying fast and furious all morning.  ^_^;
>
> Matt
> _______________________________________________
> 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.
>



-- 
Charity Gamboa-Embley
IGCBP10 MENA Group Tutor
Diplo Foundation
CharityG at diplomacy.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101007/9b153fb2/attachment.htm>

From ljorgenson at inetco.com  Thu Oct  7 13:44:09 2010
From: ljorgenson at inetco.com (Loki Jorgenson)
Date: Thu, 7 Oct 2010 13:44:09 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <mailman.7.1286467201.26397.arin-ppml@arin.net>
References: <mailman.7.1286467201.26397.arin-ppml@arin.net>
Message-ID: <4CAE06E9.4060304@inetco.com>

  With admittedly limited perspective on the implications, I support the 
intention fully.  Efforts to date to promote IPv6 adoption have been 
typically passive and relied on non-existent market forces to drive the 
transition - much more aggressive measures to promotion are welcomed.  
By all means, implicate the stakeholders.
> Message: 7
> Date: Thu, 7 Oct 2010 11:46:17 -0400
> From: William Herrin<bill at herrin.us>
> To:arin-ppml at arin.net
> Subject: [arin-ppml] Preemptive IPv6 assignment
>
>
> Hi folks,
>
> Over the course of the week I've had the opportunity to talk to a
> number of wonderful folks in the operator community here at the
> meeting in Atlanta. As expected we often talked of IPv6 and in some
> cases the conversation wandered to a question that has puzzled me for
> some time:
>
> "Why not look in the BGP table, take every announced ARIN AS number
> and preemptively assign IPv6 addresses to each associated organization
> that doesn't already have them? Not forever of course... give it three
> years and then the assignments evaporate unless claimed by signing an
> RSA and paying the annual fees."
>
> When I posed this question the responses were largely variants on,
> "That would make too much sense."
>
> So I put it to the list. Have we some stick rammed far enough up our
> collective backside that we're willing to tell people: you MUST deploy
> IPv6, it alone will save the Internet's soul. And oh by the way you
> need our permission to start for real. So fill out the form, make your
> checks payable and we'll get back to you.
>
> For your consideration,
> Bill Herrin
>
-- 
Loki Jorgenson
ljorgenson at inetco.com
(604) 908-5833



From kkargel at polartel.com  Thu Oct  7 14:28:18 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 7 Oct 2010 13:28:18 -0500
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
Message-ID: <8695009A81378E48879980039EEDAD288C049CFB@MAIL1.polartel.local>

I support pre-emptive assignment of one IPV-6 netblock per ASN meeting current minimum and allocation policies.  I do not see a reason for a reclamation timer if the block would not affect fees.

Kevin Kargel

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of William Herrin
> Sent: Thursday, October 07, 2010 10:46 AM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Preemptive IPv6 assignment
> 
> Hi folks,
> 
> Over the course of the week I've had the opportunity to talk to a
> number of wonderful folks in the operator community here at the
> meeting in Atlanta. As expected we often talked of IPv6 and in some
> cases the conversation wandered to a question that has puzzled me for
> some time:
> 
> "Why not look in the BGP table, take every announced ARIN AS number
> and preemptively assign IPv6 addresses to each associated organization
> that doesn't already have them? Not forever of course... give it three
> years and then the assignments evaporate unless claimed by signing an
> RSA and paying the annual fees."
> 
> When I posed this question the responses were largely variants on,
> "That would make too much sense."
> 
> So I put it to the list. Have we some stick rammed far enough up our
> collective backside that we're willing to tell people: you MUST deploy
> IPv6, it alone will save the Internet's soul. And oh by the way you
> need our permission to start for real. So fill out the form, make your
> checks payable and we'll get back to you.
> 
> For your consideration,
> 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
> _______________________________________________
> 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 heather.skanks at gmail.com  Thu Oct  7 14:40:43 2010
From: heather.skanks at gmail.com (Heather Schiller)
Date: Thu, 7 Oct 2010 14:40:43 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
Message-ID: <AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>

Obtaining v6 address space is not the problem, deployment is.  Giving
people IPv6 space is *not* the same thing as deployment.  If getting
space is the problem, that should be addressed in policy.  Unlike a
couple of years ago, we aren't hearing a cacophony of folks who can
not get an IPv6 prefix.  It's likely that most people who want space
can get it, more importantly they can get it in a timely manner that
would not interfere with their deployment plans.   Massively assigning
space doesn't come with a person to design your addressing plan,
updated software tools to support and configure, or turn v6 on your
routers.

In fact, I would argue against forced assignment - because monitoring
number of requests from the RIR may be a useful measure of potential
v6 adoption - if nothing else, it's an indication of the number of
organizations who have given it enough consideration to request a
prefix.  By letting folks request v6 on their own, you have a handy
list of folks who need outreach.

--Heather

On Thu, Oct 7, 2010 at 11:46 AM, William Herrin <bill at herrin.us> wrote:
> Hi folks,
>
> Over the course of the week I've had the opportunity to talk to a
> number of wonderful folks in the operator community here at the
> meeting in Atlanta. As expected we often talked of IPv6 and in some
> cases the conversation wandered to a question that has puzzled me for
> some time:
>
> "Why not look in the BGP table, take every announced ARIN AS number
> and preemptively assign IPv6 addresses to each associated organization
> that doesn't already have them? Not forever of course... give it three
> years and then the assignments evaporate unless claimed by signing an
> RSA and paying the annual fees."
>
> When I posed this question the responses were largely variants on,
> "That would make too much sense."
>
> So I put it to the list. Have we some stick rammed far enough up our
> collective backside that we're willing to tell people: you MUST deploy
> IPv6, it alone will save the Internet's soul. And oh by the way you
> need our permission to start for real. So fill out the form, make your
> checks payable and we'll get back to you.
>
> For your consideration,
> 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
> _______________________________________________
> 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 Oct  7 15:00:12 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 7 Oct 2010 14:00:12 -0500
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>
Message-ID: <8695009A81378E48879980039EEDAD288C049D00@MAIL1.polartel.local>

Agreed --  assignment is not deployment.

What I do think about preemptive assignment is that there are quite a few netadmins who would experiment with something they happen to already have and are just not motivated to jump through the hoops to get an allocation.

Premptive allocation that would put IPv6 blocks in the hands of netadmins without the need to do paperwork or argue through the bureaucracy for authorization would IMHO further IPv6 adoption.

Kevin

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Heather Schiller
> Sent: Thursday, October 07, 2010 1:41 PM
> To: William Herrin
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Preemptive IPv6 assignment
> 
> Obtaining v6 address space is not the problem, deployment is.  Giving
> people IPv6 space is *not* the same thing as deployment.  If getting
> space is the problem, that should be addressed in policy.  Unlike a
> couple of years ago, we aren't hearing a cacophony of folks who can
> not get an IPv6 prefix.  It's likely that most people who want space
> can get it, more importantly they can get it in a timely manner that
> would not interfere with their deployment plans.   Massively assigning
> space doesn't come with a person to design your addressing plan,
> updated software tools to support and configure, or turn v6 on your
> routers.
> 
> In fact, I would argue against forced assignment - because monitoring
> number of requests from the RIR may be a useful measure of potential
> v6 adoption - if nothing else, it's an indication of the number of
> organizations who have given it enough consideration to request a
> prefix.  By letting folks request v6 on their own, you have a handy
> list of folks who need outreach.
> 
> --Heather
> 
> On Thu, Oct 7, 2010 at 11:46 AM, William Herrin <bill at herrin.us> wrote:
> > Hi folks,
> >
> > Over the course of the week I've had the opportunity to talk to a
> > number of wonderful folks in the operator community here at the
> > meeting in Atlanta. As expected we often talked of IPv6 and in some
> > cases the conversation wandered to a question that has puzzled me for
> > some time:
> >
> > "Why not look in the BGP table, take every announced ARIN AS number
> > and preemptively assign IPv6 addresses to each associated organization
> > that doesn't already have them? Not forever of course... give it three
> > years and then the assignments evaporate unless claimed by signing an
> > RSA and paying the annual fees."
> >
> > When I posed this question the responses were largely variants on,
> > "That would make too much sense."
> >
> > So I put it to the list. Have we some stick rammed far enough up our
> > collective backside that we're willing to tell people: you MUST deploy
> > IPv6, it alone will save the Internet's soul. And oh by the way you
> > need our permission to start for real. So fill out the form, make your
> > checks payable and we'll get back to you.
> >
> > For your consideration,
> > 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
> > _______________________________________________
> > 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 stephen at sprunk.org  Thu Oct  7 14:58:57 2010
From: stephen at sprunk.org (Stephen Sprunk)
Date: Thu, 07 Oct 2010 13:58:57 -0500
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
Message-ID: <4CAE1871.50303@sprunk.org>

 On 07 Oct 2010 10:46, William Herrin wrote:
> "Why not look in the BGP table, take every announced ARIN AS number
> and preemptively assign IPv6 addresses to each associated organization
> that doesn't already have them? Not forever of course... give it three
> years and then the assignments evaporate unless claimed by signing an
> RSA and paying the annual fees."

I'm not fond of the idea of assigning/allocating resources to folks who
haven't asked for them, if for no other reason than such blocks will be
very attractive to fraudsters, spammers, etc.

The process for getting an initial IPv6 assignment or allocation is
already ridiculously simple, and there is no shortage of blocks to hand
out.  The effort (and cost) required to ask for a new block would be
roughly equivalent to the effort required to "claim" a preemptively
assigned/allocated block, so I see no functional difference.  What,
exactly, is this supposed to accomplish?

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/20101007/9d7bcf65/attachment.p7s>

From christopher.morrow at gmail.com  Thu Oct  7 15:00:44 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Thu, 7 Oct 2010 15:00:44 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>
Message-ID: <AANLkTik1DV25ARaWawDuXTyQv=CEQaWESJLUzT8rrnCV@mail.gmail.com>

On Thu, Oct 7, 2010 at 2:40 PM, Heather Schiller
<heather.skanks at gmail.com> wrote:
> Obtaining v6 address space is not the problem, deployment is. ?Giving
> people IPv6 space is *not* the same thing as deployment. ?If getting

+1

> space is the problem, that should be addressed in policy. ?Unlike a
> couple of years ago, we aren't hearing a cacophony of folks who can
> not get an IPv6 prefix. ?It's likely that most people who want space

+1

> can get it, more importantly they can get it in a timely manner that
> would not interfere with their deployment plans. ? Massively assigning
> space doesn't come with a person to design your addressing plan,
> updated software tools to support and configure, or turn v6 on your
> routers.

+1

>
> In fact, I would argue against forced assignment - because monitoring
> number of requests from the RIR may be a useful measure of potential
> v6 adoption - if nothing else, it's an indication of the number of
> organizations who have given it enough consideration to request a
> prefix. ?By letting folks request v6 on their own, you have a handy
> list of folks who need outreach.

and... you let them decide what size prefix is proper for their
deployment needs. If they don't have a design/deploymenr in mind, what
size would you assign them? what about future needs?

forced assignment has many problems... imho.

-Chris

>
> --Heather
>
> On Thu, Oct 7, 2010 at 11:46 AM, William Herrin <bill at herrin.us> wrote:
>> Hi folks,
>>
>> Over the course of the week I've had the opportunity to talk to a
>> number of wonderful folks in the operator community here at the
>> meeting in Atlanta. As expected we often talked of IPv6 and in some
>> cases the conversation wandered to a question that has puzzled me for
>> some time:
>>
>> "Why not look in the BGP table, take every announced ARIN AS number
>> and preemptively assign IPv6 addresses to each associated organization
>> that doesn't already have them? Not forever of course... give it three
>> years and then the assignments evaporate unless claimed by signing an
>> RSA and paying the annual fees."
>>
>> When I posed this question the responses were largely variants on,
>> "That would make too much sense."
>>
>> So I put it to the list. Have we some stick rammed far enough up our
>> collective backside that we're willing to tell people: you MUST deploy
>> IPv6, it alone will save the Internet's soul. And oh by the way you
>> need our permission to start for real. So fill out the form, make your
>> checks payable and we'll get back to you.
>>
>> For your consideration,
>> 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
>> _______________________________________________
>> 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 Wesley.E.George at sprint.com  Thu Oct  7 15:01:30 2010
From: Wesley.E.George at sprint.com (George, Wes E IV [NTK])
Date: Thu, 7 Oct 2010 14:01:30 -0500
Subject: [arin-ppml] Draft Policy 2010-14: Standardize IP Reassignment
 Registration Requirements
In-Reply-To: <AANLkTimBMoNfeBhJWE2T4vfYf7Pd8O3JiW8yrHBx2XLA@mail.gmail.com>
References: <4C61C448.7090403@arin.net>
	<AANLkTimBMoNfeBhJWE2T4vfYf7Pd8O3JiW8yrHBx2XLA@mail.gmail.com>
Message-ID: <F7EB0A7C707E39409A73CD0353242551A8C1ED253A@PLSWM01C.ad.sprint.com>

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin
Hi folks,

[[WEG]] <snip>
As we struggle to put IPv6 in users' hands, we need extra red tape like a we
need holes in the head.

So, I propose this compromise:

Let's optimize the documentation requirements and let's publish them.
But let's include this caveat:

"In the interests of facilitating IPv6 deployment, IPv6 reassignment
documentation requirements shall not be enforced before 1/1/2015."

[[WEG]] I am vehemently opposed to this proposed modification.
Put bluntly, this is short-sighted "kicking the can down the road" with no means to ensure a change in situation at the end of the delay period, while being injurious to those who need access to this information during the delay period.

Fast-forward to 2015 (or 2012 as Owen proposed) and the same folks who are bothered by a documentation requirement today will now complain that they didn't do anything with documentation upon initial deployment because they weren't required to, and now they have this huge mountain of work that they have to do to retroactively implement/validate/update their documentation so that it's useful and accurate. Even if they simply need to translate their existing internal records to something that can be updated in the RIR's systems, that likely won't be significantly easier in 2 years than it is today. Or worse, "there's no way I can make this accurate because I didn't keep good records to start with because it was hard and you didn't require it." And of course ARIN will now have a large volume of work in having to enforce updating/validating existing records, something they're already challenged to do in IPv4, and have little leverage to enforce.
And the refrain will be, "well you didn't make us do it to start with, so obviously it's not important, why are you making us do it now all of the sudden?"

Meanwhile as IPv6 deployment increases, LEAs and operators will have more and more difficulty managing problems, rooting out Spam, botnets and viruses, etc due to a phenomenal lack of information on whom to contact regarding a certain address block, and IPv6 gains a reputation as a place to hide illicit activity because it's impossible to manage/track/enforce the way that IPv4 is. It's already going to be hard enough for LEAs and others to catch up to the realities of getting to IPv4 parity on real production IPv6 deployments. So to turn your argument on its ear - they need an additional challenge in managing the transition to IPv6 in their area of the universe like they need a hole in the head.

While those with no plans to manage their documentation might save time/money in implementing a plan to update ARIN records, they'll give back a lot of it when LEAs and operators are forced to contact them directly to enforce their AUP on their end customers, serve subpoenas, fix routing problems. It wastes a lot of everyone's time for no good reason.

Part of deploying IPv6 is managing documentation as required by the internet community and the RIR policy. It's cost of doing business, just as it is with IPv4. I agree that we don't want additional barriers to entry, but this is not a good way to solve that problem, and ultimately, I think that we're rapidly moving beyond the point where barriers to entry actually matters for IPv6 adoption.
The IPv4 party is over next year. If you don't at least have a plan to do IPv6, you no longer have a viable long-term business model (at least as far as interacting with the Internet is concerned). That would be a major barrier *against* entry that trumps a relatively straightforward documentation requirement as a barrier *to* entry.

You want to help? Make a public domain/GPL address management system or other resources available that handles the SWIP or Rwhois interaction with the RIR to ease this as a headache or cost for address holders. Or make sure that the requirement for documentation is giving LEA and operators the info they need without generating increased effort in documenting things that they don't. The answer is *not* to remove the requirement for documentation altogether, delayed or permanently.

Thanks
Wes George

This e-mail may contain Sprint Nextel 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  Thu Oct  7 15:03:45 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 7 Oct 2010 12:03:45 -0700
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>
Message-ID: <FBC13EB5-4313-4D6C-B103-CAC1BFE841AF@delong.com>

Well said, Heather.

Owen

On Oct 7, 2010, at 11:40 AM, Heather Schiller wrote:

> Obtaining v6 address space is not the problem, deployment is.  Giving
> people IPv6 space is *not* the same thing as deployment.  If getting
> space is the problem, that should be addressed in policy.  Unlike a
> couple of years ago, we aren't hearing a cacophony of folks who can
> not get an IPv6 prefix.  It's likely that most people who want space
> can get it, more importantly they can get it in a timely manner that
> would not interfere with their deployment plans.   Massively assigning
> space doesn't come with a person to design your addressing plan,
> updated software tools to support and configure, or turn v6 on your
> routers.
> 
> In fact, I would argue against forced assignment - because monitoring
> number of requests from the RIR may be a useful measure of potential
> v6 adoption - if nothing else, it's an indication of the number of
> organizations who have given it enough consideration to request a
> prefix.  By letting folks request v6 on their own, you have a handy
> list of folks who need outreach.
> 
> --Heather
> 
> On Thu, Oct 7, 2010 at 11:46 AM, William Herrin <bill at herrin.us> wrote:
>> Hi folks,
>> 
>> Over the course of the week I've had the opportunity to talk to a
>> number of wonderful folks in the operator community here at the
>> meeting in Atlanta. As expected we often talked of IPv6 and in some
>> cases the conversation wandered to a question that has puzzled me for
>> some time:
>> 
>> "Why not look in the BGP table, take every announced ARIN AS number
>> and preemptively assign IPv6 addresses to each associated organization
>> that doesn't already have them? Not forever of course... give it three
>> years and then the assignments evaporate unless claimed by signing an
>> RSA and paying the annual fees."
>> 
>> When I posed this question the responses were largely variants on,
>> "That would make too much sense."
>> 
>> So I put it to the list. Have we some stick rammed far enough up our
>> collective backside that we're willing to tell people: you MUST deploy
>> IPv6, it alone will save the Internet's soul. And oh by the way you
>> need our permission to start for real. So fill out the form, make your
>> checks payable and we'll get back to you.
>> 
>> For your consideration,
>> 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
>> _______________________________________________
>> 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  Thu Oct  7 15:05:05 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Thu, 07 Oct 2010 15:05:05 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
Message-ID: <4CAE19E1.308@chl.com>

I am opposed to both proposals because the camel creeping from right to 
left of the bitspace is really starting to concern me.

Transition space for 6rd can in theory justify a /16 allocation if you 
are doing /48 per customer.

Joe


From michael.dillon at bt.com  Thu Oct  7 15:13:42 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 7 Oct 2010 20:13:42 +0100
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423937811E7C@EMV01-UKBR.domain1.systemhost.net>

> Obtaining v6 address space is not the problem, deployment is.  Giving
> people IPv6 space is *not* the same thing as deployment. 

Hear, hear.

Also, allocating numbers to people who don't need them goes against the
grain of all of ARIN's policies. It is not very hard to fill in a form
and get an IPv6 allocation. There is no problem that needs to be solved.

As for IPv6 deployment, ARIN doesn't have much to do with that. 
Deployment is an Internet operator problem, not an ARIN problem.

--Michael Dillon


From ggiesen at akn.ca  Thu Oct  7 15:18:26 2010
From: ggiesen at akn.ca (Gary Giesen)
Date: Thu, 7 Oct 2010 15:18:26 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CAE19E1.308@chl.com>
Message-ID: <C8D393E4.C796%ggiesen@akn.ca>

If the ONLY concern with either policy is the consumption of address
space, than we need have a good look in the mirror.

The sheer enormity of the v6 address space means even if we screw this up,
we still have lots of address space and time to make it right.
Overallocating will not affect routing table size (it's still a single
prefix being advertised). We need something NOW so people can start
deploying IPv6 if we're serious about making this happen. We CANNOT afford
to go through another policy cycle, we just don't have the time. Unless
you like technologies like CGN, we need to give something to people so
they can get moved over to v6 NOW.

GG

On 10-10-07 3:05 PM, "Joe Maimon" <jmaimon at chl.com> wrote:

>I am opposed to both proposals because the camel creeping from right to
>left of the bitspace is really starting to concern me.
>
>Transition space for 6rd can in theory justify a /16 allocation if you
>are doing /48 per customer.
>
>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.



From mpetach at netflight.com  Thu Oct  7 15:24:17 2010
From: mpetach at netflight.com (Matthew Petach)
Date: Thu, 7 Oct 2010 12:24:17 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CAE19E1.308@chl.com>
References: <4CAE19E1.308@chl.com>
Message-ID: <AANLkTikfjTpp3ScR+n3OCC2htdK5JNwwYGEhzK2LCupe@mail.gmail.com>

On Thu, Oct 7, 2010 at 12:05 PM, Joe Maimon <jmaimon at chl.com> wrote:
> I am opposed to both proposals because the camel creeping from right to left
> of the bitspace is really starting to concern me.
>
> Transition space for 6rd can in theory justify a /16 allocation if you are
> doing /48 per customer.
>
> Joe

I think John clarified that unless we fix the fundamental
address allocation policy, it's not clear we have a way
to do a sane and reasonable initial allocation that supports
6rd, so we probably need to look at fixing not just subsequent
allocation policy, but also initial allocation policy.

Sometimes picking up rocks reveals things underneath
you really hadn't planned on coming face-to-face with.  ^_^;

Matt


From scottleibrand at gmail.com  Thu Oct  7 15:24:55 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 7 Oct 2010 15:24:55 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CAE19E1.308@chl.com>
References: <4CAE19E1.308@chl.com>
Message-ID: <D7A88AC9-09E7-4802-B13E-3BD2C8F2532F@gmail.com>

Where would you put the concrete tent-flap camelwall? /24?

Scott

On Oct 7, 2010, at 3:05 PM, Joe Maimon <jmaimon at chl.com> wrote:

> I am opposed to both proposals because the camel creeping from right to left of the bitspace is really starting to concern me.
> 
> Transition space for 6rd can in theory justify a /16 allocation if you are doing /48 per customer.
> 
> 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.


From christopher.morrow at gmail.com  Thu Oct  7 15:27:10 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Thu, 7 Oct 2010 15:27:10 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <8695009A81378E48879980039EEDAD288C049D00@MAIL1.polartel.local>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>
	<8695009A81378E48879980039EEDAD288C049D00@MAIL1.polartel.local>
Message-ID: <AANLkTi=UKewjV-B1tSKYSKT-O16VoysXz1uD=mDBDAhQ@mail.gmail.com>

On Thu, Oct 7, 2010 at 3:00 PM, Kevin Kargel <kkargel at polartel.com> wrote:
> Agreed -- ?assignment is not deployment.
>
> What I do think about preemptive assignment is that there are quite a few netadmins who would experiment with something they happen to already have and are just not motivated to jump through the hoops to get an allocation.
>

can I point you (and these netadmins) at tunnelbroker.net? mr leber
runs a very nice service, with your ASN (or not) you can get a /48
routed down a tunnel to you for this very purpose.

> Premptive allocation that would put IPv6 blocks in the hands of netadmins without the need to do paperwork or argue through the bureaucracy for authorization would IMHO further IPv6 adoption.
>

see point above...

-chris


From ggiesen at akn.ca  Thu Oct  7 15:30:19 2010
From: ggiesen at akn.ca (Gary Giesen)
Date: Thu, 7 Oct 2010 15:30:19 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTi=UKewjV-B1tSKYSKT-O16VoysXz1uD=mDBDAhQ@mail.gmail.com>
Message-ID: <C8D397FE.C7AA%ggiesen@akn.ca>

Agreed. This is a solution in need of a problem IMHO.

GG

On 10-10-07 3:27 PM, "Christopher Morrow" <christopher.morrow at gmail.com>
wrote:

>On Thu, Oct 7, 2010 at 3:00 PM, Kevin Kargel <kkargel at polartel.com> wrote:
>> Agreed --  assignment is not deployment.
>>
>> What I do think about preemptive assignment is that there are quite a
>>few netadmins who would experiment with something they happen to already
>>have and are just not motivated to jump through the hoops to get an
>>allocation.
>>
>
>can I point you (and these netadmins) at tunnelbroker.net? mr leber
>runs a very nice service, with your ASN (or not) you can get a /48
>routed down a tunnel to you for this very purpose.
>
>> Premptive allocation that would put IPv6 blocks in the hands of
>>netadmins without the need to do paperwork or argue through the
>>bureaucracy for authorization would IMHO further IPv6 adoption.
>>
>
>see point above...
>
>-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 andrew.dul at quark.net  Thu Oct  7 15:27:39 2010
From: andrew.dul at quark.net (Andrew Dul - andrew.dul)
Date: Thu, 07 Oct 2010 13:27:39 -0600
Subject: [arin-ppml] early experimenter /32 catch-22
Message-ID: <82e6ca14ffea24a432529b7172241e94@8-continents.com>

We told people to go out and get a /32 to get some experience with IPv6,
so a lot of people went out and were allocated /32s.  Now that we are
actually getting ready to deploy production networks a number of the large
providers need to get larger blocks to address their networks even though
they haven't used up their current /32.

Seems like we need a simple policy that will either allow an ISP to return
the /32 in exchange for a larger block or get an additional larger block
that they can renumber into.  

This "production" block should be justified based upon current customer
count, an expected growth rate over the next 5-10 years, and the expected
network topology assuming some regional aggregation for large networks.

Some thoughts for discussion...

Andrew


From owen at delong.com  Thu Oct  7 15:37:57 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 7 Oct 2010 12:37:57 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CAE19E1.308@chl.com>
References: <4CAE19E1.308@chl.com>
Message-ID: <5DF50066-0402-4474-AF92-52ECFD90EF90@delong.com>

My biggest concerns with both policies and with 6rd in general are as follows:

1.	If it becomes a permanent deployment, it will seriously degrade end user
	capabilities and stifle innovation and place unnecessary limits on future
	product development. Thus, while it doesn't contain the same evils as
	NAT, it may actually have a similar impact to NAT in some ways.

2.	As much as I favor liberal allocation/assignment of IPv6 space and
	don't generally tend to accept most of the conservatism arguments,
	6rd is impressively wasteful, even by my standards. We've got the
	ability to support it as a short-term solution, but, I'd hate to see these
	assignments become in any way permanent usage.

As such, I cannot support any 6rd or transition policy which does not have
the following safeguards:

1.	A time horizon of not more than 5 years before the space is to
	be deprecated. (If there is need for an extension, a policy amendment
	can take care of this problem).

2.	Space from a separate prefix which can be reclaimed in its entirety
	and filtered by service providers to facilitate the aforementioned
	deprecation.

3.	Strict limits on the maximum prefix size to be allocated to any organization
	to facilitate the technology.

4.	Limitations of not more than 3 such allocations for different transition
	technologies per organization. (If you want to deploy a third, then,
	deprecate the first and return that space before you can get a fourth)

Owen



From christopher.morrow at gmail.com  Thu Oct  7 15:45:59 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Thu, 7 Oct 2010 15:45:59 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <5DF50066-0402-4474-AF92-52ECFD90EF90@delong.com>
References: <4CAE19E1.308@chl.com>
	<5DF50066-0402-4474-AF92-52ECFD90EF90@delong.com>
Message-ID: <AANLkTikZggx_9H8z+N9YWwUVJtdKf9VTeK3e7dBiP7W3@mail.gmail.com>

On Thu, Oct 7, 2010 at 3:37 PM, Owen DeLong <owen at delong.com> wrote:
> My biggest concerns with both policies and with 6rd in general are as follows:
>
> 1. ? ? ?If it becomes a permanent deployment, it will seriously degrade end user
> ? ? ? ?capabilities and stifle innovation and place unnecessary limits on future

more than not having ipv6 will? more than nat/nat/nat will? I'm not a
particularly large fan of 6rd either, but... it does give the
capability to get v6 to end users (in a decent quality) and today.

Talking to Mark some, and Lorenzo, and looked at ietf work ongoing to
bring operations tools/capabilities they need to deploy v6 in a
congruent manner as v4.... waiting for this will take quite a long
while (2-3 years at best for the standards work to finish, never mind
implementations).

To be clear, I'd support neither -9 nor -12, but a fix for -12 that
removed all of the 'transition technology' wording and focused on
'subsequent allocation' alone.

-chris


From marty at akamai.com  Thu Oct  7 15:46:57 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Thu, 7 Oct 2010 15:46:57 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <8695009A81378E48879980039EEDAD288C049D00@MAIL1.polartel.local>
Message-ID: <C8D39BF1.12960%marty@akamai.com>




On 10/7/10 3:00 PM, "Kevin Kargel" <kkargel at polartel.com> wrote:

> Agreed --  assignment is not deployment.
> 
> What I do think about preemptive assignment is that there are quite a few
> netadmins who would experiment with something they happen to already have and
> are just not motivated to jump through the hoops to get an allocation.



Maybe we could consider auto assignments to all new applicants for ASN's as
well?


Best,

-M<




> 
> Premptive allocation that would put IPv6 blocks in the hands of netadmins
> without the need to do paperwork or argue through the bureaucracy for
> authorization would IMHO further IPv6 adoption.
> 
> Kevin
> 
>  
> 
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of Heather Schiller
>> Sent: Thursday, October 07, 2010 1:41 PM
>> To: William Herrin
>> Cc: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] Preemptive IPv6 assignment
>> 
>> Obtaining v6 address space is not the problem, deployment is.  Giving
>> people IPv6 space is *not* the same thing as deployment.  If getting
>> space is the problem, that should be addressed in policy.  Unlike a
>> couple of years ago, we aren't hearing a cacophony of folks who can
>> not get an IPv6 prefix.  It's likely that most people who want space
>> can get it, more importantly they can get it in a timely manner that
>> would not interfere with their deployment plans.   Massively assigning
>> space doesn't come with a person to design your addressing plan,
>> updated software tools to support and configure, or turn v6 on your
>> routers.
>> 
>> In fact, I would argue against forced assignment - because monitoring
>> number of requests from the RIR may be a useful measure of potential
>> v6 adoption - if nothing else, it's an indication of the number of
>> organizations who have given it enough consideration to request a
>> prefix.  By letting folks request v6 on their own, you have a handy
>> list of folks who need outreach.
>> 
>> --Heather
>> 
>> On Thu, Oct 7, 2010 at 11:46 AM, William Herrin <bill at herrin.us> wrote:
>>> Hi folks,
>>> 
>>> Over the course of the week I've had the opportunity to talk to a
>>> number of wonderful folks in the operator community here at the
>>> meeting in Atlanta. As expected we often talked of IPv6 and in some
>>> cases the conversation wandered to a question that has puzzled me for
>>> some time:
>>> 
>>> "Why not look in the BGP table, take every announced ARIN AS number
>>> and preemptively assign IPv6 addresses to each associated organization
>>> that doesn't already have them? Not forever of course... give it three
>>> years and then the assignments evaporate unless claimed by signing an
>>> RSA and paying the annual fees."
>>> 
>>> When I posed this question the responses were largely variants on,
>>> "That would make too much sense."
>>> 
>>> So I put it to the list. Have we some stick rammed far enough up our
>>> collective backside that we're willing to tell people: you MUST deploy
>>> IPv6, it alone will save the Internet's soul. And oh by the way you
>>> need our permission to start for real. So fill out the form, make your
>>> checks payable and we'll get back to you.
>>> 
>>> For your consideration,
>>> 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
>>> _______________________________________________
>>> 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 christopher.morrow at gmail.com  Thu Oct  7 15:47:42 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Thu, 7 Oct 2010 15:47:42 -0400
Subject: [arin-ppml] early experimenter /32 catch-22
In-Reply-To: <82e6ca14ffea24a432529b7172241e94@8-continents.com>
References: <82e6ca14ffea24a432529b7172241e94@8-continents.com>
Message-ID: <AANLkTinjK4eZLQdFyLQdzU-RD=MPL66nD5R3RO4qzcjb@mail.gmail.com>

On Thu, Oct 7, 2010 at 3:27 PM, Andrew Dul - andrew.dul
<andrew.dul at quark.net> wrote:
> We told people to go out and get a /32 to get some experience with IPv6,
> so a lot of people went out and were allocated /32s. ?Now that we are
> actually getting ready to deploy production networks a number of the large
> providers need to get larger blocks to address their networks even though
> they haven't used up their current /32.

or another allocation for a distinct routing domain
or another allocation for a new technology deployment
or ...

> Seems like we need a simple policy that will either allow an ISP to return
> the /32 in exchange for a larger block or get an additional larger block
> that they can renumber into.

yes, to the second part. (I think)

> This "production" block should be justified based upon current customer
> count, an expected growth rate over the next 5-10 years, and the expected
> network topology assuming some regional aggregation for large networks.

-chris


From ggiesen at akn.ca  Thu Oct  7 15:49:56 2010
From: ggiesen at akn.ca (Gary Giesen)
Date: Thu, 7 Oct 2010 15:49:56 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <5DF50066-0402-4474-AF92-52ECFD90EF90@delong.com>
Message-ID: <C8D39A81.C7AF%ggiesen@akn.ca>



On 10-10-07 3:37 PM, "Owen DeLong" <owen at delong.com> wrote:

>My biggest concerns with both policies and with 6rd in general are as
>follows:
>
>1.    If it becomes a permanent deployment, it will seriously degrade end
>user
>    capabilities and stifle innovation and place unnecessary limits on
>future
>    product development. Thus, while it doesn't contain the same evils as
>    NAT, it may actually have a similar impact to NAT in some ways.

If this is truly the case, I think the market will decide, and users will
move to those ISPs that make the move to native connectivity


>2.    As much as I favor liberal allocation/assignment of IPv6 space and
>    don't generally tend to accept most of the conservatism arguments,
>    6rd is impressively wasteful, even by my standards. We've got the
>    ability to support it as a short-term solution, but, I'd hate to see
>these
>    assignments become in any way permanent usage.

I agree that this can seriously have the potential to again create the
same dual-class networks (Legacy vs post-RIR) we have in v4, where those
who got in early got a vast amount of address space and those who came
later were less fortunate.


>As such, I cannot support any 6rd or transition policy which does not have
>the following safeguards:
>
>1.    A time horizon of not more than 5 years before the space is to
>    be deprecated. (If there is need for an extension, a policy amendment
>    can take care of this problem).

I can live with this, although I expect these will live much longer.

>
>2.    Space from a separate prefix which can be reclaimed in its entirety
>    and filtered by service providers to facilitate the aforementioned
>    deprecation.

In considering your arguments (and some of my responses), I'm now leaning
this way as well. I think it's actually a good thing that we attach some
sort of stigma to these prefixes to emphasize their temporary nature.

>
>3.    Strict limits on the maximum prefix size to be allocated to any
>organization
>    to facilitate the technology.

What do you propose these are?

>
>4.    Limitations of not more than 3 such allocations for different
>transition
>    technologies per organization. (If you want to deploy a third, then,
>    deprecate the first and return that space before you can get a fourth)

Seems entirely reasonable.



From ggiesen at akn.ca  Thu Oct  7 15:51:57 2010
From: ggiesen at akn.ca (Gary Giesen)
Date: Thu, 7 Oct 2010 15:51:57 -0400
Subject: [arin-ppml] early experimenter /32 catch-22
In-Reply-To: <AANLkTinjK4eZLQdFyLQdzU-RD=MPL66nD5R3RO4qzcjb@mail.gmail.com>
Message-ID: <C8D39D08.C7C9%ggiesen@akn.ca>

I'm hoping that with sparse allocation ARIN would just be able to grow
their existing block.

GG

On 10-10-07 3:47 PM, "Christopher Morrow" <christopher.morrow at gmail.com>
wrote:

>On Thu, Oct 7, 2010 at 3:27 PM, Andrew Dul - andrew.dul
><andrew.dul at quark.net> wrote:
>> We told people to go out and get a /32 to get some experience with IPv6,
>> so a lot of people went out and were allocated /32s.  Now that we are
>> actually getting ready to deploy production networks a number of the
>>large
>> providers need to get larger blocks to address their networks even
>>though
>> they haven't used up their current /32.
>
>or another allocation for a distinct routing domain
>or another allocation for a new technology deployment
>or ...
>
>> Seems like we need a simple policy that will either allow an ISP to
>>return
>> the /32 in exchange for a larger block or get an additional larger block
>> that they can renumber into.
>
>yes, to the second part. (I think)
>
>> This "production" block should be justified based upon current customer
>> count, an expected growth rate over the next 5-10 years, and the
>>expected
>> network topology assuming some regional aggregation for large networks.
>
>-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 ggiesen at akn.ca  Thu Oct  7 15:51:22 2010
From: ggiesen at akn.ca (Gary Giesen)
Date: Thu, 7 Oct 2010 15:51:22 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <C8D39BF1.12960%marty@akamai.com>
Message-ID: <C8D39CCE.C7C6%ggiesen@akn.ca>

>
>
>
>Maybe we could consider auto assignments to all new applicants for ASN's
>as
>well?

Not everyone who has an ASN necessarily wants the expense of their own
block (consider end users).

>
>
>Best,
>
>-M<
>
>
>
>
>> 
>> Premptive allocation that would put IPv6 blocks in the hands of
>>netadmins
>> without the need to do paperwork or argue through the bureaucracy for
>> authorization would IMHO further IPv6 adoption.
>> 
>> Kevin
>> 
>>  
>> 
>>> -----Original Message-----
>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>>> Behalf Of Heather Schiller
>>> Sent: Thursday, October 07, 2010 1:41 PM
>>> To: William Herrin
>>> Cc: arin-ppml at arin.net
>>> Subject: Re: [arin-ppml] Preemptive IPv6 assignment
>>> 
>>> Obtaining v6 address space is not the problem, deployment is.  Giving
>>> people IPv6 space is *not* the same thing as deployment.  If getting
>>> space is the problem, that should be addressed in policy.  Unlike a
>>> couple of years ago, we aren't hearing a cacophony of folks who can
>>> not get an IPv6 prefix.  It's likely that most people who want space
>>> can get it, more importantly they can get it in a timely manner that
>>> would not interfere with their deployment plans.   Massively assigning
>>> space doesn't come with a person to design your addressing plan,
>>> updated software tools to support and configure, or turn v6 on your
>>> routers.
>>> 
>>> In fact, I would argue against forced assignment - because monitoring
>>> number of requests from the RIR may be a useful measure of potential
>>> v6 adoption - if nothing else, it's an indication of the number of
>>> organizations who have given it enough consideration to request a
>>> prefix.  By letting folks request v6 on their own, you have a handy
>>> list of folks who need outreach.
>>> 
>>> --Heather
>>> 
>>> On Thu, Oct 7, 2010 at 11:46 AM, William Herrin <bill at herrin.us> wrote:
>>>> Hi folks,
>>>> 
>>>> Over the course of the week I've had the opportunity to talk to a
>>>> number of wonderful folks in the operator community here at the
>>>> meeting in Atlanta. As expected we often talked of IPv6 and in some
>>>> cases the conversation wandered to a question that has puzzled me for
>>>> some time:
>>>> 
>>>> "Why not look in the BGP table, take every announced ARIN AS number
>>>> and preemptively assign IPv6 addresses to each associated organization
>>>> that doesn't already have them? Not forever of course... give it three
>>>> years and then the assignments evaporate unless claimed by signing an
>>>> RSA and paying the annual fees."
>>>> 
>>>> When I posed this question the responses were largely variants on,
>>>> "That would make too much sense."
>>>> 
>>>> So I put it to the list. Have we some stick rammed far enough up our
>>>> collective backside that we're willing to tell people: you MUST deploy
>>>> IPv6, it alone will save the Internet's soul. And oh by the way you
>>>> need our permission to start for real. So fill out the form, make your
>>>> checks payable and we'll get back to you.
>>>> 
>>>> For your consideration,
>>>> 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
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>>> 
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>
>_______________________________________________
>PPML
>You are receiving this message because you are subscribed to
>the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>Unsubscribe or manage your mailing list subscription at:
>http://lists.arin.net/mailman/listinfo/arin-ppml
>Please contact info at arin.net if you experience any issues.



From owen at delong.com  Thu Oct  7 15:50:18 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 7 Oct 2010 12:50:18 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <AANLkTikZggx_9H8z+N9YWwUVJtdKf9VTeK3e7dBiP7W3@mail.gmail.com>
References: <4CAE19E1.308@chl.com>
	<5DF50066-0402-4474-AF92-52ECFD90EF90@delong.com>
	<AANLkTikZggx_9H8z+N9YWwUVJtdKf9VTeK3e7dBiP7W3@mail.gmail.com>
Message-ID: <CD7991F9-FA34-47CB-B2E4-6A158CE86816@delong.com>


On Oct 7, 2010, at 12:45 PM, Christopher Morrow wrote:

> On Thu, Oct 7, 2010 at 3:37 PM, Owen DeLong <owen at delong.com> wrote:
>> My biggest concerns with both policies and with 6rd in general are as follows:
>> 
>> 1.      If it becomes a permanent deployment, it will seriously degrade end user
>>        capabilities and stifle innovation and place unnecessary limits on future
> 
> more than not having ipv6 will? more than nat/nat/nat will? I'm not a
> particularly large fan of 6rd either, but... it does give the
> capability to get v6 to end users (in a decent quality) and today.
> 
Less than those, but, more than native IPv6.

> Talking to Mark some, and Lorenzo, and looked at ietf work ongoing to
> bring operations tools/capabilities they need to deploy v6 in a
> congruent manner as v4.... waiting for this will take quite a long
> while (2-3 years at best for the standards work to finish, never mind
> implementations).
> 
Hence my suggestion that we provide for 6rd, but, require that it be
something we can deprecate later.

> To be clear, I'd support neither -9 nor -12, but a fix for -12 that
> removed all of the 'transition technology' wording and focused on
> 'subsequent allocation' alone.
> 
Yeah, I can't support that without safeguards to make sure that we
can deprecate 6rd.

Owen



From marty at akamai.com  Thu Oct  7 15:59:49 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Thu, 7 Oct 2010 15:59:49 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <C8D39CCE.C7C6%ggiesen@akn.ca>
Message-ID: <C8D39EF5.1296F%marty@akamai.com>




On 10/7/10 3:51 PM, "Gary Giesen" <ggiesen at akn.ca> wrote:

>> 
>> 
>> 
>> Maybe we could consider auto assignments to all new applicants for ASN's
>> as
>> well?
> 
> Not everyone who has an ASN necessarily wants the expense of their own
> block (consider end users).
> 


Understood. Would be nice to see a real proposal that spelled out something
in detail, but overall I think that this is a good idea and anything that we
can do to remove roadblocks is a win-win from my perspective.

Best,

-M<



From jmaimon at chl.com  Thu Oct  7 16:00:17 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Thu, 07 Oct 2010 16:00:17 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <D7A88AC9-09E7-4802-B13E-3BD2C8F2532F@gmail.com>
References: <4CAE19E1.308@chl.com>
	<D7A88AC9-09E7-4802-B13E-3BD2C8F2532F@gmail.com>
Message-ID: <4CAE26D1.9030407@chl.com>

Scott,

In my most generous moods, to the point where in the existing /3, there 
would be enough allocations/assignments of that size/scale for every 
single ISP/end user that has ever existed or will ever exist in the next 
50 years that will meet their needs for at least a decade, without 
having to go brownfield.

I think thats a fairly low expectation from an address space large 
enough to number molecules.

I doubt these numbers cant be predicted with any degree of accuracy to 
any near degree of specificity. Thus, the only safe course is one that 
overestimates in the orders of magnitudes.

There is only 13 bits (8192) available for 6rd deployments storing their 
datasets into 32 bits of the space and planning on giving all their 
users /48 for 65K /64 subnets,  as per current guidance, with the 
default starting point of /32 ISP allocations.

All those deploying 6RD are not likely to be using the above math and I 
see no reason to open the door to it. Something has got to give.

Joe

Scott Leibrand wrote:
> Where would you put the concrete tent-flap camelwall? /24?
>
> Scott
>
> On Oct 7, 2010, at 3:05 PM, Joe Maimon<jmaimon at chl.com>  wrote:
>
>    
>> I am opposed to both proposals because the camel creeping from right to left of the bitspace is really starting to concern me.
>>
>> Transition space for 6rd can in theory justify a /16 allocation if you are doing /48 per customer.
>>
>> 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.
>>      
>
>    


From Wesley.E.George at sprint.com  Thu Oct  7 16:02:08 2010
From: Wesley.E.George at sprint.com (George, Wes E IV [NTK])
Date: Thu, 7 Oct 2010 15:02:08 -0500
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>
Message-ID: <F7EB0A7C707E39409A73CD0353242551A8C1ED25DD@PLSWM01C.ad.sprint.com>

Only thing that I'll add that hasn't already been said by others in opposition to this idea.

> "Why not look in the BGP table, take every announced ARIN AS number
> and preemptively assign IPv6 addresses to each associated organization
> that doesn't already have them?
[[WEG]] because every announced AS number does not necessarily need PI space. Even if you were to assume that all of the visible ASNs are multihomed (which may or may not be a valid assumption), unless ARIN is also planning to make updates to IPv6 qualification policies to make being multihomed a sole condition for justifying PI, we'd end up having to say "sorry, you don't actually qualify, give it back."

Far more useful would be for every SP that is actively delegating IPv4 space to their customers to start asking the executives of said customer company upon application/delegation (similar to the way that ARIN did) what their plan is for IPv6 and warning that they can't meet their IPv4 needs indefinitely.

Wes George


This e-mail may contain Sprint Nextel 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  Thu Oct  7 15:59:54 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 7 Oct 2010 12:59:54 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <C8D39A81.C7AF%ggiesen@akn.ca>
References: <C8D39A81.C7AF%ggiesen@akn.ca>
Message-ID: <B38D4D8F-9EBD-410A-97B7-28041A618D92@delong.com>


On Oct 7, 2010, at 12:49 PM, Gary Giesen wrote:

> 
> 
> On 10-10-07 3:37 PM, "Owen DeLong" <owen at delong.com> wrote:
> 
>> My biggest concerns with both policies and with 6rd in general are as
>> follows:
>> 
>> 1.    If it becomes a permanent deployment, it will seriously degrade end
>> user
>>   capabilities and stifle innovation and place unnecessary limits on
>> future
>>   product development. Thus, while it doesn't contain the same evils as
>>   NAT, it may actually have a similar impact to NAT in some ways.
> 
> If this is truly the case, I think the market will decide, and users will
> move to those ISPs that make the move to native connectivity
> 
This assumes a greater level of choice than is present in many markets.

> 
>> 2.    As much as I favor liberal allocation/assignment of IPv6 space and
>>   don't generally tend to accept most of the conservatism arguments,
>>   6rd is impressively wasteful, even by my standards. We've got the
>>   ability to support it as a short-term solution, but, I'd hate to see
>> these
>>   assignments become in any way permanent usage.
> 
> I agree that this can seriously have the potential to again create the
> same dual-class networks (Legacy vs post-RIR) we have in v4, where those
> who got in early got a vast amount of address space and those who came
> later were less fortunate.
> 
Indeed.

> 
>> As such, I cannot support any 6rd or transition policy which does not have
>> the following safeguards:
>> 
>> 1.    A time horizon of not more than 5 years before the space is to
>>   be deprecated. (If there is need for an extension, a policy amendment
>>   can take care of this problem).
> 
> I can live with this, although I expect these will live much longer.
> 
Probably, but, at least having a date,  a clock, and requiring policy
change to allow them to do so provides the right message.
>> 
>> 2.    Space from a separate prefix which can be reclaimed in its entirety
>>   and filtered by service providers to facilitate the aforementioned
>>   deprecation.
> 
> In considering your arguments (and some of my responses), I'm now leaning
> this way as well. I think it's actually a good thing that we attach some
> sort of stigma to these prefixes to emphasize their temporary nature.
> 
Thank you.

>> 
>> 3.    Strict limits on the maximum prefix size to be allocated to any
>> organization
>>   to facilitate the technology.
> 
> What do you propose these are?
> 
Probably a /24. That allows a /56 for end-sites which is suboptimal
(end sites should be at least a /48), but, hopefully doesn't consume
too vast a swath of IPv6 in the process (roughly a  /8).

>> 
>> 4.    Limitations of not more than 3 such allocations for different
>> transition
>>   technologies per organization. (If you want to deploy a third, then,
>>   deprecate the first and return that space before you can get a fourth)
> 
> Seems entirely reasonable.

Thanks.

Owen



From christopher.morrow at gmail.com  Thu Oct  7 16:08:37 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Thu, 7 Oct 2010 16:08:37 -0400
Subject: [arin-ppml] early experimenter /32 catch-22
In-Reply-To: <C8D39D08.C7C9%ggiesen@akn.ca>
References: <AANLkTinjK4eZLQdFyLQdzU-RD=MPL66nD5R3RO4qzcjb@mail.gmail.com>
	<C8D39D08.C7C9%ggiesen@akn.ca>
Message-ID: <AANLkTikP7db28wR5Dh0__PEn_XGaN7R_nJUjeAJ-fZ-_@mail.gmail.com>

On Thu, Oct 7, 2010 at 3:51 PM, Gary Giesen <ggiesen at akn.ca> wrote:
> I'm hoping that with sparse allocation ARIN would just be able to grow
> their existing block.

oh look, I started my v6 rollout on my wired network, I have 20
customers deployed, uptake is kinda slow. oh well, still good though!

'exec' - "Hey chris, build me a wireless network eh? you know, like
one that enables rural folk access to this interwebs and the dancing
baby videos? Yea, I get that you may need to buy transit for this
network, that you may need to have wireless backhaul links, etc...
just get it done we have customers to service!"

me - "ok, well... I don't want the new wireless network with lower
speed core interfaces and less transit to provide transit to my
existing v6 customers on this here fancy 1gbps customer-link
deployment. I'll have to get a new netblock and not re-use the
existing /32... oh, but I can't."

replace 'wireless network' with '6rd' or 'network with a
new/different/other routing domain/requirements'

(you can't guarantee longer prefixes than a /32 get global
reachability... so subnetting the current allocation isn't feasible)
-chris

> GG
>
> On 10-10-07 3:47 PM, "Christopher Morrow" <christopher.morrow at gmail.com>
> wrote:
>
>>On Thu, Oct 7, 2010 at 3:27 PM, Andrew Dul - andrew.dul
>><andrew.dul at quark.net> wrote:
>>> We told people to go out and get a /32 to get some experience with IPv6,
>>> so a lot of people went out and were allocated /32s. ?Now that we are
>>> actually getting ready to deploy production networks a number of the
>>>large
>>> providers need to get larger blocks to address their networks even
>>>though
>>> they haven't used up their current /32.
>>
>>or another allocation for a distinct routing domain
>>or another allocation for a new technology deployment
>>or ...
>>
>>> Seems like we need a simple policy that will either allow an ISP to
>>>return
>>> the /32 in exchange for a larger block or get an additional larger block
>>> that they can renumber into.
>>
>>yes, to the second part. (I think)
>>
>>> This "production" block should be justified based upon current customer
>>> count, an expected growth rate over the next 5-10 years, and the
>>>expected
>>> network topology assuming some regional aggregation for large networks.
>>
>>-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 christopher.morrow at gmail.com  Thu Oct  7 16:12:22 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Thu, 7 Oct 2010 16:12:22 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <B38D4D8F-9EBD-410A-97B7-28041A618D92@delong.com>
References: <C8D39A81.C7AF%ggiesen@akn.ca>
	<B38D4D8F-9EBD-410A-97B7-28041A618D92@delong.com>
Message-ID: <AANLkTik1RD0mN79+5NYtsNvy34aOoUTPBZBH4nPFrRrf@mail.gmail.com>

On Thu, Oct 7, 2010 at 3:59 PM, Owen DeLong <owen at delong.com> wrote:
> Probably a /24. That allows a /56 for end-sites which is suboptimal
> (end sites should be at least a /48), but, hopefully doesn't consume
> too vast a swath of IPv6 in the process (roughly a ?/8).

can't we let the ISP decide what makes sense? it seems (to me) that a
/48 for a business-type link (your traditional T1/T3 customer type,
and office, etc.) is perfectly rational. It seems, to me, that a /56
for a consumer (dsl/cable/etc) is also quite fine.

There are, I'm sure, ISP folks who'd decide to just assign a /48
across the board... I'm not sure that guidance (aside from general
scoping) is required from ARIN to the members/users.

-chris


From heather.skanks at gmail.com  Thu Oct  7 16:14:42 2010
From: heather.skanks at gmail.com (Heather Schiller)
Date: Thu, 7 Oct 2010 16:14:42 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTi=UKewjV-B1tSKYSKT-O16VoysXz1uD=mDBDAhQ@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>
	<8695009A81378E48879980039EEDAD288C049D00@MAIL1.polartel.local>
	<AANLkTi=UKewjV-B1tSKYSKT-O16VoysXz1uD=mDBDAhQ@mail.gmail.com>
Message-ID: <AANLkTinQgC1A=m+pYQFv2AKGLq0qC62=L-rVgwXGwc80@mail.gmail.com>

On Thu, Oct 7, 2010 at 3:27 PM, Christopher Morrow
<christopher.morrow at gmail.com> wrote:
> On Thu, Oct 7, 2010 at 3:00 PM, Kevin Kargel <kkargel at polartel.com> wrote:
>> Agreed -- ?assignment is not deployment.
>>
>> What I do think about preemptive assignment is that there are quite a few netadmins who would experiment with something they happen to already have and are just not motivated to jump through the hoops to get an allocation.
>>
>
> can I point you (and these netadmins) at tunnelbroker.net? mr leber
> runs a very nice service, with your ASN (or not) you can get a /48
> routed down a tunnel to you for this very purpose.
>

Or generate a ULA prefix..

I do think that ARIN should be dropping a pretty big hint to folk who
come asking for IPv4 resources (initial or additional) and ASN's ...
while they have their attention.

>> Premptive allocation that would put IPv6 blocks in the hands of netadmins without the need to do paperwork or argue through the bureaucracy for authorization would IMHO further IPv6 adoption.
>>
>
> see point above...
>
> -chris
>


From gary.buhrmaster at gmail.com  Thu Oct  7 16:19:14 2010
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Thu, 7 Oct 2010 20:19:14 +0000
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
Message-ID: <AANLkTi=xeB-FxXwzyESDd2hriJRZ5DXr6gEjUyXN_-k_@mail.gmail.com>

On Thu, Oct 7, 2010 at 15:46, William Herrin <bill at herrin.us> wrote:
> Hi folks,
....
> "Why not look in the BGP table, take every announced ARIN AS number
> and preemptively assign IPv6 addresses to each associated organization
> that doesn't already have them? Not forever of course... give it three
> years and then the assignments evaporate unless claimed by signing an
> RSA and paying the annual fees."
>
> When I posed this question the responses were largely variants on,
> "That would make too much sense."

I was thinking along similar lines last evening, and came to
the conclusion that it made so much sense that clearly I
was not smart enough to recognize what must be the clear
and obvious (to others) objections that had been previously
discussed before I was paying attention to the ARIN PPML.
(I came up with a few issues, but none that I thought were
more important than making sure IPv6 gets deployed now).

I would support such a proposal to move forward.

Gary


From jmaimon at chl.com  Thu Oct  7 16:20:42 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Thu, 07 Oct 2010 16:20:42 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <B38D4D8F-9EBD-410A-97B7-28041A618D92@delong.com>
References: <C8D39A81.C7AF%ggiesen@akn.ca>
	<B38D4D8F-9EBD-410A-97B7-28041A618D92@delong.com>
Message-ID: <4CAE2B9A.6040101@chl.com>



Owen DeLong wrote:
>
> Probably a /24. That allows a /56 for end-sites which is suboptimal
> (end sites should be at least a /48), but, hopefully doesn't consume
> too vast a swath of IPv6 in the process (roughly a  /8).
>
>    
Does it provide enough space only for whom a /32 for native was enough 
or for all?

Would ARIN need to get another /12 to be able to address this from a 
distinct prefix? Would we expect all the other RiR's to do the same, and 
could IANA be kind enough to do it on a /8?

Could we expect all and sundry to deploy 6rd under these guidelines and 
how many bits would that actually consume?

And all even before any real use by real people.

Joe



From scottleibrand at gmail.com  Thu Oct  7 16:21:52 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 7 Oct 2010 16:21:52 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <AANLkTik1RD0mN79+5NYtsNvy34aOoUTPBZBH4nPFrRrf@mail.gmail.com>
References: <C8D39A81.C7AF%ggiesen@akn.ca>
	<B38D4D8F-9EBD-410A-97B7-28041A618D92@delong.com>
	<AANLkTik1RD0mN79+5NYtsNvy34aOoUTPBZBH4nPFrRrf@mail.gmail.com>
Message-ID: <022901cb665d$48a0f1d0$d9e2d570$@com>

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Christopher Morrow
> Sent: Thursday, October 07, 2010 4:12 PM
> To: Owen DeLong
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] Opposed to 2010-9 and 2010-12
> 
> On Thu, Oct 7, 2010 at 3:59 PM, Owen DeLong <owen at delong.com> wrote:
> > Probably a /24. That allows a /56 for end-sites which is suboptimal
> > (end sites should be at least a /48), but, hopefully doesn't consume
> > too vast a swath of IPv6 in the process (roughly a ?/8).
> 
> can't we let the ISP decide what makes sense? it seems (to me) that a
> /48 for a business-type link (your traditional T1/T3 customer type,
> and office, etc.) is perfectly rational. It seems, to me, that a /56
> for a consumer (dsl/cable/etc) is also quite fine.
> 
> There are, I'm sure, ISP folks who'd decide to just assign a /48
> across the board... I'm not sure that guidance (aside from general
> scoping) is required from ARIN to the members/users.

So you would be fine with each ISP getting a /16 for 6rd so they can do 32
bits for m-n and /48s to end users?

-Scott



From andrew.dul at quark.net  Thu Oct  7 16:23:11 2010
From: andrew.dul at quark.net (Andrew Dul - andrew.dul)
Date: Thu, 07 Oct 2010 14:23:11 -0600
Subject: [arin-ppml] early experimenter /32 catch-22
In-Reply-To: <C8D39D08.C7C9%ggiesen@akn.ca>
References: <C8D39D08.C7C9%ggiesen@akn.ca>
Message-ID: <950707e0b07b1711af8f899a7470a4b5@8-continents.com>

Quite a few of the /32s which were allocated to ISPs were not done with a
sparse allocation model.

Andrew

On Thu, 7 Oct 2010 15:51:57 -0400, Gary Giesen <ggiesen at akn.ca> wrote:
> I'm hoping that with sparse allocation ARIN would just be able to grow
> their existing block.
> 
> GG
> 
> On 10-10-07 3:47 PM, "Christopher Morrow" <christopher.morrow at gmail.com>
> wrote:
> 
>>On Thu, Oct 7, 2010 at 3:27 PM, Andrew Dul - andrew.dul
>><andrew.dul at quark.net> wrote:
>>> We told people to go out and get a /32 to get some experience with
IPv6,
>>> so a lot of people went out and were allocated /32s.  Now that we are
>>> actually getting ready to deploy production networks a number of the
>>>large
>>> providers need to get larger blocks to address their networks even
>>>though
>>> they haven't used up their current /32.
>>
>>or another allocation for a distinct routing domain
>>or another allocation for a new technology deployment
>>or ...
>>
>>> Seems like we need a simple policy that will either allow an ISP to
>>>return
>>> the /32 in exchange for a larger block or get an additional larger
block
>>> that they can renumber into.
>>
>>yes, to the second part. (I think)
>>
>>> This "production" block should be justified based upon current
customer
>>> count, an expected growth rate over the next 5-10 years, and the
>>>expected
>>> network topology assuming some regional aggregation for large
networks.
>>
>>-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  Thu Oct  7 16:21:26 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 7 Oct 2010 13:21:26 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <AANLkTik1RD0mN79+5NYtsNvy34aOoUTPBZBH4nPFrRrf@mail.gmail.com>
References: <C8D39A81.C7AF%ggiesen@akn.ca>
	<B38D4D8F-9EBD-410A-97B7-28041A618D92@delong.com>
	<AANLkTik1RD0mN79+5NYtsNvy34aOoUTPBZBH4nPFrRrf@mail.gmail.com>
Message-ID: <0C98D64A-493D-4C50-9B3B-DE2A39B30A4D@delong.com>


On Oct 7, 2010, at 1:12 PM, Christopher Morrow wrote:

> On Thu, Oct 7, 2010 at 3:59 PM, Owen DeLong <owen at delong.com> wrote:
>> Probably a /24. That allows a /56 for end-sites which is suboptimal
>> (end sites should be at least a /48), but, hopefully doesn't consume
>> too vast a swath of IPv6 in the process (roughly a  /8).
> 
> can't we let the ISP decide what makes sense? it seems (to me) that a
> /48 for a business-type link (your traditional T1/T3 customer type,
> and office, etc.) is perfectly rational. It seems, to me, that a /56
> for a consumer (dsl/cable/etc) is also quite fine.
> 
If the ISP wants to give /48s out in 6rd, that's a /16 for each ISP.
I am opposed to giving out IPv6 /16s to ISPs for 6rd. I think that
is really really bad stewardship of the address space.

> There are, I'm sure, ISP folks who'd decide to just assign a /48
> across the board... I'm not sure that guidance (aside from general
> scoping) is required from ARIN to the members/users.
> 
/48 across the board for native IPv6 is fine. That's not the
topic of this discussion. The topic of this discussion is the
upper bound for how much IPv6 space we would give to an ISP
to enable 6rd. Giving /20s or /16s strikes me as a particularly
bad idea.

Owen



From christopher.morrow at gmail.com  Thu Oct  7 16:25:46 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Thu, 7 Oct 2010 16:25:46 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <022901cb665d$48a0f1d0$d9e2d570$@com>
References: <C8D39A81.C7AF%ggiesen@akn.ca>
	<B38D4D8F-9EBD-410A-97B7-28041A618D92@delong.com>
	<AANLkTik1RD0mN79+5NYtsNvy34aOoUTPBZBH4nPFrRrf@mail.gmail.com>
	<022901cb665d$48a0f1d0$d9e2d570$@com>
Message-ID: <AANLkTi=rkyKiwkRTQ5x3Wuw-EBYv3yJV2MNxqxAgK+Tg@mail.gmail.com>

On Thu, Oct 7, 2010 at 4:21 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of Christopher Morrow
>> Sent: Thursday, October 07, 2010 4:12 PM
>> To: Owen DeLong
>> Cc: ppml at arin.net
>> Subject: Re: [arin-ppml] Opposed to 2010-9 and 2010-12
>>
>> On Thu, Oct 7, 2010 at 3:59 PM, Owen DeLong <owen at delong.com> wrote:
>> > Probably a /24. That allows a /56 for end-sites which is suboptimal
>> > (end sites should be at least a /48), but, hopefully doesn't consume
>> > too vast a swath of IPv6 in the process (roughly a ?/8).
>>
>> can't we let the ISP decide what makes sense? it seems (to me) that a
>> /48 for a business-type link (your traditional T1/T3 customer type,
>> and office, etc.) is perfectly rational. It seems, to me, that a /56
>> for a consumer (dsl/cable/etc) is also quite fine.
>>
>> There are, I'm sure, ISP folks who'd decide to just assign a /48
>> across the board... I'm not sure that guidance (aside from general
>> scoping) is required from ARIN to the members/users.
>
> So you would be fine with each ISP getting a /16 for 6rd so they can do 32
> bits for m-n and /48s to end users?

if they are planning on a transition technology (and that's their
stated reason for a subsequent allocation) it seems that 'hey, a
smaller initial prefix, until you migrate to native, seems like a
better plan, eh?'

6rd seems like strictly a consumer-tech answer.

-Chris


From Brian.Knight at us.mizuho-sc.com  Thu Oct  7 16:27:46 2010
From: Brian.Knight at us.mizuho-sc.com (Knight, Brian)
Date: Thu, 7 Oct 2010 16:27:46 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <C8D39CCE.C7C6%ggiesen@akn.ca>
References: <C8D39BF1.12960%marty@akamai.com> <C8D39CCE.C7C6%ggiesen@akn.ca>
Message-ID: <54777E145E97BE4E8C5A26DD78EFB11B04F5653E@EXMAIL.usi.mizuho-sc.com>

Gary,

> >Maybe we could consider auto assignments to all new applicants for 
> >ASN's as well?
> 
> Not everyone who has an ASN necessarily wants the expense of 
> their own block (consider end users).

End-users with an ASN do not pay anything extra in maintenance fees for v4 or
v6 ranges.  It is a flat $100/year charge for all ASN's and assigned
provider-independent ranges under a single OrgID.

https://www.arin.net/fees/fee_schedule.html#end_users

If the registration fee for a v6 range were waived for ASN holders, the total
NRC and MRC would be $0 for that v6 range.

-Brian


* Please note that all ARIN PPML list members and archive readers may
consider themselves Recipients of this message, in reference to the appended
disclaimer.  (I don't add it myself and can't control it, sorry.)
CONFIDENTIAL: This e-mail, including its contents and attachments,
if any, are confidential. It is neither an offer to buy or sell,
nor a solicitation of an offer to buy or sell, any securities or
any related financial instruments mentioned in it. If you are not
the named recipient please notify the sender and immediately delete
it. You may not disseminate, distribute, or forward this e-mail
message or disclose its contents to anybody else. Unless otherwise
indicated, copyright and any other intellectual property rights in
its contents are the sole property of Mizuho Securities USA Inc.
     E-mail transmission cannot be guaranteed to be secure or
error-free. The sender therefore does not accept liability for any
errors or omissions in the contents of this message which arise as
a result of e-mail transmission.  If verification is required
please request a hard-copy version.
     Although we routinely screen for viruses, addressees should
check this e-mail and any attachments for viruses. We make no
representation or warranty as to the absence of viruses in this
e-mail or any attachments. Please note that to ensure regulatory
compliance and for the protection of our customers and business, we
may monitor and read e-mails sent to and from our server(s).
#####################################################################################


From owen at delong.com  Thu Oct  7 16:27:51 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 7 Oct 2010 13:27:51 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CAE2B9A.6040101@chl.com>
References: <C8D39A81.C7AF%ggiesen@akn.ca>
	<B38D4D8F-9EBD-410A-97B7-28041A618D92@delong.com>
	<4CAE2B9A.6040101@chl.com>
Message-ID: <5025F541-0BBC-4EAF-A5E7-8B9A47F38685@delong.com>


On Oct 7, 2010, at 1:20 PM, Joe Maimon wrote:

> 
> 
> Owen DeLong wrote:
>> 
>> Probably a /24. That allows a /56 for end-sites which is suboptimal
>> (end sites should be at least a /48), but, hopefully doesn't consume
>> too vast a swath of IPv6 in the process (roughly a  /8).
>> 
>>   
> Does it provide enough space only for whom a /32 for native was enough or for all?
> 
By definition a /24 is enough for any ISP to do /56s for all of their IPv4 customers because
there are only 32 bits in IPv4. Since 6rd contains a mapping of the IPv4 /32 into the
IPv6 address, this is pretty basic.

Perhaps I don't understand your question.

> Would ARIN need to get another /12 to be able to address this from a distinct prefix? Would we expect all the other RiR's to do the same, and could IANA be kind enough to do it on a /8?
> 
Ideally I would like to see IANA set aside a block for this, such as 3f00/8. The RIRs might need more
than one /12 each to do this if they are giving out /24s.

> Could we expect all and sundry to deploy 6rd under these guidelines and how many bits would that actually consume?
> 
Don't know how many would deploy it. However, if EVERYONE using IPv4 today deployed in this manner and received a /24, it would consume a total (worldwide) of a bit less than a /8 (~/10+).

> And all even before any real use by real people.
> 
Not sure I understand this statement. That amount of space would facilitate 6rd to every existing customer of every ISP currently receiving IPv4 services and all future IPv4 deployments as well.

Owen



From ggiesen at akn.ca  Thu Oct  7 16:37:16 2010
From: ggiesen at akn.ca (Gary Giesen)
Date: Thu, 7 Oct 2010 16:37:16 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <54777E145E97BE4E8C5A26DD78EFB11B04F5653E@EXMAIL.usi.mizuho-sc.com>
Message-ID: <C8D3A770.C7E5%ggiesen@akn.ca>

They pay a one-time fee of $1250, which is what I was referring. Just to
be clear, I don't support the idea of auto-allocation, I was just giving
an example of a reason why someone might not want an allocation and why
auto-allocation was a bad idea...

GG

On 10-10-07 4:27 PM, "Knight, Brian" <Brian.Knight at us.mizuho-sc.com> wrote:

>Gary,
>
>> >Maybe we could consider auto assignments to all new applicants for
>> >ASN's as well?
>> 
>> Not everyone who has an ASN necessarily wants the expense of
>> their own block (consider end users).
>
>End-users with an ASN do not pay anything extra in maintenance fees for
>v4 or
>v6 ranges.  It is a flat $100/year charge for all ASN's and assigned
>provider-independent ranges under a single OrgID.
>
>https://www.arin.net/fees/fee_schedule.html#end_users
>
>If the registration fee for a v6 range were waived for ASN holders, the
>total
>NRC and MRC would be $0 for that v6 range.
>
>-Brian
>
>
>* Please note that all ARIN PPML list members and archive readers may
>consider themselves Recipients of this message, in reference to the
>appended
>disclaimer.  (I don't add it myself and can't control it, sorry.)
>CONFIDENTIAL: This e-mail, including its contents and attachments,
>if any, are confidential. It is neither an offer to buy or sell,
>nor a solicitation of an offer to buy or sell, any securities or
>any related financial instruments mentioned in it. If you are not
>the named recipient please notify the sender and immediately delete
>it. You may not disseminate, distribute, or forward this e-mail
>message or disclose its contents to anybody else. Unless otherwise
>indicated, copyright and any other intellectual property rights in
>its contents are the sole property of Mizuho Securities USA Inc.
>     E-mail transmission cannot be guaranteed to be secure or
>error-free. The sender therefore does not accept liability for any
>errors or omissions in the contents of this message which arise as
>a result of e-mail transmission.  If verification is required
>please request a hard-copy version.
>     Although we routinely screen for viruses, addressees should
>check this e-mail and any attachments for viruses. We make no
>representation or warranty as to the absence of viruses in this
>e-mail or any attachments. Please note that to ensure regulatory
>compliance and for the protection of our customers and business, we
>may monitor and read e-mails sent to and from our server(s).
>##########################################################################
>###########



From charles at office.tcsn.net  Thu Oct  7 16:37:23 2010
From: charles at office.tcsn.net (Charles O'Hern)
Date: Thu, 07 Oct 2010 13:37:23 -0700
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>
Message-ID: <4CAE2F83.50007@office.tcsn.net>

 Mine is just a very small voice, from a very small fish...-

On 10/7/10 11:40 AM, Heather Schiller wrote:
> Obtaining v6 address space is not the problem, deployment is.  Giving
> people IPv6 space is *not* the same thing as deployment.  If getting
We can't deploy what we can't get.
> space is the problem, that should be addressed in policy.  Unlike a
> couple of years ago, we aren't hearing a cacophony of folks who can
> not get an IPv6 prefix.  It's likely that most people who want space
> can get it, more importantly they can get it in a timely manner that
> would not interfere with their deployment plans.   Massively assigning
Any ISP with the minimum v4 assignment would have to double their annual ARIN fees in order to obtain a minimal v6 assignment.  Its not a stretch to say that a business of that
scale would be hard pressed, especially in the current economic environment, justifying doubling a cost like that.  This makes acquisition, for some, the immediate barrier to
deployment.  I know the fees are a bit of a dead horse themselves, but the barrier to adoption is still there.
> space doesn't come with a person to design your addressing plan,
> updated software tools to support and configure, or turn v6 on your
> routers.
>
> In fact, I would argue against forced assignment - because monitoring
> number of requests from the RIR may be a useful measure of potential
> v6 adoption - if nothing else, it's an indication of the number of
> organizations who have given it enough consideration to request a
Why not just count bgp route advertisements?
> prefix.  By letting folks request v6 on their own, you have a handy
> list of folks who need outreach.
>
> --Heather
> _______________________________________________
> 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.
I can accept that organizations like mine may be too small and innumerate to be more than a perturbation to the general policies, but I think its important to remind others, on
occasion, that we are still here.

-- 
Charles O'Hern
Network Operations
 
TCSN - The Computer Shop Netlink
1306 Pine St. Paso Robles CA 93446
1-(805) 227-7000  1-(800) 974-DISK
http://www.tcsn.net  abuse at tcsn.net



From bill at herrin.us  Thu Oct  7 16:46:10 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 7 Oct 2010 16:46:10 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>
Message-ID: <AANLkTinZh51Wzaf50iy_03_Xpvy3rdcajefoBw-+iyJ1@mail.gmail.com>

On Thu, Oct 7, 2010 at 2:40 PM, Heather Schiller
<heather.skanks at gmail.com> wrote:
> Massively assigning
> space doesn't come with a person to design your addressing plan,
> updated software tools to support and configure, or turn v6 on your
> routers.
> In fact, I would argue against forced assignment - because monitoring
> number of requests from the RIR may be a useful measure of potential
> v6 adoption - if nothing else, it's an indication of the number of
> organizations who have given it enough consideration to request a

Hi Heather,

Like a horse, you can't make me drink but you can lead me to water.

You don't have to. I'll eventually seek water on my own. But how much
money will your employer first lose to dual stack and v4 CGN?

Lead us to water. Some of us will drink.

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 andrew.koch at gawul.net  Thu Oct  7 16:53:41 2010
From: andrew.koch at gawul.net (Andrew Koch)
Date: Thu, 7 Oct 2010 16:53:41 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
Message-ID: <AANLkTikoCZiE9JuOz0kbOYmZzO+Erv072=OyDyw7pq_7@mail.gmail.com>

On Thu, Oct 7, 2010 at 11:46, William Herrin <bill at herrin.us> wrote:
> Hi folks,
>
> Over the course of the week I've had the opportunity to talk to a
> number of wonderful folks in the operator community here at the
> meeting in Atlanta. As expected we often talked of IPv6 and in some
> cases the conversation wandered to a question that has puzzled me for
> some time:
>
> "Why not look in the BGP table, take every announced ARIN AS number
> and preemptively assign IPv6 addresses to each associated organization
> that doesn't already have them? Not forever of course... give it three
> years and then the assignments evaporate unless claimed by signing an
> RSA and paying the annual fees."


What size allocation would you assign to any given AS?  For those who
do not hold any resources besides an AS?

While I like the idea of making it easy as possible to get IPv6 space,
there needs to be some planning and responsibility behind getting this
space.

Andrew Koch
andrew.koch at gawul.net
gawul00 at gmail.com


From christopher.morrow at gmail.com  Thu Oct  7 17:01:53 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Thu, 7 Oct 2010 17:01:53 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTinZh51Wzaf50iy_03_Xpvy3rdcajefoBw-+iyJ1@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>
	<AANLkTinZh51Wzaf50iy_03_Xpvy3rdcajefoBw-+iyJ1@mail.gmail.com>
Message-ID: <AANLkTikd+CtO+OzEDHTy-5hRYu3Nfxg1-bTo+mh2_2FD@mail.gmail.com>

On Thu, Oct 7, 2010 at 4:46 PM, William Herrin <bill at herrin.us> wrote:
> On Thu, Oct 7, 2010 at 2:40 PM, Heather Schiller
> <heather.skanks at gmail.com> wrote:
>> Massively assigning
>> space doesn't come with a person to design your addressing plan,
>> updated software tools to support and configure, or turn v6 on your
>> routers.
>> In fact, I would argue against forced assignment - because monitoring
>> number of requests from the RIR may be a useful measure of potential
>> v6 adoption - if nothing else, it's an indication of the number of
>> organizations who have given it enough consideration to request a
>
> Hi Heather,
>
> Like a horse, you can't make me drink but you can lead me to water.
>
> You don't have to. I'll eventually seek water on my own. But how much
> money will your employer first lose to dual stack and v4 CGN?

guessing probably none? how would those be money losers? they'll be deploying:
  o v6 - dualstack
  o v6 - CGN/6rd/dslite

either way, 'win' (and v6 deployment). If the 'cgn' is merely v4
nat44... then things just keep chugging along, eh?

I must have missed the point...

-chris

>
> Lead us to water. Some of us will drink.
>
> 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
> _______________________________________________
> 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 Oct  7 17:11:13 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 7 Oct 2010 17:11:13 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTikoCZiE9JuOz0kbOYmZzO+Erv072=OyDyw7pq_7@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<AANLkTikoCZiE9JuOz0kbOYmZzO+Erv072=OyDyw7pq_7@mail.gmail.com>
Message-ID: <AANLkTiniBR2n=ma8ZM4ioOVjqvEWCgL0W_xtw4o0D75s@mail.gmail.com>

On Thu, Oct 7, 2010 at 4:53 PM, Andrew Koch <andrew.koch at gawul.net> wrote:
> On Thu, Oct 7, 2010 at 11:46, William Herrin <bill at herrin.us> wrote:
>> "Why not look in the BGP table, take every announced ARIN AS number
>> and preemptively assign IPv6 addresses to each associated organization
>> that doesn't already have them? Not forever of course... give it three
>> years and then the assignments evaporate unless claimed by signing an
>> RSA and paying the annual fees."
>
>
> What size allocation would you assign to any given AS? ?For those who
> do not hold any resources besides an AS?

Hi Andrew,

If your AS is in the BGP table, there are two situations:

1. Transit only AS - no need for an assignment.
2. Origin AS - need an assignment.

If the AS never appears at the start of the AS path then it doesn't
need an assignment. We can give it one if we feel like it. Won't hurt
anything. It'll evaporate when they don't claim it. But we don't have
to.

Of the Origin ASes, some are announcing ARIN allocations to the same
organization, some are announcing ARIN assignments to the same
organization and some are announcing something else.

The ones announcing at least one ARIN allocation get a /32. The ones
announcing anything else get a /48. If the recipient thinks that's the
wrong size, then he trades it in, fills out paperwork with ARIN and is
no worse off than he is without the preemptive action. The other 95%
of the time, we picked an acceptable size.

Either way we've poked the registrant with a message saying, "Here are
your flashy new addresses, please go deploy." That's mildly more
persuasive than, "You should deploy. Please pay us and beg
permission."



On Thu, Oct 7, 2010 at 5:01 PM, Christopher Morrow
<christopher.morrow at gmail.com> wrote:
> either way, 'win' (and v6 deployment). If the 'cgn' is merely v4
> nat44... then things just keep chugging along, eh?
>
> I must have missed the point...

Chris,

You don't mind me waiting until I need more v4 and it's too expensive
on the market? I'll take that under advisement.

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 mpetach at netflight.com  Thu Oct  7 17:54:08 2010
From: mpetach at netflight.com (Matthew Petach)
Date: Thu, 7 Oct 2010 14:54:08 -0700
Subject: [arin-ppml] 2010.10.07 ARIN26 day 2 afternoon notes
Message-ID: <AANLkTinGDv0PzuL5-_ao5tcSOkkuqhU13EZkckUks8UY@mail.gmail.com>

OK, getting chased out for dinner--unofficial notes posted
to
http://kestrel3.netflight.com/2010.10.07-ARIN26-afternoon-notes.txt
apache restarted.  poor box keeps dying, sorry about that.  :(

Matt


From matthew at matthew.at  Thu Oct  7 18:31:14 2010
From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 07 Oct 2010 15:31:14 -0700
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTikoCZiE9JuOz0kbOYmZzO+Erv072=OyDyw7pq_7@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<AANLkTikoCZiE9JuOz0kbOYmZzO+Erv072=OyDyw7pq_7@mail.gmail.com>
Message-ID: <4CAE4A32.2020006@matthew.at>

  On 10/7/2010 1:53 PM, Andrew Koch wrote:
>
> While I like the idea of making it easy as possible to get IPv6 space,
> there needs to be some planning and responsibility behind getting this
> space.
>
Why? There's lots of it.

I have an even easier idea: Ignore what's visible in BGP and simply 
direct IANA to allocate a portion of IPv6 space such that:
<prefix>:<ASN>/<size>.

A few choices might be:
     A) prefix of 16 bits, full 32-bit ASN, size=48 (this is the obvious 
one, but then lots of entities need to come back for more, as they 
really are ISPs to more than just customers who'll take a /56 or /64... 
but it is a fairly conservative "experiment" to only use a single 16-bit 
prefix)
    B) prefix of 3 or 4 bits, 28 or 29 bits of ASN (hoping that we never 
allocate that many 32-bit ASNs), size=32 (this is the one that means 
that almost nobody ever needs to come back for more)
Nice compromises include:
     C) prefix of 4 bits, full 32 bits of ASN, size=36 (I like this as 
much or better than choice B, but one could argue that it is a lot of v6 
space to use)
     D) prefix of 8 bits, full 32 bits of ASN, size=40 (not bad, and 
doesn't use up nearly as much IPv6 space if it turns out to be a bad idea)


Then every ASN, legacy* and new, in all regions, immediately gets a 
reasonable amount of IPv6 space without any additional paperwork or 
database entries.

The only problem created by this (especially if "size" is up near or at 
/32) is a financial one for the registries... but they're going to have 
that problem with nobody coming back for additional v6 assignments anyway.

Matthew Kaufman

* I will observe here that there are lots of entities who have legacy 
IPv4 space and legacy AS numbers who currently aren't party to a LRSA 
and don't pay anyone anything. By definition, they were early adopters 
of IPv4. One might suppose that such folks might also be/have been early 
adopters of IPv6... but they are in a particular bind if they want to 
keep their status with regard to (in this region) ARIN at the same time 
as they try to be an early IPv6 adopter.



From andrew.koch at gawul.net  Fri Oct  8 01:38:42 2010
From: andrew.koch at gawul.net (Andrew Koch)
Date: Fri, 8 Oct 2010 01:38:42 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <4CAE4A32.2020006@matthew.at>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<AANLkTikoCZiE9JuOz0kbOYmZzO+Erv072=OyDyw7pq_7@mail.gmail.com>
	<4CAE4A32.2020006@matthew.at>
Message-ID: <AANLkTin55SNOFrVmfoLFcjpi9ztUFT92coaWgJqMu5DR@mail.gmail.com>

On Thu, Oct 7, 2010 at 18:31, Matthew Kaufman <matthew at matthew.at> wrote:
> ?On 10/7/2010 1:53 PM, Andrew Koch wrote:
>>
>> While I like the idea of making it easy as possible to get IPv6 space,
>> there needs to be some planning and responsibility behind getting this
>> space.
>>
> Why? There's lots of it.

Sure there may be lots of it, but what happens when you pre-assign a
/32, but the org needs a /26?  They start using their pre-assigned
addresses as you have directed for them to do, but the soon run out
and would be very painful for them to renumber into the appropriate
sized block.  Having to allocate/assign multiple times may result in
an inability to aggregate.

>
> I have an even easier idea: Ignore what's visible in BGP and simply direct
> IANA to allocate a portion of IPv6 space such that:
> <prefix>:<ASN>/<size>.
>
> A few choices might be:
> ? ?A) prefix of 16 bits, full 32-bit ASN, size=48 (this is the obvious one,
> but then lots of entities need to come back for more, as they really are
> ISPs to more than just customers who'll take a /56 or /64... but it is a
> fairly conservative "experiment" to only use a single 16-bit prefix)
> ? B) prefix of 3 or 4 bits, 28 or 29 bits of ASN (hoping that we never
> allocate that many 32-bit ASNs), size=32 (this is the one that means that
> almost nobody ever needs to come back for more)
> Nice compromises include:
> ? ?C) prefix of 4 bits, full 32 bits of ASN, size=36 (I like this as much or
> better than choice B, but one could argue that it is a lot of v6 space to
> use)
> ? ?D) prefix of 8 bits, full 32 bits of ASN, size=40 (not bad, and doesn't
> use up nearly as much IPv6 space if it turns out to be a bad idea)
>
>
> Then every ASN, legacy* and new, in all regions, immediately gets a
> reasonable amount of IPv6 space without any additional paperwork or database
> entries.
>
> The only problem created by this (especially if "size" is up near or at /32)
> is a financial one for the registries... but they're going to have that
> problem with nobody coming back for additional v6 assignments anyway.
>
> Matthew Kaufman
>
> * I will observe here that there are lots of entities who have legacy IPv4
> space and legacy AS numbers who currently aren't party to a LRSA and don't
> pay anyone anything. By definition, they were early adopters of IPv4. One
> might suppose that such folks might also be/have been early adopters of
> IPv6... but they are in a particular bind if they want to keep their status
> with regard to (in this region) ARIN at the same time as they try to be an
> early IPv6 adopter.
>
>

I also believe this creates more PI space that may not have been
otherwise needed.  This again leads to further de-aggregation and more
burned slots in expensive router memory.  So, besides the RIR possibly
loosing out on money, all routers that are in the DFZ are impacted as
well.

Andrew


From michael.dillon at bt.com  Fri Oct  8 03:33:47 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 8 Oct 2010 08:33:47 +0100
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <4CAE4A32.2020006@matthew.at>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<AANLkTikoCZiE9JuOz0kbOYmZzO+Erv072=OyDyw7pq_7@mail.gmail.com>
	<4CAE4A32.2020006@matthew.at>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423937811F63@EMV01-UKBR.domain1.systemhost.net>

> I have an even easier idea: Ignore what's visible in BGP and simply
> direct IANA to allocate a portion of IPv6 space such that:
> <prefix>:<ASN>/<size>.

Interesting idea but the IETF is over that way ---->

And be prepared for people to drag up 10 year old ideas that you
have never heard of and tell you that "we already rejected that idea".

Unfortunately, ARIN cannot direct the IANA to do anything other than
change the allocation process for blocks which the IETF has already
directed IANA to allocate via the RIRs.

--Michael Dillon



From gbonser at seven.com  Fri Oct  8 04:13:14 2010
From: gbonser at seven.com (George Bonser)
Date: Fri, 8 Oct 2010 01:13:14 -0700
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C142@RWC-EX1.corp.seven.com>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of William Herrin
> Sent: Thursday, October 07, 2010 8:46 AM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Preemptive IPv6 assignment
> 
> "Why not look in the BGP table, take every announced ARIN AS number
> and preemptively assign IPv6 addresses to each associated organization
> that doesn't already have them? Not forever of course... give it three
> years and then the assignments evaporate unless claimed by signing an
> RSA and paying the annual fees."
> 
> When I posed this question the responses were largely variants on,
> "That would make too much sense."
> 

I have not read through every response to this thread but have read over
a number of them.  It seems to me that there is considerable discussion
on the size of such allocation.

It seems that would be a fairly simple matter as you could look at the
type of organization they are and make some educated guesses and if
assignments are made on nibble boundaries, there might be room for
expansion.

For example:

Assume everyone currently in v4 space will at some point need v6 space.
An organization that is an ISP today in v4 space will probably still be
an isp in v6 space.
A large enterprise in v4 space will still be a large enterprise in v6
A network with multiple unconnected networks in v4 will still be
multiple unconnected in v6.
Etc.

The v6 assignment can probably be chosen to match fairly closely a
profile which can be fairly reasonably determined by their v4
assignments.  It might be possible to auto-categorize an AS based on
their v4 assignment.  Assignments can be made on a nibble boundary with
some padding to allow for growth.

Rather than a "one size fits all" initial assignment, it might be fairly
easy to come up with three or four categories to get the assignment
pretty close to begin with.  Maybe initial sizes of /32  /40  /44 and
/48 might do.  An ISP gets a /32, a large enterprise gets a /40, an AS
with multiple unconnected gets a /44 and run of the mill small
multihomed AS gets a /48

Maybe enough buffering can be put in place between the various types of
assignments to allow for growth commensurate with the sort of network
they are.  ISPs getting a /32 might get room to grow larger and the same
with the other types.

Or is that just too much work to try to sort out?

George




From tedm at ipinc.net  Fri Oct  8 04:54:55 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 08 Oct 2010 01:54:55 -0700
Subject: [arin-ppml] early experimenter /32 catch-22
In-Reply-To: <82e6ca14ffea24a432529b7172241e94@8-continents.com>
References: <82e6ca14ffea24a432529b7172241e94@8-continents.com>
Message-ID: <4CAEDC5F.1090803@ipinc.net>

On 10/7/2010 12:27 PM, Andrew Dul - andrew.dul wrote:
> We told people to go out and get a /32 to get some experience with IPv6,
> so a lot of people went out and were allocated /32s.  Now that we are
> actually getting ready to deploy production networks a number of the large
> providers need to get larger blocks to address their networks even though
> they haven't used up their current /32.
>
> Seems like we need a simple policy that will either allow an ISP to return
> the /32 in exchange for a larger block or get an additional larger block
> that they can renumber into.
>
> This "production" block should be justified based upon current customer
> count, an expected growth rate over the next 5-10 years, and the expected
> network topology assuming some regional aggregation for large networks.
>
> Some thoughts for discussion...
>

I really have to disagree with this.  These "experimental" blocks are
one-shot things and once they are returned we won't have this as a 
problem in the future.  I see no need to clutter up policy.

All you should have to do is put down "Returning IPv6 /32 block" as part 
of the justification you submit to the ARIN hostmaster for a larger IPv6 
block.

I would suggest that anyone in this situation start by e-mailing the
ARIN hostmaster and ask if doing it this way would be OK.  If not, THEN
let's consider policy additions.

Ted

> Andrew
> _______________________________________________
> 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  Fri Oct  8 06:41:04 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 08 Oct 2010 03:41:04 -0700
Subject: [arin-ppml] Policy Question(s)
In-Reply-To: <30271.1286361973@tristatelogic.com>
References: <30271.1286361973@tristatelogic.com>
Message-ID: <4CAEF540.60708@ipinc.net>

On 10/6/2010 3:46 AM, Ronald F. Guilmette wrote:
>
> In message<alpine.BSF.2.00.1010060153520.57601 at atlas.ipinc.net>,
> tedm at ipinc.net wrote:
>
>>> I have read the applicable documents available on the ARIN web site. They
>>> are ambiguous at best.
>>
>> That is because much of ARIN policy comes from committee.  It is the nature
>> of politics that you can often not get consensus on specific policy that
>> prohibits something where you CAN get consensus on GENERAL policy that
>> when interpreted, will prohibit that very same thing.  To put it succinctly,
>> people often don't know what they are voting for.
>
> Well, thank you.  You know, for plain simple honesty.
>
> I well and truly understand... and abide... that every law or rule must be
> interpreted.  And for that, we have things like ARIN and the U.S. Judiciary.
>
> But of course, in the case of the judiciary, when _they_ get done interpreting
> one of their rules, that interpretation quite often gets published, in public,
> and becomes ``binding''.  This is great because then, in future, everybody
> knows where they stand and what they can do and not do.
>

Ah, no.  Yes they get published.  But in the history of the US Judiciary
an enormous amount of fundamental precedent has been overturned.  The 
only difference is that the US Judiciary moves at a glacial pace 
compared to ARIN.

> But apparently, every time ARIN interprets one of its rules... you know...
> like the judiciary would... to fit some new and novel set of facts... then
> *their* decision gets burried under layers of NDAs, and is never heard from
> again.
>
> Am I the only one who sees a potential problem with this?
>

I think so. You must remember that it is in the interests of the 
Internet Community to encourage orgs to get IP space from their LIRs
and not from the RIRs.

If an org complains on this forum about how difficult it is to figure
out how to navigate the waters to get IP space I usually remind them
that their local friendly ISP is more than happy to give them the IP
space they want without having to spend all that time learning all those
pesky RIR rules and the current interpretations of them.

If we make it easy for anyone to get IP space from the RIRs then we
end up flooding the Internet with BGP advertisements.  And let me tell
you my org just dropped a thousand bucks last month into CPU updates
for some of our routers because of DFZ growth, and we were getting used 
hardware from a network hardware reseller, and the absolute minimum 
update that would work - stuff that isn't in current production, even. 
So I kind of am not real sympathetic right now to rolling out the red 
carpet to orgs that want space and don't want to do the work to 
understand everything that's under discussion here.

>> You really cannot fully understand all ARIN policy unless you understand that
>> ARIN policy consists both of the written policy - and the interpretation of
>> that written policy.
>
> Right.  Believe me, I understood that part before I even posted here the
> first time, and in fact that is precisely _why_ I posted here the first
> time... because I have first-hand knowledge that there is, on the one hand,
> the law, as written, and then there is, on the other hand, the interpretation
> of the law, with respect to various sets of facts, and the two are different
> and separate.
>
>> But, I don't think ARIN is doing this yet for a very simple reason - there
>> are addresses still available.  Instead I think what is happening is
>> that if Mr. Smith shows up on ARIN's door with a block that he "bought"
>>from depository.net, AND with justification for it, that ARIN's hostmaster
>> is granting the transfer but also saying "by the way, you did NOT need to
>> spend $$$ with depository.net, you could have got the IP numbers from
>> us, FREE"
>
> Free???  Did you say FREE??  Hay!  That just happens to be my favorite number!
>
> But seriously folks, was I asleep?  Did I fail to get the memo?  Is ARIN
> actually not charging for IP space anymore?  Funny, I could have sworn
> I saw a fee chart on their web site just the other day.  And I was
> thinking, hay, if I could talk somebody out of their (fee-free?) legacy
> /16, and if I could keep it and ``monitize'' it for, say, ten years, then,
> you know, without going thru all of the fancy schmancy ``present value''
> calculations that people who play with money for a living know about,
> my very rough estimate is that that would be worth approximately
> 10 * $4,500 == $45k.   That's minimum, of course, because that only
> represents how much you'd save on fees, you know, relative to your
> competitors who have non-legacy blocks.
>

Consider that if an org spends money to buy numbers from a broker that
they still have to pay ARIN the same yearly fee that they pay if they
just got the numbers from ARIN.  Thus why pay the broker?

>> For example you could approach a legacy address holder who has obviously
>> abandonded their legacy holdings or is sparsely using them, and say
>> "If you sign a contract with me saying that I'm your exclusive IP address
>> rep. I'll guarentee you will get XXX dollars for every block of yours
>> I help you to transfer"
>
> May I say to them instead ``I'll give you $10k right now for all rights
> and title to that legacy /16 you have lying over there in the corner,
> collecting dust.'' ?
>

No.  You may not because you don't have acceptable justification to
have that /16.  The legacy org does because of a (IMHO) rather poor
"deal" that was cut with the legacy holders in ARIN's infancy.

> See, like you said, there's middlemen, and then there's players.  Middlemen
> just facilitate transfers from A to B.  Players actually buy and hold
> _themselves_ hoping for the price to go up.
>
> I wanna be a player.  So now I just need to know if ARIN will let me put
> _my_ name on any legacy /16 I manage to aquire all existing rights and
> title to, you know, from the original owner, and of course, I'd also
> like to know if they will also delegate reverse DNS to me.
>

No, of course not.  And if you know that anyone out there
is doing this - including what was it, "depository.net" then as others
have said, turn the buggers in.  Rat them out to the RIR so that the
RIR can pull their addresses.  Don't try copying them!

>> But, an "IP Investment bank" which operated as a straight broker plus
>> also gained ownership over IP address blocks (like how many stock brokerage
>> houses which also played the market did with stocks not too long ago)
>> in order to "sell" them would be a violation, in my interpretation.
>
> A violation of what, exactly?
>
> I guess you mean of NRPM section 8, but I don't think I saw anything really
> concrete in there that was an actual prohibition.  (Can you quote me the
> actual prohibition language out of the NRPM?)
>
> And again, are we talking about the letter of the law, or are we talking
> about its interpretation, and existing precedents?
>
>> IMHO you would be a fool to attempt to invest or setup an "IP investment
>> bank"
>
> Well, that's what seemed to me might be a profitable thing to do, and I
> am not at all persuaded that ARIN could really stop me (or anyone) if
> somebody did that, and if they were dealing only in legacy blocks.
>
>> You cannot "sell" an IP block because IP
>> addresses are not property and thus cannot be owned.
>
> Ok, ok.  So I'll use the terms ``leased'' and ``sub-leased'' instead.
> Or ``sub-leased right-to-use'' or whatever the lawyers decide to call
> it.  Will that work?
>

No.  Proper terminology is in NRPM and your just going to alienate
the knowledgeable people here if you insist on using property-related
terms.

> (This is starting to remind me of the old bar joke... you know... Nobody
> ever actually ``buys'' beer.  You just rent it.  I guess that we could
> say that about everything, because we'll all die eventually, and all that
> beer we drank and all that food we consumed, and all of those PlayStations
> we threw into the dumpster after they stopped working will all be returned
> to the earth someday, one way or the other.)
>

Yes, you can say that about everything, if you take the long view.   And
they won't be returned to the Earth, but to the Universe.

>> When they start censoring you THEN you can complain.
>
> Ummm... I guess you don't see the rather obvious logical falacy in what
> you just said...
>
> ... but as I look at it some more, what you just said is actually awfully
> darned humorous.  Did you copyright that, or may I use it as a .sig?
>

Heh.  I think that when I signed on to the list I probably clicked some
boilerplate that made it copyrighted by ARIN.  Use it as a sig.  My 
favorite sig is "If what you just read didn't make you snot milk out 
your nose when you laughed then my post was a failure" but I don't use
it much.

>> The RIR (unfortunately, IMHO) at the current time does not owe you or I or any
>> one an explanation of why a particular block ownership has suddenly changed.
>> I personally
>> and professionally wish this was not the case.  But the problem is that so man
>> y
>> of the players out there regard this sort of data as competitive secrets data
>> that the RIR is in the position where it absolutely MUST guarentee the parties
>> involved in block transfers confidentiality under a legal NDA or practically
>> nobody would deal at all with ARIN.
>
> Yes.
>
> So much for ``open'' Internet governance.
>
>> we compromised and sacrificed transparency so that we could get compliance.
>
> I'm wondering if it occured to anybody, during the making of that decision,
> that what such a decision inevitably yields is an impenetrable Star Chamber,
> making un-reviewable decisions, in secret, that nobody ever even finds out
> about, let alone being able to question or understand.
>

Ah, but we didn't 'make' that decision.  It evolved out of committee. 
Like I mentioned at first, the beauty of the stuff that comes out of
committee is that people don't often realize what they are voting for.

I think the Universe laughs when people find out that they are being
forced to follow rules and regulations that they made themselves.

> I mean yes, I'm quite sure that all the people involved are of sound and
> good character... I take that as a given.  I'm sure they're all good
> people trying their best to do the right thing.  But the very _notion_
> of secrecy rubs the wrong way for some people.  I just happen to be one
> of them.
>

And you are living in the US today and with that attitude you think your 
of sound mind.  How sweet!  A romantic!

>> I think that this is a rather amusing interpretation of what's going on.
>> I am quite sure that there's no "gravy train" out there, at least, not
>> yet.
>
> Well, that's your view, based on what you know... But how do you know?

Logic.  In short, why would a legitimate number requesting org buy IP
blocks from an "IP investment house" today when they can still get
IPv4 for free from ARIN or the other RIRs.  I recognize a criminal might
want to buy.  But since fraudulent use of IP space will get it taken
away by the RIR that criminal is going to be spending a lot of money
I think once IPv4 runout has occurred, and a lot of people are looking
for IPv4.

> I mean how does anybody know?  As you've noted, all these decisions
> about what may or may not get transfered, and to whom, are being made at
> this point, and have been made, since ARIN took over, with the same level
> of secrecy as the election of the next pope, i.e. total.  Right?  Because
> everybody (or at any rate, a majority) wanted it that way.  OK fine. I
> get that part.  But now, here we are, and you actually can't tell me
> for certain, one way or the other, whether or not there's some Internet
> version of Gordon Gecko out there already, buying up IP real estate,
> quietly and secretly, and getting all those blocks quietly transfered
> to himself... or rather to his various paper subsidiaries... , again,
> very quietly.  (Perhaps this sounds far fetched, but do you happen to
> know about a company called Tactara?  Do you know how much IP real
> estate they've managed to amass, by hook or by crook?)
>
> Am I saying this _is_ happening _generally_ and other than in the one
> special case I just mentioned?  Of course not.  Not at all. Am I saying
> that anyone at ARIN is giving unfair advantage to any one party, or even
> to any set of favored parties?  Again, no, of course not.  Not at all.
> What I _am_ saying is that secrecy breeds suspicion.
>
>> I'm also quite sure that a lot of these people like this depository.net
>> are hoping that there might be a gravy train and are trying to put their
>> claim in it, should such train ever come down the tracks.
>
> As far as we know, the train is already rolling.  Secrecy, remember?
> Everything is under a thick warm fuzzy blanket of NDAs.
>
> What I _can_ tell you is that I've made a special study of so-called
> snowshoe spammers.  These people consume (and lay waste to) IP space
> just like the proverbial stuff-through-a-goose.  And when I find...
> within the IPv4 space... another one of these operations... of which
> there are hundreds, as we speak, sometimes it is obvious where they
> are getting their IP space, i.e. from crooked ISPs that are lying to
> ARIN about their sub-allocations and their effective utilization rates.
> But at other times, it is not at all obvious how one of these criminals
> managed to glom onto a big fat hunk of IP space in a time of alleged shortage.
>
> Such cases perplex me.  And I would argue that secrecy in these cases
> not only doesn't provide an answer to me personally, more importantly,
> in my opinion, it is counter to the best interests of the community.
> It's like saying that child molesters have a right-of-privacy, and so
> we ain't gonna tell you when one moves in two doors down from you.
> That used to be acceptable, but in a lot of places, it isn't anymore.
>
> Well, ok, I didn't actually intend to get off on this at all.  I know
> full well that the secrecy isn't going away anytime soon.  And I don't
> fault anybody at ARIN for its existance, because, as you noted, it was
> a ``community'' decision, made long ago, and basically, the lawyers won.
> (Note: *Not* ARIN's lawyers... everybody else's.)  But to say that it's
> a done deal and a fully settled matter, decided long long ago...  well...
> that's what a lot of people used to say about the privacy rights of
> child molesters. In short, times change, and rules evolve.  I can hope
> anyway.
>
> And a whole lot less secrecy wouldn't just help to get more spammers
> off the streets.  It also seems to me to be a prerequsite for the
> development of a fair and open marketplace for IP space... a marketplace
> that even ARIN itself floated a proposal for a couple of years ago.  I
> mean can you really imagine being a business man and investing your
> own money in an environment where your major assets, your stock in
> trade, may be subject to effective confiscation at any moment by a
> secretive Star Chamber whose decisions are un-reviewable?  No investor
> in his right mind would put his money into THAT!  Well... no _ordinary_
> investor.  So what we will predictably end up with, as the exhaustion
> end game starts to unfold, will be some real slick operators... definite
> black market types that will charge people truly astronomical prices
> for even a tiny bit of IP turf.  They'll have to, in order to make up
> for their potentially very high ``breakage'' rate.
>

Ah, but you miss the point entirely here.  We WANT this.  The WORST 
THING for the Internet would be for IPv4 to become a permanent fixture
on the Internet - which would happen if a fair and open marketplace
developed for it.  Such a happening would add an entirely useless layer
of people as Internet gatekeepers and not even filling a spaceship
and crashing it into a distant class M planet as the Golgafrinchens
did would solve the problem.

The IPv4 transfer policy was put into the NRPM as a band-aid.  Many
people, including myself, opposed it and argued against it.  Your
essentially wanting to base a permanent, ongoing business on this
one policy rule, which is exactly the kind of thing that I predicted
someone would want to do when I argued against it being stuck in
there in the first place.

IPv4 has big engineering problems on the modern Internet, everyone
realizes that now.  But not everyone seems to realize that it has even
worse political and business problems.

It would be like if the Federal government mandated that ALL auto
license plates in the United States would have UNIQUE numbers of
no more than 8 digits because it would make it slightly easier for
a photo radar to issue a speeding ticket for an out of state driver,
where the vehicle owner had the plate in a frame that obscured the
state name.  Instantly you create a shortage where none exists now,
instantly you add huge administrative overhead.  (Why do you think
that states are going from single-color license plates to picture
plates?  It's because photo radar is black and white and the picture
lets them determine the plate's state.)

For example, ARIN spends a lot of labor and time verifying that an
address requester has justification for however many numbers they want.
This is because there's a shortage of IPv4.  With IPv6 there is not
a shortage, thus ARIN can simply rubber stamp justification evidence for 
any /32 requests.  This saves money and time.
Which means that eventually our fees should decrease.

So, LET the IPv4 black market go to the gougers.  It will just make
people switch to IPv6 all that much faster and save mountains of money
for everyone on the Internet.

>> But the idea that all you need to do is throw up a Wordpress website with a
>> few IP transfer templates on it and sit back and have oodles of money
>> rolling in for doing nothing is a lot of baloney.  It's not going to happen.
>
> Me personally?  I never had anything like THAT even remotely in mind.
> I'm old fashioned.  I believe in making money the old fashion way,
> earning it.
>

Then, earn it like I suggested, as in being a middleman, and when that
peters out a few years after IPv4 runout, find something else to do.

Ted

> Regards,
> rfg
> _______________________________________________
> 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 dlw+arin at tellme.com  Fri Oct  8 09:38:42 2010
From: dlw+arin at tellme.com (David Williamson)
Date: Fri, 8 Oct 2010 06:38:42 -0700
Subject: [arin-ppml] early experimenter /32 catch-22
In-Reply-To: <AANLkTikP7db28wR5Dh0__PEn_XGaN7R_nJUjeAJ-fZ-_@mail.gmail.com>
References: <AANLkTinjK4eZLQdFyLQdzU-RD=MPL66nD5R3RO4qzcjb@mail.gmail.com>
	<C8D39D08.C7C9%ggiesen@akn.ca>
	<AANLkTikP7db28wR5Dh0__PEn_XGaN7R_nJUjeAJ-fZ-_@mail.gmail.com>
Message-ID: <20101008133841.GD10509@shell02.cell.sv2.tellme.com>

On Thu, Oct 07, 2010 at 04:08:37PM -0400, Christopher Morrow wrote:
> replace 'wireless network' with '6rd' or 'network with a
> new/different/other routing domain/requirements'

Absolutely - there's a clear need.
 
> (you can't guarantee longer prefixes than a /32 get global
> reachability... so subnetting the current allocation isn't feasible)

Is that really true?  Would someone fess up about current routing
practice?  We definitely accept longer prefixes, as we only have a /45,
and we only advertise /48s.  Of course, that's in the PI block.

There's definitely risk with accepting longer prefixes (a /32 de-agg'd
to /48 is an interesting DoS), but what are people actually doing?  I
suspect there are places where anything longer than a /32 isn't
accepted, but all I've heard so far is the rumor of that.

-David


From aaronh at bind.com  Fri Oct  8 09:54:17 2010
From: aaronh at bind.com (Aaron Hughes)
Date: Fri, 8 Oct 2010 06:54:17 -0700
Subject: [arin-ppml] early experimenter /32 catch-22
In-Reply-To: <20101008133841.GD10509@shell02.cell.sv2.tellme.com>
References: <AANLkTinjK4eZLQdFyLQdzU-RD=MPL66nD5R3RO4qzcjb@mail.gmail.com>
	<C8D39D08.C7C9%ggiesen@akn.ca>
	<AANLkTikP7db28wR5Dh0__PEn_XGaN7R_nJUjeAJ-fZ-_@mail.gmail.com>
	<20101008133841.GD10509@shell02.cell.sv2.tellme.com>
Message-ID: <20101008135417.GB30952@trace.bind.com>

IPv6 table masks (as of 5 min ago):

16, 19, 20, 21, 22, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 64

914 /48s
2056 /32s
455 non-48s or 32s
3425 Total

Cheers,
Aaron


On Fri, Oct 08, 2010 at 06:38:42AM -0700, David Williamson wrote:
> On Thu, Oct 07, 2010 at 04:08:37PM -0400, Christopher Morrow wrote:
> > replace 'wireless network' with '6rd' or 'network with a
> > new/different/other routing domain/requirements'
> 
> Absolutely - there's a clear need.
>  
> > (you can't guarantee longer prefixes than a /32 get global
> > reachability... so subnetting the current allocation isn't feasible)
> 
> Is that really true?  Would someone fess up about current routing
> practice?  We definitely accept longer prefixes, as we only have a /45,
> and we only advertise /48s.  Of course, that's in the PI block.
> 
> There's definitely risk with accepting longer prefixes (a /32 de-agg'd
> to /48 is an interesting DoS), but what are people actually doing?  I
> suspect there are places where anything longer than a /32 isn't
> accepted, but all I've heard so far is the rumor of that.
> 
> -David
> -- 
> 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.

-- 

Aaron Hughes 
aaronh at bind.com
+1-831-824-4161
Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8
http://www.bind.com/


From brandon at dodecatec.com  Fri Oct  8 09:44:07 2010
From: brandon at dodecatec.com (Brandon Thetford)
Date: Fri, 8 Oct 2010 09:44:07 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTi=UKewjV-B1tSKYSKT-O16VoysXz1uD=mDBDAhQ@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>	<AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>	<8695009A81378E48879980039EEDAD288C049D00@MAIL1.polartel.local>
	<AANLkTi=UKewjV-B1tSKYSKT-O16VoysXz1uD=mDBDAhQ@mail.gmail.com>
Message-ID: <009e01cb66ee$e20a0c30$a61e2490$@dodecatec.com>

>> Agreed -- ?assignment is not deployment.
>>
>> What I do think about preemptive assignment is that there are quite a few
netadmins who would experiment with something they happen to already have
and are just not motivated to >>jump through the hoops to get an allocation.
>>

>can I point you (and these netadmins) at tunnelbroker.net? mr leber runs a
very nice service, with your ASN (or not) you can get a /48 routed down a
tunnel to you for this very purpose.

Yes, but this also comes with the need to renumber once you finally get a
"real" allocation, down the line.  That alone may be enough to scare some
off until an alternative, more permanent solution is available.

-Brandon




From christopher.morrow at gmail.com  Fri Oct  8 09:55:16 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Fri, 8 Oct 2010 09:55:16 -0400
Subject: [arin-ppml] early experimenter /32 catch-22
In-Reply-To: <20101008133841.GD10509@shell02.cell.sv2.tellme.com>
References: <AANLkTinjK4eZLQdFyLQdzU-RD=MPL66nD5R3RO4qzcjb@mail.gmail.com>
	<C8D39D08.C7C9%ggiesen@akn.ca>
	<AANLkTikP7db28wR5Dh0__PEn_XGaN7R_nJUjeAJ-fZ-_@mail.gmail.com>
	<20101008133841.GD10509@shell02.cell.sv2.tellme.com>
Message-ID: <AANLkTikO-uTBjEOJQsPHSiM45ZyYUAGzTJ_3LSCDzZtr@mail.gmail.com>

On Fri, Oct 8, 2010 at 9:38 AM, David Williamson <dlw+arin at tellme.com> wrote:
> On Thu, Oct 07, 2010 at 04:08:37PM -0400, Christopher Morrow wrote:
>
>> (you can't guarantee longer prefixes than a /32 get global
>> reachability... so subnetting the current allocation isn't feasible)
>
> Is that really true? ?Would someone fess up about current routing

I know of a case (solved by announcing the /32 aggregate) of this, yes.
('hello docs.python.org!')

> practice? ?We definitely accept longer prefixes, as we only have a /45,
> and we only advertise /48s. ?Of course, that's in the PI block.

sure, so in the PI ranges it seems most places (save vzb?) accept to
/48. In the other allocation sets you can get to /32 but not often
very much further (for full reachability).

-chris


From christopher.morrow at gmail.com  Fri Oct  8 09:58:36 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Fri, 8 Oct 2010 09:58:36 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <009e01cb66ee$e20a0c30$a61e2490$@dodecatec.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>
	<8695009A81378E48879980039EEDAD288C049D00@MAIL1.polartel.local>
	<AANLkTi=UKewjV-B1tSKYSKT-O16VoysXz1uD=mDBDAhQ@mail.gmail.com>
	<009e01cb66ee$e20a0c30$a61e2490$@dodecatec.com>
Message-ID: <AANLkTinrWsnOq3gdhPKyWTVX36tGiopB9g9XkgkhGOLX@mail.gmail.com>

On Fri, Oct 8, 2010 at 9:44 AM, Brandon Thetford <brandon at dodecatec.com> wrote:
>>> Agreed -- ?assignment is not deployment.
>>>
>>> What I do think about preemptive assignment is that there are quite a few
> netadmins who would experiment with something they happen to already have
> and are just not motivated to >>jump through the hoops to get an allocation.
>>>
>
>>can I point you (and these netadmins) at tunnelbroker.net? mr leber runs a
> very nice service, with your ASN (or not) you can get a /48 routed down a
> tunnel to you for this very purpose.
>
> Yes, but this also comes with the need to renumber once you finally get a
> "real" allocation, down the line. ?That alone may be enough to scare some
> off until an alternative, more permanent solution is available.

I took 'experiment' as 'I put my things in a "lab" to see how they'd
work and work out bugs'

so renumbering, or a full deployment (with a numbering plan and such)
doesn't seem to be a problem there. I suspect a /32 is probably NOT
enough for most ISP-type folks anyway, so just assigning a random /32
isn't super helpful...

-chris

>
> -Brandon
>
>
> _______________________________________________
> 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 aaronh at bind.com  Fri Oct  8 10:00:39 2010
From: aaronh at bind.com (Aaron Hughes)
Date: Fri, 8 Oct 2010 07:00:39 -0700
Subject: [arin-ppml] early experimenter /32 catch-22
In-Reply-To: <AANLkTi=_+i-N+zqS2YGfJDO6bekwRfD1diotvw6=3Si2@mail.gmail.com>
References: <AANLkTinjK4eZLQdFyLQdzU-RD=MPL66nD5R3RO4qzcjb@mail.gmail.com>
	<C8D39D08.C7C9%ggiesen@akn.ca>
	<AANLkTikP7db28wR5Dh0__PEn_XGaN7R_nJUjeAJ-fZ-_@mail.gmail.com>
	<20101008133841.GD10509@shell02.cell.sv2.tellme.com>
	<20101008135417.GB30952@trace.bind.com>
	<AANLkTi=_+i-N+zqS2YGfJDO6bekwRfD1diotvw6=3Si2@mail.gmail.com>
Message-ID: <20101008140039.GC30952@trace.bind.com>

On Fri, Oct 08, 2010 at 09:56:34AM -0400, Christopher Morrow wrote:
> these don't guarantee reachability, just that someone leaked routes to
> a RouteServer... there's a bunch of  >/24 routes in v4 visible off
> routeviews too :(

I completely agree. Just pointing out how (not so) well filtering is working today. Perhaps it's time to work on the next NANOG preso on appropriate filtering in v6.

Cheers,
Aaron
-- 

Aaron Hughes 
aaronh at bind.com
+1-831-824-4161
Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8
http://www.bind.com/


From christopher.morrow at gmail.com  Fri Oct  8 09:56:34 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Fri, 8 Oct 2010 09:56:34 -0400
Subject: [arin-ppml] early experimenter /32 catch-22
In-Reply-To: <20101008135417.GB30952@trace.bind.com>
References: <AANLkTinjK4eZLQdFyLQdzU-RD=MPL66nD5R3RO4qzcjb@mail.gmail.com>
	<C8D39D08.C7C9%ggiesen@akn.ca>
	<AANLkTikP7db28wR5Dh0__PEn_XGaN7R_nJUjeAJ-fZ-_@mail.gmail.com>
	<20101008133841.GD10509@shell02.cell.sv2.tellme.com>
	<20101008135417.GB30952@trace.bind.com>
Message-ID: <AANLkTi=_+i-N+zqS2YGfJDO6bekwRfD1diotvw6=3Si2@mail.gmail.com>

On Fri, Oct 8, 2010 at 9:54 AM, Aaron Hughes <aaronh at bind.com> wrote:
> IPv6 table masks (as of 5 min ago):
>
> 16, 19, 20, 21, 22, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 64
>
> 914 /48s
> 2056 /32s
> 455 non-48s or 32s
> 3425 Total

these don't guarantee reachability, just that someone leaked routes to
a RouteServer... there's a bunch of  >/24 routes in v4 visible off
routeviews too :(


From christopher.morrow at gmail.com  Fri Oct  8 10:18:01 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Fri, 8 Oct 2010 10:18:01 -0400
Subject: [arin-ppml] early experimenter /32 catch-22
In-Reply-To: <20101008140039.GC30952@trace.bind.com>
References: <AANLkTinjK4eZLQdFyLQdzU-RD=MPL66nD5R3RO4qzcjb@mail.gmail.com>
	<C8D39D08.C7C9%ggiesen@akn.ca>
	<AANLkTikP7db28wR5Dh0__PEn_XGaN7R_nJUjeAJ-fZ-_@mail.gmail.com>
	<20101008133841.GD10509@shell02.cell.sv2.tellme.com>
	<20101008135417.GB30952@trace.bind.com>
	<AANLkTi=_+i-N+zqS2YGfJDO6bekwRfD1diotvw6=3Si2@mail.gmail.com>
	<20101008140039.GC30952@trace.bind.com>
Message-ID: <AANLkTik9qOYvSxYmrgTCst34a_3uNoCXKSuHAXGP4KF-@mail.gmail.com>

On Fri, Oct 8, 2010 at 10:00 AM, Aaron Hughes <aaronh at bind.com> wrote:
> On Fri, Oct 08, 2010 at 09:56:34AM -0400, Christopher Morrow wrote:
>> these don't guarantee reachability, just that someone leaked routes to
>> a RouteServer... there's a bunch of ?>/24 routes in v4 visible off
>> routeviews too :(
>
> I completely agree. Just pointing out how (not so) well filtering is working today. Perhaps it's time to work on the next NANOG preso on appropriate filtering in v6.

yes :)


From brandon at dodecatec.com  Fri Oct  8 10:20:46 2010
From: brandon at dodecatec.com (Brandon Thetford)
Date: Fri, 8 Oct 2010 10:20:46 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTinrWsnOq3gdhPKyWTVX36tGiopB9g9XkgkhGOLX@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>	<AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>	<8695009A81378E48879980039EEDAD288C049D00@MAIL1.polartel.local>	<AANLkTi=UKewjV-B1tSKYSKT-O16VoysXz1uD=mDBDAhQ@mail.gmail.com>	<009e01cb66ee$e20a0c30$a61e2490$@dodecatec.com>
	<AANLkTinrWsnOq3gdhPKyWTVX36tGiopB9g9XkgkhGOLX@mail.gmail.com>
Message-ID: <009f01cb66f4$01077370$03165a50$@dodecatec.com>

>From: Christopher Morrow [mailto:christopher.morrow at gmail.com]
>Sent: Friday, October 08, 2010 9:59 AM
>I took 'experiment' as 'I put my things in a "lab" to see how they'd work
and work
>out bugs'
>
>so renumbering, or a full deployment (with a numbering plan and such)
doesn't
>seem to be a problem there. I suspect a /32 is probably NOT enough for most
ISP-
>type folks anyway, so just assigning a random /32 isn't super helpful...
>
>-chris

As someone else pointed out, however, assigning a random /32 doesn't put
those ISPs in any worse situation than they were in to begin with.  They'd
just have to come to ARIN and ask for a bigger block, which should be as
easy as it would have been for them to get a block that big in the first
place.

For end users, however, assigning a /32 is helpful, because it accomplishes
a few things:
1) It gets them v6 space to hurry up and get rolling (or not, if they just
let it expire, in which case it hurts nobody).
2) It's a large enough block that one can actually multi-home with it.
3) It doesn't waste that much space - especially if those allocations are
returned upon inaction by the assignees.


As an alternative/enhancement to this idea, what if fees for IPv4
allocations were to become contingent on at least having a v6 allocation?
For example, state that v4 fees will double for all organizations that do
not at least have a v6 block allocated.  Having the blocks (or being forced
to pay for NOT having them) would, I imagine, encourage people to start
using it.
I'm in support of ramping v4 fees up, anyway, as an extra encouragement to
move the heck on, but that's been discussed before, I believe.

-Brandon




From bill at herrin.us  Fri Oct  8 10:36:40 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 8 Oct 2010 10:36:40 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <009e01cb66ee$e20a0c30$a61e2490$@dodecatec.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>
	<8695009A81378E48879980039EEDAD288C049D00@MAIL1.polartel.local>
	<AANLkTi=UKewjV-B1tSKYSKT-O16VoysXz1uD=mDBDAhQ@mail.gmail.com>
	<009e01cb66ee$e20a0c30$a61e2490$@dodecatec.com>
Message-ID: <AANLkTin1VFtkew3FR+-nsw5KQMricvq1jr=Y3h4SedoP@mail.gmail.com>

On Fri, Oct 8, 2010 at 9:44 AM, Brandon Thetford <brandon at dodecatec.com> wrote:
>>can I point you (and these netadmins) at tunnelbroker.net? mr leber runs a
> very nice service, with your ASN (or not) you can get a /48 routed down a
> tunnel to you for this very purpose.
>
> Yes, but this also comes with the need to renumber once you finally get a
> "real" allocation, down the line. ?That alone may be enough to scare some
> off until an alternative, more permanent solution is available.

Tunnels are nifty. I learned a great deal about IPv6 using tunnels.
Thank you Hurricane Electric.

Now I'm done with tunnels. I'll start my for-real IPv6 deployment once
I have my for-real addresses.

Don't kid yourselves. The other existing Origin ASes will start their
for-real IPv6 deployments only after obtaining registry addresses as
well.


On Fri, Oct 8, 2010 at 9:58 AM, Christopher Morrow
<christopher.morrow at gmail.com> wrote:
> I suspect a /32 is probably NOT
> enough for most ISP-type folks anyway, so just assigning a random /32
> isn't super helpful...

Chris,

With the new tech out there like 6rd, what's your best guess as to
what size a preemptive ISP allocation should be for those 2661
ARIN-region ISPs (75%) that haven't yet gotten their IPv6 allocations?

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 schiller at uu.net  Fri Oct  8 10:39:35 2010
From: schiller at uu.net (Jason Schiller)
Date: Fri, 08 Oct 2010 10:39:35 -0400 (EDT)
Subject: [arin-ppml] early experimenter /32 catch-22
In-Reply-To: <AANLkTikO-uTBjEOJQsPHSiM45ZyYUAGzTJ_3LSCDzZtr@mail.gmail.com>
References: <AANLkTinjK4eZLQdFyLQdzU-RD=MPL66nD5R3RO4qzcjb@mail.gmail.com>
	<C8D39D08.C7C9%ggiesen@akn.ca>
	<AANLkTikP7db28wR5Dh0__PEn_XGaN7R_nJUjeAJ-fZ-_@mail.gmail.com>
	<20101008133841.GD10509@shell02.cell.sv2.tellme.com>
	<AANLkTikO-uTBjEOJQsPHSiM45ZyYUAGzTJ_3LSCDzZtr@mail.gmail.com>
Message-ID: <alpine.GSO.2.00.1010081033160.21655@peermon.argfrp.us.uu.net>

On Fri, 8 Oct 2010, Christopher Morrow wrote:

|On Fri, Oct 8, 2010 at 9:38 AM, David Williamson <dlw+arin at tellme.com> wrote:
|> On Thu, Oct 07, 2010 at 04:08:37PM -0400, Christopher Morrow wrote:
|>
|>> (you can't guarantee longer prefixes than a /32 get global
|>> reachability... so subnetting the current allocation isn't feasible)
|>
|> Is that really true? ?Would someone fess up about current routing
|
|I know of a case (solved by announcing the /32 aggregate) of this, yes.
|('hello docs.python.org!')
|
|> practice? ?We definitely accept longer prefixes, as we only have a /45,
|> and we only advertise /48s. ?Of course, that's in the PI block.
|
|sure, so in the PI ranges it seems most places (save vzb?) accept to
|/48. In the other allocation sets you can get to /32 but not often
|very much further (for full reachability).

AS701 accepts and sends PI and PA /48s to Peers for about 8 months now.

Seems most (not all) folks I talk with accept PI /48s, and slightly better 
than half accpet PA /48s.  Renysis says it PA /48 reachability is much 
worse than my experience.  (See the NANOG prior to the previous)  

__Jason

|
|-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.
|
|----------------------------------------------------------------------
|This message was created by the sender using your @mci.com address.  If you wish to continue to receive messages from this sender, please respond informing them to use your @verizonbusiness.com email address.
|
|The mci.com email domain will be decommissioned during the first quarter of 2011.  Please inform sender to use your @verizonbusiness.com address, if you desire to continue to receive messages from them.
|
|Thank You
|
|Verizon Business Messaging
|


From christopher.morrow at gmail.com  Fri Oct  8 11:09:15 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Fri, 8 Oct 2010 11:09:15 -0400
Subject: [arin-ppml] early experimenter /32 catch-22
In-Reply-To: <alpine.GSO.2.00.1010081033160.21655@peermon.argfrp.us.uu.net>
References: <AANLkTinjK4eZLQdFyLQdzU-RD=MPL66nD5R3RO4qzcjb@mail.gmail.com>
	<C8D39D08.C7C9%ggiesen@akn.ca>
	<AANLkTikP7db28wR5Dh0__PEn_XGaN7R_nJUjeAJ-fZ-_@mail.gmail.com>
	<20101008133841.GD10509@shell02.cell.sv2.tellme.com>
	<AANLkTikO-uTBjEOJQsPHSiM45ZyYUAGzTJ_3LSCDzZtr@mail.gmail.com>
	<alpine.GSO.2.00.1010081033160.21655@peermon.argfrp.us.uu.net>
Message-ID: <AANLkTikYdBfa6QU+er2bwhCbFf2PxEEDY28ACzqku+vM@mail.gmail.com>

On Fri, Oct 8, 2010 at 10:39 AM, Jason Schiller <schiller at uu.net> wrote:
> On Fri, 8 Oct 2010, Christopher Morrow wrote:
>
> |On Fri, Oct 8, 2010 at 9:38 AM, David Williamson <dlw+arin at tellme.com> wrote:
> |> On Thu, Oct 07, 2010 at 04:08:37PM -0400, Christopher Morrow wrote:
> |>
> |>> (you can't guarantee longer prefixes than a /32 get global
> |>> reachability... so subnetting the current allocation isn't feasible)
> |>
> |> Is that really true? ?Would someone fess up about current routing
> |
> |I know of a case (solved by announcing the /32 aggregate) of this, yes.
> |('hello docs.python.org!')
> |
> |> practice? ?We definitely accept longer prefixes, as we only have a /45,
> |> and we only advertise /48s. ?Of course, that's in the PI block.
> |
> |sure, so in the PI ranges it seems most places (save vzb?) accept to
> |/48. In the other allocation sets you can get to /32 but not often
> |very much further (for full reachability).
>
> AS701 accepts and sends PI and PA /48s to Peers for about 8 months now.

awesome, thanks for accepting my bribe. (note on the list)

> Seems most (not all) folks I talk with accept PI /48s, and slightly better
> than half accpet PA /48s. ?Renysis says it PA /48 reachability is much
> worse than my experience. ?(See the NANOG prior to the previous)

yup, it seems at least in some adhoc looking that PA /48's are not
always reachable without a covering route.

-chris


From ptimmins at clearrate.com  Fri Oct  8 11:10:04 2010
From: ptimmins at clearrate.com (Paul G. Timmins)
Date: Fri, 8 Oct 2010 15:10:04 +0000
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTin1VFtkew3FR+-nsw5KQMricvq1jr=Y3h4SedoP@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>
	<8695009A81378E48879980039EEDAD288C049D00@MAIL1.polartel.local>
	<AANLkTi=UKewjV-B1tSKYSKT-O16VoysXz1uD=mDBDAhQ@mail.gmail.com>
	<009e01cb66ee$e20a0c30$a61e2490$@dodecatec.com>
	<AANLkTin1VFtkew3FR+-nsw5KQMricvq1jr=Y3h4SedoP@mail.gmail.com>
Message-ID: <DD9D6CFA501E424DB214385CBF643C031CF2E3C0@exchange1.corp.clearrate.net>



> > Yes, but this also comes with the need to renumber once you finally
> get a
> > "real" allocation, down the line. ?That alone may be enough to scare
> some
> > off until an alternative, more permanent solution is available.
> 
> Tunnels are nifty. I learned a great deal about IPv6 using tunnels.
> Thank you Hurricane Electric.
> 
> Now I'm done with tunnels. I'll start my for-real IPv6 deployment once
> I have my for-real addresses.
> 
> Don't kid yourselves. The other existing Origin ASes will start their
> for-real IPv6 deployments only after obtaining registry addresses as
> well.

Upside is, HE will let you announce your own PI space to them over a tunnel too, so if you're without native options, or want a backup, there ya go.


From christopher.morrow at gmail.com  Fri Oct  8 11:20:04 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Fri, 8 Oct 2010 11:20:04 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTin1VFtkew3FR+-nsw5KQMricvq1jr=Y3h4SedoP@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>
	<8695009A81378E48879980039EEDAD288C049D00@MAIL1.polartel.local>
	<AANLkTi=UKewjV-B1tSKYSKT-O16VoysXz1uD=mDBDAhQ@mail.gmail.com>
	<009e01cb66ee$e20a0c30$a61e2490$@dodecatec.com>
	<AANLkTin1VFtkew3FR+-nsw5KQMricvq1jr=Y3h4SedoP@mail.gmail.com>
Message-ID: <AANLkTi=wn8E9ikBXKWF_S33_nYRs56Yo-W8rVTqP_8cf@mail.gmail.com>

On Fri, Oct 8, 2010 at 10:36 AM, William Herrin <bill at herrin.us> wrote:
> On Fri, Oct 8, 2010 at 9:44 AM, Brandon Thetford <brandon at dodecatec.com> wrote:
>>>can I point you (and these netadmins) at tunnelbroker.net? mr leber runs a
>> very nice service, with your ASN (or not) you can get a /48 routed down a
>> tunnel to you for this very purpose.
>>
>> Yes, but this also comes with the need to renumber once you finally get a
>> "real" allocation, down the line. ?That alone may be enough to scare some
>> off until an alternative, more permanent solution is available.
>
> Tunnels are nifty. I learned a great deal about IPv6 using tunnels.
> Thank you Hurricane Electric.
>
> Now I'm done with tunnels. I'll start my for-real IPv6 deployment once
> I have my for-real addresses.

according to the presos at ARIN this week... it's pretty simple to get
your for-real addresses. one would suggest a solid numbering plan, and
understanding of what technology you may need to employ for your
deployment are good to have in hand, though not required for initial
assignment.

Do you need 6rd because of standards/equipment failures in your chosen
deployment? Do you have other technology driven requirements?
Hopefully in your testing with the fun HE tunnels you've found out
what is possible and NOT possible in your build, yes?

> Don't kid yourselves. The other existing Origin ASes will start their
> for-real IPv6 deployments only after obtaining registry addresses as
> well.

of course, no one should deploy production services on tunneled
transport... well, free-tunnels :), and with the expectation that
renumbering will be required at some point in time.

> On Fri, Oct 8, 2010 at 9:58 AM, Christopher Morrow
> <christopher.morrow at gmail.com> wrote:
>> I suspect a /32 is probably NOT
>> enough for most ISP-type folks anyway, so just assigning a random /32
>> isn't super helpful...
>
> Chris,
>
> With the new tech out there like 6rd, what's your best guess as to
> what size a preemptive ISP allocation should be for those 2661
> ARIN-region ISPs (75%) that haven't yet gotten their IPv6 allocations?

that probably depends a LOT on what sort of ISP these are, and what
their deployment today looks like (for v4 services). For instance, are
they a:
  o hosting company (seems like fairly simple 'drop a v6 addr on your
gear, slap one toward the customer-ip, done!)
  o transit/business ISP (put ipv6 on your devices, offer prefixes to
your customers, done!)
  o consumer ISP (cable/dsl/ftth/etc - see deployment situations for issues)

For the consumer-isp folks... that's where 6rd seems to be necessary
(depending upon their deployment scenario today, of course, it's not
at all a forgone conclusion that 6rd is required in all of these
deployments)

So, in short, it depends a lot on what things the ISP is required to
do... prescribing an answer doesn't seem helpful :( (or so far the
'/32 for isps' answer hasn't been helpful)

-Chris


From cgrundemann at gmail.com  Fri Oct  8 12:00:54 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Fri, 8 Oct 2010 10:00:54 -0600
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
Message-ID: <AANLkTingLkZsMdyiQQJo8pz0h3DDBiTYd0gU9n7jTRhV@mail.gmail.com>

Problem Statement:
We have failed to deploy dual-stack in a meaningful way in time to
avoid transition problems

Objectives:
-1- Encourage IPv6 deployment prior to depletion
-2- Enable growth of IPv4 where IPv6 is being deployed
-3- Improve the utilization of IP addresses

High-Level Requirements:
-1- ARIN will only make allocations and assignments for networks that
have already deployed production IPv6
-2- Any IPv4 addresses received under this policy, must be deployed
along side of IPv6
-3- This policy will encourage deployment of IPv6 in existing IPv4-only networks

Rough Policy Text:
~ Requester defines classes in their network - only classes where IPv6
is in production qualify for IPv6
~ New addresses must be deployed on dual-stacked interfaces plus one
additional existing IPv4-only interface must be dual stacked, up to
80% of all interfaces.
~ The service that the address is used to provide must be fully IPv6
accessible (if you deploy an A record, you must also have a AAAA and
both must answer)
~ All end-sites must dual-stack all Internet facing services before
getting this space
~ For each down stream customer site where these addresses are
deployed, another pre-existing IPv4 only down stream site must also be
IPv6?enabled, up to 80% of the total customer base.


This is an emergency, let's get something together ASAP. All feedback
is extremely welcome and greatly appreciated; this problem is all of
ours. If you are still here in Atlanta come find me, Marty Hannigan
and/or Jason Schiller to discuss.

Thanks!
~Chris



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


From mpetach at netflight.com  Fri Oct  8 12:10:35 2010
From: mpetach at netflight.com (Matthew Petach)
Date: Fri, 8 Oct 2010 09:10:35 -0700
Subject: [arin-ppml] 2010.10.08 ARIN26 day 3 Friday morning notes
Message-ID: <AANLkTinFbKiS0Jw3V7xYYbp-HT2Qq9f+fB=F+KdpBgpe@mail.gmail.com>

Posting version 1.0 of Friday morning notes
chock full of typos still, doing it in a rush since
wireless is going down shortly.  Will clean up
stuffs when I find wireless again later.  ^_^;

http://kestrel3.netflight.com/2010.10.08-ARIN26-morning-notes.txt

Thanks everyone for a wonderful meeting!

Matt


From owen at delong.com  Fri Oct  8 12:36:30 2010
From: owen at delong.com (Owen DeLong)
Date: Fri, 8 Oct 2010 09:36:30 -0700
Subject: [arin-ppml] early experimenter /32 catch-22
In-Reply-To: <AANLkTikO-uTBjEOJQsPHSiM45ZyYUAGzTJ_3LSCDzZtr@mail.gmail.com>
References: <AANLkTinjK4eZLQdFyLQdzU-RD=MPL66nD5R3RO4qzcjb@mail.gmail.com>
	<C8D39D08.C7C9%ggiesen@akn.ca>
	<AANLkTikP7db28wR5Dh0__PEn_XGaN7R_nJUjeAJ-fZ-_@mail.gmail.com>
	<20101008133841.GD10509@shell02.cell.sv2.tellme.com>
	<AANLkTikO-uTBjEOJQsPHSiM45ZyYUAGzTJ_3LSCDzZtr@mail.gmail.com>
Message-ID: <B117B2A8-E2A0-404A-B0D8-C3ADAF5546CF@delong.com>


On Oct 8, 2010, at 6:55 AM, Christopher Morrow wrote:

> On Fri, Oct 8, 2010 at 9:38 AM, David Williamson <dlw+arin at tellme.com> wrote:
>> On Thu, Oct 07, 2010 at 04:08:37PM -0400, Christopher Morrow wrote:
>> 
>>> (you can't guarantee longer prefixes than a /32 get global
>>> reachability... so subnetting the current allocation isn't feasible)
>> 
>> Is that really true?  Would someone fess up about current routing
> 
> I know of a case (solved by announcing the /32 aggregate) of this, yes.
> ('hello docs.python.org!')
> 
>> practice?  We definitely accept longer prefixes, as we only have a /45,
>> and we only advertise /48s.  Of course, that's in the PI block.
> 
> sure, so in the PI ranges it seems most places (save vzb?) accept to
> /48. In the other allocation sets you can get to /32 but not often
> very much further (for full reachability).
> 
VZB does now accept /48s in the PI ranges.

Owen



From ggiesen at akn.ca  Fri Oct  8 12:28:00 2010
From: ggiesen at akn.ca (Gary Giesen)
Date: Fri, 8 Oct 2010 12:28:00 -0400
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <AANLkTingLkZsMdyiQQJo8pz0h3DDBiTYd0gU9n7jTRhV@mail.gmail.com>
Message-ID: <C8D4BDBC.C834%ggiesen@akn.ca>

Chris,

I have a couple questions:

1) What sort of mechanism are you going to use to verify IPv6 deployment?
While I believe service providers can turn up v6 relatively quickly (if
they haven't already done so), getting their customers turned up is
another thing...

2) Would you consider a change to allocation policy that would permit
non-multihomers to receive PI space? (I know a lot of people are going to
hate this). The rationale for this is that enterprise will be the last to
move to v6, and that the fear of not being able to get portable addresses
without multihoming or some sort of NAT will keep them from adopting.
Other multihoming mechanisms (such as SHIM6) have failed (and I believe
rightly so). This further incentivizes single-homed businesses to move to
v6.

GG


On 10-10-08 12:00 PM, "Chris Grundemann" <cgrundemann at gmail.com> wrote:

>Problem Statement:
>We have failed to deploy dual-stack in a meaningful way in time to
>avoid transition problems
>
>Objectives:
>-1- Encourage IPv6 deployment prior to depletion
>-2- Enable growth of IPv4 where IPv6 is being deployed
>-3- Improve the utilization of IP addresses
>
>High-Level Requirements:
>-1- ARIN will only make allocations and assignments for networks that
>have already deployed production IPv6
>-2- Any IPv4 addresses received under this policy, must be deployed
>along side of IPv6
>-3- This policy will encourage deployment of IPv6 in existing IPv4-only
>networks
>
>Rough Policy Text:
>~ Requester defines classes in their network - only classes where IPv6
>is in production qualify for IPv6
>~ New addresses must be deployed on dual-stacked interfaces plus one
>additional existing IPv4-only interface must be dual stacked, up to
>80% of all interfaces.
>~ The service that the address is used to provide must be fully IPv6
>accessible (if you deploy an A record, you must also have a AAAA and
>both must answer)
>~ All end-sites must dual-stack all Internet facing services before
>getting this space
>~ For each down stream customer site where these addresses are
>deployed, another pre-existing IPv4 only down stream site must also be
>IPv6 enabled, up to 80% of the total customer base.
>
>
>This is an emergency, let's get something together ASAP. All feedback
>is extremely welcome and greatly appreciated; this problem is all of
>ours. If you are still here in Atlanta come find me, Marty Hannigan
>and/or Jason Schiller to discuss.
>
>Thanks!
>~Chris
>
>
>
>-- 
>@ChrisGrundemann
>weblog.chrisgrundemann.com
>www.burningwiththebush.com
>www.coisoc.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 mpetach at netflight.com  Fri Oct  8 12:44:25 2010
From: mpetach at netflight.com (Matthew Petach)
Date: Fri, 8 Oct 2010 09:44:25 -0700
Subject: [arin-ppml] IPv6 Transition Policy (aka Rocky Beach)
Message-ID: <AANLkTi=Mu7NwyAC0s4BLwAuFRyQZPX9=RhBtZXVFNepk@mail.gmail.com>

On Fri, Oct 8, 2010 at 9:00 AM, Chris Grundemann <cgrundemann at gmail.com> wrote:
> Problem Statement:
> We have failed to deploy dual-stack in a meaningful way in time to
> avoid transition problems
>
> Objectives:
> -1- Encourage IPv6 deployment prior to depletion
> -2- Enable growth of IPv4 where IPv6 is being deployed
> -3- Improve the utilization of IP addresses
>
> High-Level Requirements:
> -1- ARIN will only make allocations and assignments for networks that
> have already deployed production IPv6

Including transfers, even if specified to a designated recipient.

> -2- Any IPv4 addresses received under this policy, must be deployed
> along side of IPv6
> -3- This policy will encourage deployment of IPv6 in existing IPv4-only networks
>
> Rough Policy Text:
> ~ Requester defines classes in their network - only classes where IPv6
> is in production qualify for IPv6

What the heck do you mean by a "class"?

> ~ New addresses must be deployed on dual-stacked interfaces plus one
> additional existing IPv4-only interface must be dual stacked, up to
> 80% of all interfaces.
> ~ The service that the address is used to provide must be fully IPv6
> accessible (if you deploy an A record, you must also have a AAAA and
> both must answer)

Obviously, ARIN can't check this before allocating the space; move
that to a review clause, not requirement for allocation.

> ~ All end-sites must dual-stack all Internet facing services before
> getting this space

you mean, all *existing* end-sites for that ISP?  Since you can't
very well be talking about new end-sites that will come on using
the new space they haven't gotten yet.

I think that clause is a non-starter for this proposal.  All it takes is
one customer not dual-stacking to shut the whole effort down.

> ~ For each down stream customer site where these addresses are
> deployed, another pre-existing IPv4 only down stream site must also be
> IPv6?enabled, up to 80% of the total customer base.
>
>
> This is an emergency, let's get something together ASAP. All feedback
> is extremely welcome and greatly appreciated; this problem is all of
> ours. If you are still here in Atlanta come find me, Marty Hannigan
> and/or Jason Schiller to discuss.
>
> Thanks!
> ~Chris

A worthy effort, Chris, but this is a bit too extreme.  We need to make
it more realistic, or it'll go nowhere.

More thoughts after I land, must head to airport now.

Matt


From ggiesen at akn.ca  Fri Oct  8 12:30:56 2010
From: ggiesen at akn.ca (Gary Giesen)
Date: Fri, 8 Oct 2010 12:30:56 -0400
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <AANLkTingLkZsMdyiQQJo8pz0h3DDBiTYd0gU9n7jTRhV@mail.gmail.com>
Message-ID: <C8D4BF65.C840%ggiesen@akn.ca>

My apologies for not reading through your entire policy text, but I think
the concern about being able to get customers moved still stands...

GG

On 10-10-08 12:00 PM, "Chris Grundemann" <cgrundemann at gmail.com> wrote:

>Problem Statement:
>We have failed to deploy dual-stack in a meaningful way in time to
>avoid transition problems
>
>Objectives:
>-1- Encourage IPv6 deployment prior to depletion
>-2- Enable growth of IPv4 where IPv6 is being deployed
>-3- Improve the utilization of IP addresses
>
>High-Level Requirements:
>-1- ARIN will only make allocations and assignments for networks that
>have already deployed production IPv6
>-2- Any IPv4 addresses received under this policy, must be deployed
>along side of IPv6
>-3- This policy will encourage deployment of IPv6 in existing IPv4-only
>networks
>
>Rough Policy Text:
>~ Requester defines classes in their network - only classes where IPv6
>is in production qualify for IPv6
>~ New addresses must be deployed on dual-stacked interfaces plus one
>additional existing IPv4-only interface must be dual stacked, up to
>80% of all interfaces.
>~ The service that the address is used to provide must be fully IPv6
>accessible (if you deploy an A record, you must also have a AAAA and
>both must answer)
>~ All end-sites must dual-stack all Internet facing services before
>getting this space
>~ For each down stream customer site where these addresses are
>deployed, another pre-existing IPv4 only down stream site must also be
>IPv6 enabled, up to 80% of the total customer base.
>
>
>This is an emergency, let's get something together ASAP. All feedback
>is extremely welcome and greatly appreciated; this problem is all of
>ours. If you are still here in Atlanta come find me, Marty Hannigan
>and/or Jason Schiller to discuss.
>
>Thanks!
>~Chris
>
>
>
>-- 
>@ChrisGrundemann
>weblog.chrisgrundemann.com
>www.burningwiththebush.com
>www.coisoc.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 bensons at queuefull.net  Fri Oct  8 13:01:04 2010
From: bensons at queuefull.net (Benson Schliesser)
Date: Fri, 8 Oct 2010 12:01:04 -0500
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <AANLkTingLkZsMdyiQQJo8pz0h3DDBiTYd0gU9n7jTRhV@mail.gmail.com>
References: <AANLkTingLkZsMdyiQQJo8pz0h3DDBiTYd0gU9n7jTRhV@mail.gmail.com>
Message-ID: <D9955449-C756-498B-82FC-F35DF5797E62@queuefull.net>

I would support something along these lines, but with a few caveats.

For instance, how would a Service Provider be considered in compliance if their customers don't deploy IPv6?  I think this needs to be spelled out such that the provider doesn't have their business harmed by 3rd party non-compliance with the rule.

What about loop-holes in which v4 numbers get moved around, to make new requests possible... would we effectively have to allocate numbers to org+class, instead of orgs, to patch up this loophole?  That doesn't make much sense to me.

Your text doesn't suggest this, but it should be explicit that v4 addresses can be used on transition platforms (LSN etc) and aren't restricted to dual-stack deployment to hosts.

I'm sure I'm missing something, but these are a start...

Cheers,
-Benson



On 8 Oct 10, at 11:00 AM, Chris Grundemann wrote:

> Problem Statement:
> We have failed to deploy dual-stack in a meaningful way in time to
> avoid transition problems
> 
> Objectives:
> -1- Encourage IPv6 deployment prior to depletion
> -2- Enable growth of IPv4 where IPv6 is being deployed
> -3- Improve the utilization of IP addresses
> 
> High-Level Requirements:
> -1- ARIN will only make allocations and assignments for networks that
> have already deployed production IPv6
> -2- Any IPv4 addresses received under this policy, must be deployed
> along side of IPv6
> -3- This policy will encourage deployment of IPv6 in existing IPv4-only networks
> 
> Rough Policy Text:
> ~ Requester defines classes in their network - only classes where IPv6
> is in production qualify for IPv6
> ~ New addresses must be deployed on dual-stacked interfaces plus one
> additional existing IPv4-only interface must be dual stacked, up to
> 80% of all interfaces.
> ~ The service that the address is used to provide must be fully IPv6
> accessible (if you deploy an A record, you must also have a AAAA and
> both must answer)
> ~ All end-sites must dual-stack all Internet facing services before
> getting this space
> ~ For each down stream customer site where these addresses are
> deployed, another pre-existing IPv4 only down stream site must also be
> IPv6 enabled, up to 80% of the total customer base.
> 
> 
> This is an emergency, let's get something together ASAP. All feedback
> is extremely welcome and greatly appreciated; this problem is all of
> ours. If you are still here in Atlanta come find me, Marty Hannigan
> and/or Jason Schiller to discuss.
> 
> Thanks!
> ~Chris
> 
> 
> 
> -- 
> @ChrisGrundemann
> weblog.chrisgrundemann.com
> www.burningwiththebush.com
> www.coisoc.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 jmaimon at chl.com  Fri Oct  8 13:04:58 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Fri, 08 Oct 2010 13:04:58 -0400
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <AANLkTingLkZsMdyiQQJo8pz0h3DDBiTYd0gU9n7jTRhV@mail.gmail.com>
References: <AANLkTingLkZsMdyiQQJo8pz0h3DDBiTYd0gU9n7jTRhV@mail.gmail.com>
Message-ID: <4CAF4F3A.30703@chl.com>

Chris,

Your pill needs more sugar coating.

I could only be comfortable with something like this were it to be 
accompanied by a much larger framework for reserved pools of addresses, 
address pools which had other qualifiers for eligibility, such as new 
organizations, organizations with no existing or seriously limited 
resources, one-shot open to anybody pool, and similar.

I also would like for such a proposal to encompass more or the entirety 
of the last /8 and to be refilled by returns/revokes if/when they occur.

A proposal that pits ARIN dictates against needs and desires of its 
members is not good policy. A balance must be struck. Rewards need to be 
offered to offset punishments.

Impedance mismatches between policy IPv6 dictates and 
business/self-interest goals will cause real issues and resentments.

Trying to force people to do things they would not do otherwise is a 
risky proposition.

Something that casts ARIN as the real bad guy would be enough for me not 
to support a proposal even were it to have the net positive benefit of 
locking down more resources at a lower burn rate.

Thanks,

Joe



Chris Grundemann wrote:
> Problem Statement:
> We have failed to deploy dual-stack in a meaningful way in time to
> avoid transition problems
>
> Objectives:
> -1- Encourage IPv6 deployment prior to depletion
> -2- Enable growth of IPv4 where IPv6 is being deployed
> -3- Improve the utilization of IP addresses
>
> High-Level Requirements:
> -1- ARIN will only make allocations and assignments for networks that
> have already deployed production IPv6
> -2- Any IPv4 addresses received under this policy, must be deployed
> along side of IPv6
> -3- This policy will encourage deployment of IPv6 in existing IPv4-only networks
>
> Rough Policy Text:
> ~ Requester defines classes in their network - only classes where IPv6
> is in production qualify for IPv6
> ~ New addresses must be deployed on dual-stacked interfaces plus one
> additional existing IPv4-only interface must be dual stacked, up to
> 80% of all interfaces.
> ~ The service that the address is used to provide must be fully IPv6
> accessible (if you deploy an A record, you must also have a AAAA and
> both must answer)
> ~ All end-sites must dual-stack all Internet facing services before
> getting this space
> ~ For each down stream customer site where these addresses are
> deployed, another pre-existing IPv4 only down stream site must also be
> IPv6 enabled, up to 80% of the total customer base.
>
>
> This is an emergency, let's get something together ASAP. All feedback
> is extremely welcome and greatly appreciated; this problem is all of
> ours. If you are still here in Atlanta come find me, Marty Hannigan
> and/or Jason Schiller to discuss.
>
> Thanks!
> ~Chris
>
>
>


From brandon at dodecatec.com  Fri Oct  8 13:16:53 2010
From: brandon at dodecatec.com (Brandon Thetford)
Date: Fri, 8 Oct 2010 13:16:53 -0400
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <4CAF4F3A.30703@chl.com>
References: <AANLkTingLkZsMdyiQQJo8pz0h3DDBiTYd0gU9n7jTRhV@mail.gmail.com>
	<4CAF4F3A.30703@chl.com>
Message-ID: <00e001cb670c$9b240a50$d16c1ef0$@dodecatec.com>

>From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>
>I could only be comfortable with something like this were it to be
accompanied
>by a much larger framework for reserved pools of addresses, address pools
which
>had other qualifiers for eligibility, such as new organizations,
organizations with
>no existing or seriously limited resources, one-shot open to anybody pool,
and
>similar.
>

Agree.

>I also would like for such a proposal to encompass more or the entirety of
the
>last /8 and to be refilled by returns/revokes if/when they occur.
>

Agree, partially.  The reservation I have about that is that it would simply
postpone the same issue.
What happens when that /8 is used up?  We'll be in the same boat, but no
longer have a buffer.
I think I'd rather see it done with half of that space or something like
that.

>A proposal that pits ARIN dictates against needs and desires of its members
is not
>good policy. A balance must be struck. Rewards need to be offered to offset
>punishments.
>
>Impedance mismatches between policy IPv6 dictates and
business/self-interest
>goals will cause real issues and resentments.
>

As much as I hate to, I agree here, also.  It's the reason we're in this
situation now - businesses have their needs, and until a few months from
now, IPv6 isn't one of them (so they think).




From marty at akamai.com  Fri Oct  8 17:07:12 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Fri, 8 Oct 2010 17:07:12 -0400
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <4CAF4F3A.30703@chl.com>
Message-ID: <C8D4FF0B.12B23%marty@akamai.com>





[ clip ]

> 
> I could only be comfortable with something like this were it to be
> accompanied by a much larger framework for reserved pools of addresses,
> address pools which had other qualifiers for eligibility, such as new
> organizations, organizations with no existing or seriously limited
> resources, one-shot open to anybody pool, and similar.

Note, that's what the last proposal had and one of the major themes about
it's failure was the classes and complexities.

> I also would like for such a proposal to encompass more or the entirety
> of the last /8 and to be refilled by returns/revokes if/when they occur.

I think that this might be a half-way decent idea and I believe, but I may
be recalling wrong, that this is the intent.



>From LGA, Best,

-M<



From fred at cisco.com  Fri Oct  8 21:12:08 2010
From: fred at cisco.com (Fred Baker)
Date: Fri, 8 Oct 2010 18:12:08 -0700
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <C8D4BDBC.C834%ggiesen@akn.ca>
References: <C8D4BDBC.C834%ggiesen@akn.ca>
Message-ID: <0FC11925-7D95-48B2-BEB7-E86B3AC062F5@cisco.com>


On Oct 8, 2010, at 9:28 AM, Gary Giesen wrote:

> 1) What sort of mechanism are you going to use to verify IPv6 deployment? While I believe service providers can turn up v6 relatively quickly (if they haven't already done so), getting their customers turned up is another thing...

That is most definitely the case on both counts.

That said, let me throw a hypothetical question to you. Suppose that a hypothetical ISP had 20,000,000 residential/SOHO/SMB customers and a /32 prefix, and worked out a plan to address routers in its network using a ULA and distribute the /32 as some combination of /48's, /52's, and /56's to its customers. It would be in a pretty good position to get some more addresses, I should imagine another /32 - and with any luck, do so by shortening its existing /32 to a /31 or shorter. Were I king (which I note I'm not) I would be able to do the math and say "they will need them whenever they do the deployment" without a lot more proof. My question would not be "so roll them out and renumber your network when you get to a certain deployment level"; my question would be "so show me that with this plan you have deployment in progress, implying that if I give you these addresses now you won't have to renumber your network when you get to that point".

To my admittedly small mind, the objective here is to enable ISPs to use their resources to develop scalable, manageable IPv6 networks. It seems to me like working with them to accomplish that makes some sense. Yes, one needs to verify. But I should think that every ARIN member has an appropriate NDA, and ARIN itself can count the IPv4 address space allocated to the member, to support the discussion.

From bill at herrin.us  Fri Oct  8 21:24:36 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 8 Oct 2010 21:24:36 -0400
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <AANLkTingLkZsMdyiQQJo8pz0h3DDBiTYd0gU9n7jTRhV@mail.gmail.com>
References: <AANLkTingLkZsMdyiQQJo8pz0h3DDBiTYd0gU9n7jTRhV@mail.gmail.com>
Message-ID: <AANLkTim=+xX8BWg4dHh9hKN537RQxUbTMduxbir_z7za@mail.gmail.com>

On Fri, Oct 8, 2010 at 12:00 PM, Chris Grundemann <cgrundemann at gmail.com> wrote:
> Rough Policy Text:
> ~ Requester defines classes in their network - only classes where IPv6
> is in production qualify for IPv6
> ~ New addresses must be deployed on dual-stacked interfaces plus one
> additional existing IPv4-only interface must be dual stacked, up to
> 80% of all interfaces.
> ~ The service that the address is used to provide must be fully IPv6
> accessible (if you deploy an A record, you must also have a AAAA and
> both must answer)
> ~ All end-sites must dual-stack all Internet facing services before
> getting this space
> ~ For each down stream customer site where these addresses are
> deployed, another pre-existing IPv4 only down stream site must also be
> IPv6?enabled, up to 80% of the total customer base.

Chris,

Suggestion: keep it simple, keep it grounded.

"To qualify for additional IPv4 addresses, the requesting organization
must first deploy AAAA records for its most used customer-facing web
site and maintain IPv6 connectivity to it from the public Internet."

Or something similarly simple and terse. I'm not sure there's time to
get something like this through before depletion consumes the
addresses you would preserve, but I think you'll have a better chance
with something brief and readily accomplishable that kicks the
requester to start moving on IPv6.

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 joelja at bogus.com  Fri Oct  8 15:17:59 2010
From: joelja at bogus.com (Joel Jaeggli)
Date: Fri, 08 Oct 2010 15:17:59 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <4CAE4A32.2020006@matthew.at>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>	<AANLkTikoCZiE9JuOz0kbOYmZzO+Erv072=OyDyw7pq_7@mail.gmail.com>
	<4CAE4A32.2020006@matthew.at>
Message-ID: <4CAF6E67.7070602@bogus.com>

On 10/7/10 6:31 PM, Matthew Kaufman wrote:
>  On 10/7/2010 1:53 PM, Andrew Koch wrote:
>>
>> While I like the idea of making it easy as possible to get IPv6 space,
>> there needs to be some planning and responsibility behind getting this
>> space.
>>
> Why? There's lots of it.
> 
> I have an even easier idea: Ignore what's visible in BGP and simply
> direct IANA to allocate a portion of IPv6 space such that:
> <prefix>:<ASN>/<size>.

yeah that won't result in a bunch of non-aggregatable prefixes or
orphaned ip blocks or anything...

Somewhere Geoff has a slide of the rate at which ASNs age out of the
network.


From joelja at bogus.com  Fri Oct  8 15:26:46 2010
From: joelja at bogus.com (Joel Jaeggli)
Date: Fri, 08 Oct 2010 15:26:46 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B423937811F63@EMV01-UKBR.domain1.systemhost.net>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>	<AANLkTikoCZiE9JuOz0kbOYmZzO+Erv072=OyDyw7pq_7@mail.gmail.com>	<4CAE4A32.2020006@matthew.at>
	<0F29D1BA57992E4CAB5AD2C9AE7B423937811F63@EMV01-UKBR.domain1.systemhost.net>
Message-ID: <4CAF7076.4000802@bogus.com>

On 10/8/10 3:33 AM, michael.dillon at bt.com wrote:
>> I have an even easier idea: Ignore what's visible in BGP and simply
>> direct IANA to allocate a portion of IPv6 space such that:
>> <prefix>:<ASN>/<size>.
> 
> Interesting idea but the IETF is over that way ---->

you don't need to go to 6man to know that's a bad idea.

> And be prepared for people to drag up 10 year old ideas that you
> have never heard of and tell you that "we already rejected that idea".
> 
> Unfortunately, ARIN cannot direct the IANA to do anything other than
> change the allocation process for blocks which the IETF has already
> directed IANA to allocate via the RIRs.
> 
> --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 joelja at bogus.com  Fri Oct  8 14:32:09 2010
From: joelja at bogus.com (Joel Jaeggli)
Date: Fri, 08 Oct 2010 14:32:09 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <CD7991F9-FA34-47CB-B2E4-6A158CE86816@delong.com>
References: <4CAE19E1.308@chl.com>	<5DF50066-0402-4474-AF92-52ECFD90EF90@delong.com>	<AANLkTikZggx_9H8z+N9YWwUVJtdKf9VTeK3e7dBiP7W3@mail.gmail.com>
	<CD7991F9-FA34-47CB-B2E4-6A158CE86816@delong.com>
Message-ID: <4CAF63A9.8050408@bogus.com>

On 10/7/10 3:50 PM, Owen DeLong wrote:
> On Oct 7, 2010, at 12:45 PM, Christopher Morrow wrote:
>>> 1.      If it becomes a permanent deployment, it will seriously degrade end user
>>>        capabilities and stifle innovation and place unnecessary limits on future
>>
>> more than not having ipv6 will? more than nat/nat/nat will? I'm not a
>> particularly large fan of 6rd either, but... it does give the
>> capability to get v6 to end users (in a decent quality) and today.
>>
> Less than those, but, more than native IPv6.

in either the native case or the 6rd case you're jacking up the cpe so
the difference is in the access network.

>> Talking to Mark some, and Lorenzo, and looked at ietf work ongoing to
>> bring operations tools/capabilities they need to deploy v6 in a
>> congruent manner as v4.... waiting for this will take quite a long
>> while (2-3 years at best for the standards work to finish, never mind
>> implementations).
>>
> Hence my suggestion that we provide for 6rd, but, require that it be
> something we can deprecate later.
> 
>> To be clear, I'd support neither -9 nor -12, but a fix for -12 that
>> removed all of the 'transition technology' wording and focused on
>> 'subsequent allocation' alone.
>>
> Yeah, I can't support that without safeguards to make sure that we
> can deprecate 6rd.

if something gets cooked into the network for perhaps a decade it's not
coming out easily. the ability to deprecate it is tied either to it's
nature as a short-term bandaid, which I'm not sure I buy or it's failure
in the marketplace. I see no reason to presuppose the latter.

> 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 bill at herrin.us  Fri Oct  8 22:28:16 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 8 Oct 2010 22:28:16 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTi=wn8E9ikBXKWF_S33_nYRs56Yo-W8rVTqP_8cf@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>
	<8695009A81378E48879980039EEDAD288C049D00@MAIL1.polartel.local>
	<AANLkTi=UKewjV-B1tSKYSKT-O16VoysXz1uD=mDBDAhQ@mail.gmail.com>
	<009e01cb66ee$e20a0c30$a61e2490$@dodecatec.com>
	<AANLkTin1VFtkew3FR+-nsw5KQMricvq1jr=Y3h4SedoP@mail.gmail.com>
	<AANLkTi=wn8E9ikBXKWF_S33_nYRs56Yo-W8rVTqP_8cf@mail.gmail.com>
Message-ID: <AANLkTinc4vY5ksLk-w1ssTdLOriMjFEvnC0rpiBHL7UC@mail.gmail.com>

On Fri, Oct 8, 2010 at 11:20 AM, Christopher Morrow
<christopher.morrow at gmail.com> wrote:
> according to the presos at ARIN this week... it's pretty simple to get
> your for-real addresses. one would suggest a solid numbering plan, and
> understanding of what technology you may need to employ for your
> deployment are good to have in hand, though not required for initial
> assignment.

Sure. Getting IPv6 addresses is easy. Like getting a vaccine. You pay
for it, get pricked, endure and it's all good.

But do you only want to assure that -your- kids to get the vaccine? Or
do you want -everybody- to get the vaccine so that the disease itself
dies out and doesn't haunt you again year after year? If we've truly
learned how to beat the disease, is it not worth it as a matter of
public policy to preemptively provide everybody with the vaccine?

We beat smallpox. Let's beat IPv4. ;-)


>> With the new tech out there like 6rd, what's your best guess as to
>> what size a preemptive ISP allocation should be for those 2661
>> ARIN-region ISPs (75%) that haven't yet gotten their IPv6 allocations?
>
> that probably depends a LOT on what sort of ISP these are, and what
> their deployment today looks like (for v4 services). For instance, are
> they a:
> ?o hosting company (seems like fairly simple 'drop a v6 addr on your
> gear, slap one toward the customer-ip, done!)
> ?o transit/business ISP (put ipv6 on your devices, offer prefixes to
> your customers, done!)
> ?o consumer ISP (cable/dsl/ftth/etc - see deployment situations for issues)

Do you have any ideas on how to tell the difference in a relatively
automated manner? I know how to test for whether you hold an
allocation, but I'm not sure how to test for what kind of allocation
holder you are.

If we can't tell the difference, does that negate the value in
preemptive allocation? If it doesn't then let's make an educated guess
as to what size is likely to be useful, recognizing that anyone who
finds they received the wrong size is in no worse shape than they are
without preemptive allocation.

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  Fri Oct  8 23:01:23 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Fri, 8 Oct 2010 23:01:23 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CAF63A9.8050408@bogus.com>
References: <4CAE19E1.308@chl.com>
	<5DF50066-0402-4474-AF92-52ECFD90EF90@delong.com>
	<AANLkTikZggx_9H8z+N9YWwUVJtdKf9VTeK3e7dBiP7W3@mail.gmail.com>
	<CD7991F9-FA34-47CB-B2E4-6A158CE86816@delong.com>
	<4CAF63A9.8050408@bogus.com>
Message-ID: <AANLkTimN18bazayFxjjbCefEN6p2x9kLJO0M7hat=U29@mail.gmail.com>

On Fri, Oct 8, 2010 at 2:32 PM, Joel Jaeggli <joelja at bogus.com> wrote:
>> Yeah, I can't support that without safeguards to make sure that we
>> can deprecate 6rd.
>
> if something gets cooked into the network for perhaps a decade it's not
> coming out easily. the ability to deprecate it is tied either to it's
> nature as a short-term bandaid, which I'm not sure I buy or it's failure
> in the marketplace. I see no reason to presuppose the latter.

I agree with Joel here, I think once 6rd goes in... if the support is
in linecards/interfaces and CPE and 'low cost' to the devices in
question (happens in hardware on the ingress interface of the SP
router, for instance) then... There's not much incentive to migrate
away from it. I can see it staying deployed for a very long time.
(unless of course there are no ipv4 numbers to be used in the ISP...)

-Chris


From christopher.morrow at gmail.com  Fri Oct  8 23:16:04 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Fri, 8 Oct 2010 23:16:04 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTinc4vY5ksLk-w1ssTdLOriMjFEvnC0rpiBHL7UC@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>
	<8695009A81378E48879980039EEDAD288C049D00@MAIL1.polartel.local>
	<AANLkTi=UKewjV-B1tSKYSKT-O16VoysXz1uD=mDBDAhQ@mail.gmail.com>
	<009e01cb66ee$e20a0c30$a61e2490$@dodecatec.com>
	<AANLkTin1VFtkew3FR+-nsw5KQMricvq1jr=Y3h4SedoP@mail.gmail.com>
	<AANLkTi=wn8E9ikBXKWF_S33_nYRs56Yo-W8rVTqP_8cf@mail.gmail.com>
	<AANLkTinc4vY5ksLk-w1ssTdLOriMjFEvnC0rpiBHL7UC@mail.gmail.com>
Message-ID: <AANLkTik60qf1-KoYU42Y1-LzhjGDjC+qB1RK4yrCy9b3@mail.gmail.com>

On Fri, Oct 8, 2010 at 10:28 PM, William Herrin <bill at herrin.us> wrote:
> On Fri, Oct 8, 2010 at 11:20 AM, Christopher Morrow
> <christopher.morrow at gmail.com> wrote:
>> according to the presos at ARIN this week... it's pretty simple to get
>> your for-real addresses. one would suggest a solid numbering plan, and
>> understanding of what technology you may need to employ for your
>> deployment are good to have in hand, though not required for initial
>> assignment.
>
> Sure. Getting IPv6 addresses is easy. Like getting a vaccine. You pay
> for it, get pricked, endure and it's all good.
>
> But do you only want to assure that -your- kids to get the vaccine? Or
> do you want -everybody- to get the vaccine so that the disease itself
> dies out and doesn't haunt you again year after year? If we've truly
> learned how to beat the disease, is it not worth it as a matter of
> public policy to preemptively provide everybody with the vaccine?
>
> We beat smallpox. Let's beat IPv4. ;-)

I'm not sure I buy the 'beat ipv4' ... I have a very good feeling that
it will outlive me in the live network. (albeit with dwindling traffic
rates)

>
>>> With the new tech out there like 6rd, what's your best guess as to
>>> what size a preemptive ISP allocation should be for those 2661
>>> ARIN-region ISPs (75%) that haven't yet gotten their IPv6 allocations?
>>
>> that probably depends a LOT on what sort of ISP these are, and what
>> their deployment today looks like (for v4 services). For instance, are
>> they a:
>> ?o hosting company (seems like fairly simple 'drop a v6 addr on your
>> gear, slap one toward the customer-ip, done!)
>> ?o transit/business ISP (put ipv6 on your devices, offer prefixes to
>> your customers, done!)
>> ?o consumer ISP (cable/dsl/ftth/etc - see deployment situations for issues)
>
> Do you have any ideas on how to tell the difference in a relatively
> automated manner? I know how to test for whether you hold an

nope, but if the provider is prompted at next-interaction-with-RIR ...
it gets simpler, eh? Heck there's probably even a case to be made for
something like (taking my fav past job as an example):

701 - <some sized allocation, a /27 heather justified I believe)
702/3 - ditto to above
11486 (hosting) - one /32 per datacenter. It's plausible that there
could be 30-40k customers per DC (12 DC's in the US or so... so /28).
19262 - at 8.5m (and growing) customers - as much as a /24 for native,
plus probably a /24 for 6rd-ish things (this is with a /48 for native
customers, with a /56 it's far less, though regionalized /32's seems
reasonable still so about a /28)
vzw - 60m customers and growing - strictly on the /56 allocations 1 /28.

for the verizon companies (not counting private networks, one I know
of probably drops another /24 or so of space requirements) that's
about a /23, or on nibble boundaries a /20 ...I'm  sure heather  could
wrap some customer figures around that, but it's far beyond what you
could deduce externally/automatically.

> allocation, but I'm not sure how to test for what kind of allocation
> holder you are.
>
> If we can't tell the difference, does that negate the value in
> preemptive allocation? If it doesn't then let's make an educated guess
> as to what size is likely to be useful, recognizing that anyone who
> finds they received the wrong size is in no worse shape than they are
> without preemptive allocation.

I don't think you can... but APNIC's 'easy button' model isn't all bad.

-chris


From owen at delong.com  Sat Oct  9 07:11:50 2010
From: owen at delong.com (Owen DeLong)
Date: Sat, 9 Oct 2010 04:11:50 -0700
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <0FC11925-7D95-48B2-BEB7-E86B3AC062F5@cisco.com>
References: <C8D4BDBC.C834%ggiesen@akn.ca>
	<0FC11925-7D95-48B2-BEB7-E86B3AC062F5@cisco.com>
Message-ID: <3DAD3390-67BB-40A2-9B38-6BE347C76AAE@delong.com>


On Oct 8, 2010, at 6:12 PM, Fred Baker wrote:

> 
> On Oct 8, 2010, at 9:28 AM, Gary Giesen wrote:
> 
>> 1) What sort of mechanism are you going to use to verify IPv6 deployment? While I believe service providers can turn up v6 relatively quickly (if they haven't already done so), getting their customers turned up is another thing...
> 
> That is most definitely the case on both counts.
> 
> That said, let me throw a hypothetical question to you. Suppose that a hypothetical ISP had 20,000,000 residential/SOHO/SMB customers and a /32 prefix, and worked out a plan to address routers in its network using a ULA and distribute the /32 as some combination of /48's, /52's, and /56's to its


This would be terrible... An ISP with 20,000,000 customers should NEVER get a /32. They should
get a much larger prefix. Probably at least a /20 if not a /16.

Using ULA to address routers is just dumb.

> customers. It would be in a pretty good position to get some more addresses, I should imagine another /32 - and with any luck, do so by shortening its existing /32 to a /31 or shorter. Were I king (which I note I'm not) I would be able to do the math and say "they will need them whenever they do the deployment" without a lot more proof. My question would not be "so roll them out and renumber your network when you get to a certain deployment level"; my question would be "so show me that with this plan you have deployment in progress, implying that if I give you these addresses now you won't have to renumber your network when you get to that point".
> 
Correct. If you have 20,000,000 existing customers in IPv4, you should have no problem getting
a /20 or better from your RIR for IPv6.

> To my admittedly small mind, the objective here is to enable ISPs to use their resources to develop scalable, manageable IPv6 networks. It seems to me like working with them to accomplish that makes some sense. Yes, one needs to verify. But I should think that every ARIN member has an appropriate NDA, and ARIN itself can count the IPv4 address space allocated to the member, to support the discussion.
> ___________________________

Yes.

Owen



From owen at delong.com  Sat Oct  9 07:15:50 2010
From: owen at delong.com (Owen DeLong)
Date: Sat, 9 Oct 2010 04:15:50 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CAF63A9.8050408@bogus.com>
References: <4CAE19E1.308@chl.com>	<5DF50066-0402-4474-AF92-52ECFD90EF90@delong.com>	<AANLkTikZggx_9H8z+N9YWwUVJtdKf9VTeK3e7dBiP7W3@mail.gmail.com>
	<CD7991F9-FA34-47CB-B2E4-6A158CE86816@delong.com>
	<4CAF63A9.8050408@bogus.com>
Message-ID: <1B52434E-E838-4658-BAAD-A6F492A0FD38@delong.com>


On Oct 8, 2010, at 11:32 AM, Joel Jaeggli wrote:

> On 10/7/10 3:50 PM, Owen DeLong wrote:
>> On Oct 7, 2010, at 12:45 PM, Christopher Morrow wrote:
>>>> 1.      If it becomes a permanent deployment, it will seriously degrade end user
>>>>       capabilities and stifle innovation and place unnecessary limits on future
>>> 
>>> more than not having ipv6 will? more than nat/nat/nat will? I'm not a
>>> particularly large fan of 6rd either, but... it does give the
>>> capability to get v6 to end users (in a decent quality) and today.
>>> 
>> Less than those, but, more than native IPv6.
> 
> in either the native case or the 6rd case you're jacking up the cpe so
> the difference is in the access network.
> 
I'm not sure I understand that statement. With 6rd, it's utterly impractical to give
out large enough blocks for end users to get /48s. We're stuck with giving out
huge blocks (/24s) just to enable end customers to get /56s. That's horrible,
but, livable on a temporary basis.

With native, a /32 will support 65,500+ /48 customers and you should be able
to get more if you need. Unless you're one of the 5 or so largest ISPs in the
world, you should be able to get by with a /20 or less. Most ISPs other than
the smallest of the small probably should get /28s.

(Yes, I realize current policy is defective in this regard and I am working on
a proposal to correct that).

>>> Talking to Mark some, and Lorenzo, and looked at ietf work ongoing to
>>> bring operations tools/capabilities they need to deploy v6 in a
>>> congruent manner as v4.... waiting for this will take quite a long
>>> while (2-3 years at best for the standards work to finish, never mind
>>> implementations).
>>> 
>> Hence my suggestion that we provide for 6rd, but, require that it be
>> something we can deprecate later.
>> 
>>> To be clear, I'd support neither -9 nor -12, but a fix for -12 that
>>> removed all of the 'transition technology' wording and focused on
>>> 'subsequent allocation' alone.
>>> 
>> Yeah, I can't support that without safeguards to make sure that we
>> can deprecate 6rd.
> 
> if something gets cooked into the network for perhaps a decade it's not
> coming out easily. the ability to deprecate it is tied either to it's
> nature as a short-term bandaid, which I'm not sure I buy or it's failure
> in the marketplace. I see no reason to presuppose the latter.
> 
The ability to deprecate it is tied to having it in a prefix that providers who
agree it should be deprecated can start filtering later. If it stops working
for a large enough portion of the network, then, it gets deprecated.
If it doesn't, then, it remains permanent.

Sure, having it in a separate prefix doesn't guarantee deprecation, but,
failing to put it in a separate prefix guarantees deprecation is impossible.

Owen



From owen at delong.com  Sat Oct  9 07:39:27 2010
From: owen at delong.com (Owen DeLong)
Date: Sat, 9 Oct 2010 04:39:27 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <AANLkTimN18bazayFxjjbCefEN6p2x9kLJO0M7hat=U29@mail.gmail.com>
References: <4CAE19E1.308@chl.com>
	<5DF50066-0402-4474-AF92-52ECFD90EF90@delong.com>
	<AANLkTikZggx_9H8z+N9YWwUVJtdKf9VTeK3e7dBiP7W3@mail.gmail.com>
	<CD7991F9-FA34-47CB-B2E4-6A158CE86816@delong.com>
	<4CAF63A9.8050408@bogus.com>
	<AANLkTimN18bazayFxjjbCefEN6p2x9kLJO0M7hat=U29@mail.gmail.com>
Message-ID: <9CD47A85-4094-4FB1-962F-1C3EC56BB3B0@delong.com>


On Oct 8, 2010, at 8:01 PM, Christopher Morrow wrote:

> On Fri, Oct 8, 2010 at 2:32 PM, Joel Jaeggli <joelja at bogus.com> wrote:
>>> Yeah, I can't support that without safeguards to make sure that we
>>> can deprecate 6rd.
>> 
>> if something gets cooked into the network for perhaps a decade it's not
>> coming out easily. the ability to deprecate it is tied either to it's
>> nature as a short-term bandaid, which I'm not sure I buy or it's failure
>> in the marketplace. I see no reason to presuppose the latter.
> 
> I agree with Joel here, I think once 6rd goes in... if the support is
> in linecards/interfaces and CPE and 'low cost' to the devices in
> question (happens in hardware on the ingress interface of the SP
> router, for instance) then... There's not much incentive to migrate
> away from it. I can see it staying deployed for a very long time.
> (unless of course there are no ipv4 numbers to be used in the ISP...)
> 
> -Chris

That's what concerns me.  6rd will stifle future innovation in what
we can deliver to home users. That's bad. I agree we have to swallow
hard and accept it for the moment, but, to do so, we need to safeguard
the future and have ways to create incentives to deprecate it later.

We can't give people more than a /56 of IPv6 space in 6rd, and even
that requires handing out /24s to the providers to make it happen.

Hierarchical DHCP6-PD structures and other coming household
innovations are going to require that we give SOHO users more than
a /56, ideally a /48. I don't think we want to give every 6rd ISP a /16,
so, I think we need to have ways to get beyond 6rd.

Owen



From christopher.morrow at gmail.com  Sat Oct  9 10:25:32 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Sat, 9 Oct 2010 10:25:32 -0400
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <3DAD3390-67BB-40A2-9B38-6BE347C76AAE@delong.com>
References: <C8D4BDBC.C834%ggiesen@akn.ca>
	<0FC11925-7D95-48B2-BEB7-E86B3AC062F5@cisco.com>
	<3DAD3390-67BB-40A2-9B38-6BE347C76AAE@delong.com>
Message-ID: <AANLkTinaquhG5n9eDhftLbLSKZeYC2Oc4gRx+gus5+-O@mail.gmail.com>

On Sat, Oct 9, 2010 at 7:11 AM, Owen DeLong <owen at delong.com> wrote:
> Using ULA to address routers is just dumb.

s/routers/anything/

there I fixed it for you.

-chris


From christopher.morrow at gmail.com  Sat Oct  9 10:29:15 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Sat, 9 Oct 2010 10:29:15 -0400
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <3DAD3390-67BB-40A2-9B38-6BE347C76AAE@delong.com>
References: <C8D4BDBC.C834%ggiesen@akn.ca>
	<0FC11925-7D95-48B2-BEB7-E86B3AC062F5@cisco.com>
	<3DAD3390-67BB-40A2-9B38-6BE347C76AAE@delong.com>
Message-ID: <AANLkTik-0yk=LF7BGDhS_KE2WkkYTh7R5YOds0oQYG6H@mail.gmail.com>

On Sat, Oct 9, 2010 at 7:11 AM, Owen DeLong <owen at delong.com> wrote:

> Correct. If you have 20,000,000 existing customers in IPv4, you should have no problem getting
> a /20 or better from your RIR for IPv6.
>

this depends on the end-user allocation size though, I make 20m
customers with /56's (which may be the 'right' answer for cable/dsl
users) 1.2 /32 equivalents, so call it a /28 if you like the nibble
boundary method.  Right?

it's 308ish /32 equivalents or a /20 (really a /23, but nibbled up to a /20)

-chris


From christopher.morrow at gmail.com  Sat Oct  9 10:39:11 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Sat, 9 Oct 2010 10:39:11 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <9CD47A85-4094-4FB1-962F-1C3EC56BB3B0@delong.com>
References: <4CAE19E1.308@chl.com>
	<5DF50066-0402-4474-AF92-52ECFD90EF90@delong.com>
	<AANLkTikZggx_9H8z+N9YWwUVJtdKf9VTeK3e7dBiP7W3@mail.gmail.com>
	<CD7991F9-FA34-47CB-B2E4-6A158CE86816@delong.com>
	<4CAF63A9.8050408@bogus.com>
	<AANLkTimN18bazayFxjjbCefEN6p2x9kLJO0M7hat=U29@mail.gmail.com>
	<9CD47A85-4094-4FB1-962F-1C3EC56BB3B0@delong.com>
Message-ID: <AANLkTiniO6Gop09MSoj3_DbxGNUqwJUjCaM-v8+wBaV4@mail.gmail.com>

On Sat, Oct 9, 2010 at 7:39 AM, Owen DeLong <owen at delong.com> wrote:

> Hierarchical DHCP6-PD structures and other coming household
> innovations are going to require that we give SOHO users more than
> a /56, ideally a /48. I don't think we want to give every 6rd ISP a /16,
> so, I think we need to have ways to get beyond 6rd.

suddenly ipv6 got a whole lot less 'infinite'...


From tme at multicasttech.com  Sat Oct  9 14:02:00 2010
From: tme at multicasttech.com (Marshall Eubanks)
Date: Sat, 9 Oct 2010 14:02:00 -0400
Subject: [arin-ppml] I also oppose 2010-9
Message-ID: <5918A389-0011-45E8-A4D6-6687F390EAFA@multicasttech.com>

I also oppose 2010-9 as (as has been better expressed by a number of other people)

- it will rapidly burn through the IPv6 address space and
- it is likely to last a long time (decades) if once implemented.

Regards
Marshall Eubanks

From cgrundemann at gmail.com  Sat Oct  9 15:34:02 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Sat, 9 Oct 2010 13:34:02 -0600
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <AANLkTingLkZsMdyiQQJo8pz0h3DDBiTYd0gU9n7jTRhV@mail.gmail.com>
References: <AANLkTingLkZsMdyiQQJo8pz0h3DDBiTYd0gU9n7jTRhV@mail.gmail.com>
Message-ID: <AANLkTikfOmmJsUxcqsTQUrUo_GscX=2sZfNr0DicRcvP@mail.gmail.com>

Let me offer a general response to all of the great feedback:

The basic idea here is to redefine efficient utilization. The fact is
that at this point (and for quite some time now) IPv4 addresses that
are not deployed along with IPv6 addresses are simply not being
efficiently utilized. Just like assigning a v4/24 to a PTP link is
wasteful, deploying IPv4 only is wasteful.

Many folks have made comments that effectively say "this is hard" and
that in some cases, IPv6 deployment is still impossible. What do you
think is going to happen next year when there is no more IPv4? This
policy effectively places a new wall in front of the no-more-v4-at-all
wall. The effect is to apply real pressure now, so that we have less
pain then.

Every crazy scenario that you can think of with regard to IPv4
depletion is going to happen - all of it. The real question is not how
bad it will be (bad) or when it will happen (soon) but rather how long
will it last? The answer depends on whether this community decides to
step up and provide real leadership or not.

The only true soft-landing strategy that will allow the transition to
happen without pain is to dual-stack everything and simply let traffic
shift over from v4 to v6. That ship has sailed. So now we have two
choices:

1) Change nothing and run into the wall. This idea has merit in that
we stick to our guns, and provide some predictability by not changing
the rules.
2) Require IPv6 deployment now. This idea has merit because it allows
IPv4 to keep growing while also softening the blow when new IPv4 runs
out.

The way to implement option #1 is pretty obvious. The method to affect
option #2 is probably a bit less clear. What Jason, Marty and I have
come up with here is a start at defining that method. Due to the
applause at open mike, the in-person feedback in Atlanta and the
responses here on the list - I am going to assume that this is
valuable and that there are a lot of folks in the community who think
that option #2 (action) is preferred to option #1 (inaction).

So - where do we go from here?

I would like to propose that we start with a high level discussion of
whether or not this basic idea is what the community wants and then
(if we do want this) dive quickly into the details of how exactly to
do it.

With that in mind, I set up a quick poll on doodle:
http://doodle.com/wewba7hnpkqhc9e2

I will post the poll to ppml separately as well to grab the widest
audience - please forgive the double post. Feel free to share the poll
with all other interested members of the Internet community.

Cheers,
~Chris

"Those who do not create the future they want must endure the future they get."
~Draper L. Kaufman, Jr.



On Fri, Oct 8, 2010 at 10:00, Chris Grundemann <cgrundemann at gmail.com> wrote:
> Problem Statement:
> We have failed to deploy dual-stack in a meaningful way in time to
> avoid transition problems
>
> Objectives:
> -1- Encourage IPv6 deployment prior to depletion
> -2- Enable growth of IPv4 where IPv6 is being deployed
> -3- Improve the utilization of IP addresses
>
> High-Level Requirements:
> -1- ARIN will only make allocations and assignments for networks that
> have already deployed production IPv6
> -2- Any IPv4 addresses received under this policy, must be deployed
> along side of IPv6
> -3- This policy will encourage deployment of IPv6 in existing IPv4-only networks
>
> Rough Policy Text:
> ~ Requester defines classes in their network - only classes where IPv6
> is in production qualify for IPv6
> ~ New addresses must be deployed on dual-stacked interfaces plus one
> additional existing IPv4-only interface must be dual stacked, up to
> 80% of all interfaces.
> ~ The service that the address is used to provide must be fully IPv6
> accessible (if you deploy an A record, you must also have a AAAA and
> both must answer)
> ~ All end-sites must dual-stack all Internet facing services before
> getting this space
> ~ For each down stream customer site where these addresses are
> deployed, another pre-existing IPv4 only down stream site must also be
> IPv6?enabled, up to 80% of the total customer base.
>
>
> This is an emergency, let's get something together ASAP. All feedback
> is extremely welcome and greatly appreciated; this problem is all of
> ours. If you are still here in Atlanta come find me, Marty Hannigan
> and/or Jason Schiller to discuss.
>
> Thanks!
> ~Chris


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


From cgrundemann at gmail.com  Sat Oct  9 15:45:24 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Sat, 9 Oct 2010 13:45:24 -0600
Subject: [arin-ppml] IPv4 Crumbs Straw Poll
Message-ID: <AANLkTi=F0xxfrqJcqCTZSvYrZpwAfJ63DcruMrOdN-HE@mail.gmail.com>

As I mentioned at the mike in response to dp2010-13 (and some of us
discussed at lunch); I believe strongly that we are down to two
choices with regard to the crumbs of IPv4: Do nothing and use them up
under current policy or leverage them to speed IPv6 adoption and thus
lower the pain of transition.

I am extremely curious as to which of these two options our community
feels is preferable. To make this easy; I set up a poll on doodle:
http://doodle.com/wewba7hnpkqhc9e2

Please take a minute to answer it and to share it with other members
of the ARIN community.

Thank you,
~Chris


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


From owen at delong.com  Sat Oct  9 18:38:21 2010
From: owen at delong.com (Owen DeLong)
Date: Sat, 9 Oct 2010 18:38:21 -0400
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <AANLkTinaquhG5n9eDhftLbLSKZeYC2Oc4gRx+gus5+-O@mail.gmail.com>
References: <C8D4BDBC.C834%ggiesen@akn.ca>
	<0FC11925-7D95-48B2-BEB7-E86B3AC062F5@cisco.com>
	<3DAD3390-67BB-40A2-9B38-6BE347C76AAE@delong.com>
	<AANLkTinaquhG5n9eDhftLbLSKZeYC2Oc4gRx+gus5+-O@mail.gmail.com>
Message-ID: <EF85D7E0-BE64-495C-A980-93A1874CB62C@delong.com>

Agreed... I was just responding to what was said. To me, ULA is like DDT... One of those things I wish we could uninvent.

Owen

Sent from my iPad

On Oct 9, 2010, at 10:25 AM, Christopher Morrow <christopher.morrow at gmail.com> wrote:

> On Sat, Oct 9, 2010 at 7:11 AM, Owen DeLong <owen at delong.com> wrote:
>> Using ULA to address routers is just dumb.
> 
> s/routers/anything/
> 
> there I fixed it for you.
> 
> -chris


From owen at delong.com  Sat Oct  9 18:43:36 2010
From: owen at delong.com (Owen DeLong)
Date: Sat, 9 Oct 2010 18:43:36 -0400
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <AANLkTik-0yk=LF7BGDhS_KE2WkkYTh7R5YOds0oQYG6H@mail.gmail.com>
References: <C8D4BDBC.C834%ggiesen@akn.ca>
	<0FC11925-7D95-48B2-BEB7-E86B3AC062F5@cisco.com>
	<3DAD3390-67BB-40A2-9B38-6BE347C76AAE@delong.com>
	<AANLkTik-0yk=LF7BGDhS_KE2WkkYTh7R5YOds0oQYG6H@mail.gmail.com>
Message-ID: <A962806A-B53E-418E-9234-795153D3D0CC@delong.com>



Sent from my iPad

On Oct 9, 2010, at 10:29 AM, Christopher Morrow <christopher.morrow at gmail.com> wrote:

> On Sat, Oct 9, 2010 at 7:11 AM, Owen DeLong <owen at delong.com> wrote:
> 
>> Correct. If you have 20,000,000 existing customers in IPv4, you should have no problem getting
>> a /20 or better from your RIR for IPv6.
>> 
> 
> this depends on the end-user allocation size though, I make 20m
> customers with /56's (which may be the 'right' answer for cable/dsl
> users) 1.2 /32 equivalents, so call it a /28 if you like the nibble
> boundary method.  Right?
> 
> it's 308ish /32 equivalents or a /20 (really a /23, but nibbled up to a /20)
> 
> -chris


For a variety of reasons, not the least of which is hierarchical dhcpv6 pd in the soho, /56 is not the 'right' answer. The correct answer really is /48.

20,000,000 anythings require 21 bits to represent. Rounding that to 24 just makes sense and 48-24 is 24.

Owen



From bill at herrin.us  Sat Oct  9 18:46:34 2010
From: bill at herrin.us (William Herrin)
Date: Sat, 9 Oct 2010 18:46:34 -0400
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <3DAD3390-67BB-40A2-9B38-6BE347C76AAE@delong.com>
References: <C8D4BDBC.C834%ggiesen@akn.ca>
	<0FC11925-7D95-48B2-BEB7-E86B3AC062F5@cisco.com>
	<3DAD3390-67BB-40A2-9B38-6BE347C76AAE@delong.com>
Message-ID: <AANLkTinKgj_7CFRKHp-wH7EkVg9mQAHaAKTts=vOwjrt@mail.gmail.com>

On Sat, Oct 9, 2010 at 7:11 AM, Owen DeLong <owen at delong.com> wrote:
> This would be terrible... An ISP with 20,000,000 customers
> should NEVER get a /32. They should
> get a much larger prefix. Probably at least a /20 if not a /16.

Owen,

We've gone to an address space 30 orders of magnitude larger. Would
you truly have us start our burn at rates only 2 orders slower than
the accelerating consumption of 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 owen at delong.com  Sun Oct 10 00:00:07 2010
From: owen at delong.com (Owen DeLong)
Date: Sat, 9 Oct 2010 23:00:07 -0500
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <AANLkTinKgj_7CFRKHp-wH7EkVg9mQAHaAKTts=vOwjrt@mail.gmail.com>
References: <C8D4BDBC.C834%ggiesen@akn.ca>
	<0FC11925-7D95-48B2-BEB7-E86B3AC062F5@cisco.com>
	<3DAD3390-67BB-40A2-9B38-6BE347C76AAE@delong.com>
	<AANLkTinKgj_7CFRKHp-wH7EkVg9mQAHaAKTts=vOwjrt@mail.gmail.com>
Message-ID: <08DFE069-C69C-4F1B-9C22-95DC23C61E65@delong.com>



Sent from my iPad

On Oct 9, 2010, at 5:46 PM, William Herrin <bill at herrin.us> wrote:

> On Sat, Oct 9, 2010 at 7:11 AM, Owen DeLong <owen at delong.com> wrote:
>> This would be terrible... An ISP with 20,000,000 customers
>> should NEVER get a /32. They should
>> get a much larger prefix. Probably at least a /20 if not a /16.
> 
> Owen,
> 
> We've gone to an address space 30 orders of magnitude larger. Would
> you truly have us start our burn at rates only 2 orders slower than
> the accelerating consumption of IPv4?
> 
> Regards.
> Bill Herrin
> 
> 
Bill... See my previous post. End sites should get at least a /48... If you serve 20,000,000 end sites, you need 23 bits to define those customers. 48-23 is 25. The closest larger nibble boundary is 20.  There are few enough providers serving 20,000,000 subscribers that I don't see it as a problem. Most providers should probably get /28s with larger ones getting /24s and smaller ones getting /32s.

We will cause harm by being stingy with address space beyond these points.

Owen

> 
> -- 
> 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 Oct 10 01:46:01 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Sun, 10 Oct 2010 01:46:01 -0400
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <08DFE069-C69C-4F1B-9C22-95DC23C61E65@delong.com>
References: <C8D4BDBC.C834%ggiesen@akn.ca>
	<0FC11925-7D95-48B2-BEB7-E86B3AC062F5@cisco.com>
	<3DAD3390-67BB-40A2-9B38-6BE347C76AAE@delong.com>
	<AANLkTinKgj_7CFRKHp-wH7EkVg9mQAHaAKTts=vOwjrt@mail.gmail.com>
	<08DFE069-C69C-4F1B-9C22-95DC23C61E65@delong.com>
Message-ID: <AANLkTim_3funAh=TgenrHQC3Q5H7kq1YMQVMBFarCF8a@mail.gmail.com>

On Sun, Oct 10, 2010 at 12:00 AM, Owen DeLong <owen at delong.com> wrote:

> We will cause harm by being stingy with address space beyond these points.

you've mentioned (at least 2x in the last 3 days) that /48's for
consumer end sites permit heirarchical dhcpv6-PD, can you explain how
the you see this working? and more importantly why you can't do PD on
... just about any other boundary? Why can't I do PD of a /64 or /60
inside an already PD'd /56 to my home gateway? (or is this just
inconvenient?)

-Chris


From owen at delong.com  Sun Oct 10 02:12:28 2010
From: owen at delong.com (Owen DeLong)
Date: Sat, 9 Oct 2010 23:12:28 -0700
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <AANLkTim_3funAh=TgenrHQC3Q5H7kq1YMQVMBFarCF8a@mail.gmail.com>
References: <C8D4BDBC.C834%ggiesen@akn.ca>
	<0FC11925-7D95-48B2-BEB7-E86B3AC062F5@cisco.com>
	<3DAD3390-67BB-40A2-9B38-6BE347C76AAE@delong.com>
	<AANLkTinKgj_7CFRKHp-wH7EkVg9mQAHaAKTts=vOwjrt@mail.gmail.com>
	<08DFE069-C69C-4F1B-9C22-95DC23C61E65@delong.com>
	<AANLkTim_3funAh=TgenrHQC3Q5H7kq1YMQVMBFarCF8a@mail.gmail.com>
Message-ID: <F2A4D3F8-4269-40DD-9B6F-2C4AE8E6D664@delong.com>


On Oct 9, 2010, at 10:46 PM, Christopher Morrow wrote:

> On Sun, Oct 10, 2010 at 12:00 AM, Owen DeLong <owen at delong.com> wrote:
> 
>> We will cause harm by being stingy with address space beyond these points.
> 
> you've mentioned (at least 2x in the last 3 days) that /48's for
> consumer end sites permit heirarchical dhcpv6-PD, can you explain how
> the you see this working? and more importantly why you can't do PD on
> ... just about any other boundary? Why can't I do PD of a /64 or /60
> inside an already PD'd /56 to my home gateway? (or is this just
> inconvenient?)
> 
For better or worse, /64 as the end subnet size is pretty well codified
and required for SLAAC. So, PD of /64 is a non-starter.

A /60 allows you a flat network of 16 subnets. If you don't have
a 16-port router, but, instead have a stack of routers, then, how
do you go about dividing up those bits?

At a minimum, you could use 2 bits per layer and allow for
each layer to contain 4 routers each of which could have 4
ports (subnets) attached. With 4 bits, that means you get
essentially 2 layers.

There are a lot of technologies being developed for sensor
networks and home automation that will require significantly
deeper layering. You may think this absurd, but, imagine
your refrigerator is a router. It contains a collection of subnets
which contain RFIDs and RIFD readers to address what is
in the refrigerator, the state of various operational
characteristics of the refrigerator itself, etc.

You could, literally, be able to use the web browser in
your phone and have the refrigerator inform you of what
you do and don't have left in it while you are at the store.
Absurd? Perhaps, but, people also bought pet rocks.
The technology for this is real and I do not think it is that
far off for you to start seeing it deployed, if the addressing
issues stop being a barrier to the process.

I'm sure there are other examples. Tony Hain actually
does a much better job of explaining it than I do. I'll CC him
here in hopes he will respond, since I'm not sure whether
he follows PPML or not.

Owen



From jmaimon at chl.com  Sun Oct 10 04:20:05 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Sun, 10 Oct 2010 04:20:05 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <5025F541-0BBC-4EAF-A5E7-8B9A47F38685@delong.com>
References: <C8D39A81.C7AF%ggiesen@akn.ca>
	<B38D4D8F-9EBD-410A-97B7-28041A618D92@delong.com>
	<4CAE2B9A.6040101@chl.com>
	<5025F541-0BBC-4EAF-A5E7-8B9A47F38685@delong.com>
Message-ID: <4CB17735.2050403@chl.com>



Owen DeLong wrote:
> On Oct 7, 2010, at 1:20 PM, Joe Maimon wrote:
>    
>>
>> Does it provide enough space only for whom a /32 for native was enough or for all?
>>
>>      
> By definition a /24 is enough for any ISP to do /56s for all of their IPv4 customers because
> there are only 32 bits in IPv4. Since 6rd contains a mapping of the IPv4 /32 into the
> IPv6 address, this is pretty basic.
>
> Perhaps I don't understand your question.
>
> Owen
>
>
>    

Is there any reason a large ISP might want more than one 6rd scheme?


Joe


From jmaimon at chl.com  Sun Oct 10 04:29:48 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Sun, 10 Oct 2010 04:29:48 -0400
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <F2A4D3F8-4269-40DD-9B6F-2C4AE8E6D664@delong.com>
References: <C8D4BDBC.C834%ggiesen@akn.ca>	<0FC11925-7D95-48B2-BEB7-E86B3AC062F5@cisco.com>	<3DAD3390-67BB-40A2-9B38-6BE347C76AAE@delong.com>	<AANLkTinKgj_7CFRKHp-wH7EkVg9mQAHaAKTts=vOwjrt@mail.gmail.com>	<08DFE069-C69C-4F1B-9C22-95DC23C61E65@delong.com>	<AANLkTim_3funAh=TgenrHQC3Q5H7kq1YMQVMBFarCF8a@mail.gmail.com>
	<F2A4D3F8-4269-40DD-9B6F-2C4AE8E6D664@delong.com>
Message-ID: <4CB1797C.8000202@chl.com>



Owen DeLong wrote:
>
> On Oct 9, 2010, at 10:46 PM, Christopher Morrow wrote:
>
>> On Sun, Oct 10, 2010 at 12:00 AM, Owen DeLong<owen at delong.com>  wrote:
>>
>>> We will cause harm by being stingy with address space beyond these points.
>>
>> you've mentioned (at least 2x in the last 3 days) that /48's for
>> consumer end sites permit heirarchical dhcpv6-PD, can you explain how
>> the you see this working? and more importantly why you can't do PD on
>> ... just about any other boundary? Why can't I do PD of a /64 or /60
>> inside an already PD'd /56 to my home gateway? (or is this just
>> inconvenient?)
>>
> For better or worse, /64 as the end subnet size is pretty well codified
> and required for SLAAC. So, PD of /64 is a non-starter.

Its only as codified as we all allow it to be by continuing to give 
SLAAC veto power over the rightmost 64 bits.

Its early days yet. In comparable v4 history, it was the leftmost bits 
that were well codified.

There are alternatives to slaac, and apipa has already shown that 16 
bits is sufficient in todays world.

Toss in privacy concerns and slaac is starting to look stodgy.

Automatic numbering and subnetting schemes in v6 are going to have to be 
a bit more bit flexible if they are to withstand the test of time.

In other words, pdv6 would have to ripple up the chain and cause subnet 
shortening on the fly all the way up in order to be fully robust.

Joe



From BillD at cait.wustl.edu  Sun Oct 10 08:05:16 2010
From: BillD at cait.wustl.edu (Bill Darte)
Date: Sun, 10 Oct 2010 07:05:16 -0500
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
References: <AANLkTingLkZsMdyiQQJo8pz0h3DDBiTYd0gU9n7jTRhV@mail.gmail.com>
	<AANLkTikfOmmJsUxcqsTQUrUo_GscX=2sZfNr0DicRcvP@mail.gmail.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D030879153D6@ex1.cait.wustl.edu>

Chris,

As you know, at our lunch table discussion 'fighting over the crumbs of v4', I made mention that I believed it was beyond the scope of ARIN's mission to 'mandate a business practice change' like requiring v6 implementation as a condition of receiving future v4 allocations.

In a brief discussion about the legality of such....I now believe(or interpret what I heard) that ARIN might arguably do this without undue risk....

FYI...

bd
-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Chris Grundemann
Sent: Sat 10/9/2010 2:34 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
 
Let me offer a general response to all of the great feedback:

The basic idea here is to redefine efficient utilization. The fact is
that at this point (and for quite some time now) IPv4 addresses that
are not deployed along with IPv6 addresses are simply not being
efficiently utilized. Just like assigning a v4/24 to a PTP link is
wasteful, deploying IPv4 only is wasteful.

Many folks have made comments that effectively say "this is hard" and
that in some cases, IPv6 deployment is still impossible. What do you
think is going to happen next year when there is no more IPv4? This
policy effectively places a new wall in front of the no-more-v4-at-all
wall. The effect is to apply real pressure now, so that we have less
pain then.

Every crazy scenario that you can think of with regard to IPv4
depletion is going to happen - all of it. The real question is not how
bad it will be (bad) or when it will happen (soon) but rather how long
will it last? The answer depends on whether this community decides to
step up and provide real leadership or not.

The only true soft-landing strategy that will allow the transition to
happen without pain is to dual-stack everything and simply let traffic
shift over from v4 to v6. That ship has sailed. So now we have two
choices:

1) Change nothing and run into the wall. This idea has merit in that
we stick to our guns, and provide some predictability by not changing
the rules.
2) Require IPv6 deployment now. This idea has merit because it allows
IPv4 to keep growing while also softening the blow when new IPv4 runs
out.

The way to implement option #1 is pretty obvious. The method to affect
option #2 is probably a bit less clear. What Jason, Marty and I have
come up with here is a start at defining that method. Due to the
applause at open mike, the in-person feedback in Atlanta and the
responses here on the list - I am going to assume that this is
valuable and that there are a lot of folks in the community who think
that option #2 (action) is preferred to option #1 (inaction).

So - where do we go from here?

I would like to propose that we start with a high level discussion of
whether or not this basic idea is what the community wants and then
(if we do want this) dive quickly into the details of how exactly to
do it.

With that in mind, I set up a quick poll on doodle:
http://doodle.com/wewba7hnpkqhc9e2

I will post the poll to ppml separately as well to grab the widest
audience - please forgive the double post. Feel free to share the poll
with all other interested members of the Internet community.

Cheers,
~Chris

"Those who do not create the future they want must endure the future they get."
~Draper L. Kaufman, Jr.



On Fri, Oct 8, 2010 at 10:00, Chris Grundemann <cgrundemann at gmail.com> wrote:
> Problem Statement:
> We have failed to deploy dual-stack in a meaningful way in time to
> avoid transition problems
>
> Objectives:
> -1- Encourage IPv6 deployment prior to depletion
> -2- Enable growth of IPv4 where IPv6 is being deployed
> -3- Improve the utilization of IP addresses
>
> High-Level Requirements:
> -1- ARIN will only make allocations and assignments for networks that
> have already deployed production IPv6
> -2- Any IPv4 addresses received under this policy, must be deployed
> along side of IPv6
> -3- This policy will encourage deployment of IPv6 in existing IPv4-only networks
>
> Rough Policy Text:
> ~ Requester defines classes in their network - only classes where IPv6
> is in production qualify for IPv6
> ~ New addresses must be deployed on dual-stacked interfaces plus one
> additional existing IPv4-only interface must be dual stacked, up to
> 80% of all interfaces.
> ~ The service that the address is used to provide must be fully IPv6
> accessible (if you deploy an A record, you must also have a AAAA and
> both must answer)
> ~ All end-sites must dual-stack all Internet facing services before
> getting this space
> ~ For each down stream customer site where these addresses are
> deployed, another pre-existing IPv4 only down stream site must also be
> IPv6?enabled, up to 80% of the total customer base.
>
>
> This is an emergency, let's get something together ASAP. All feedback
> is extremely welcome and greatly appreciated; this problem is all of
> ours. If you are still here in Atlanta come find me, Marty Hannigan
> and/or Jason Schiller to discuss.
>
> Thanks!
> ~Chris


-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.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.

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

From owen at delong.com  Sun Oct 10 08:27:01 2010
From: owen at delong.com (Owen DeLong)
Date: Sun, 10 Oct 2010 05:27:01 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CB17735.2050403@chl.com>
References: <C8D39A81.C7AF%ggiesen@akn.ca>
	<B38D4D8F-9EBD-410A-97B7-28041A618D92@delong.com>
	<4CAE2B9A.6040101@chl.com>
	<5025F541-0BBC-4EAF-A5E7-8B9A47F38685@delong.com>
	<4CB17735.2050403@chl.com>
Message-ID: <6BCFA1B9-2F20-440D-8105-7693D8F16909@delong.com>


On Oct 10, 2010, at 1:20 AM, Joe Maimon wrote:

> 
> 
> Owen DeLong wrote:
>> On Oct 7, 2010, at 1:20 PM, Joe Maimon wrote:
>>   
>>> 
>>> Does it provide enough space only for whom a /32 for native was enough or for all?
>>> 
>>>     
>> By definition a /24 is enough for any ISP to do /56s for all of their IPv4 customers because
>> there are only 32 bits in IPv4. Since 6rd contains a mapping of the IPv4 /32 into the
>> IPv6 address, this is pretty basic.
>> 
>> Perhaps I don't understand your question.
>> 
>> Owen
>> 
>> 
>>   
> 
> Is there any reason a large ISP might want more than one 6rd scheme?
> 
Not that I can think of, and, the real problem with 6rd is that it doesn't matter what
size ISP you are... From the tiniest to the largest, they all consume the same
messed up prefix size for the same number of end bits to the end site.

So even a tiny ISP with 100 customers, if they want to give /56s to their end sites
will still consume 56-32 = /24.

Owen



From owen at delong.com  Sun Oct 10 08:33:03 2010
From: owen at delong.com (Owen DeLong)
Date: Sun, 10 Oct 2010 05:33:03 -0700
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <4CB1797C.8000202@chl.com>
References: <C8D4BDBC.C834%ggiesen@akn.ca>	<0FC11925-7D95-48B2-BEB7-E86B3AC062F5@cisco.com>	<3DAD3390-67BB-40A2-9B38-6BE347C76AAE@delong.com>	<AANLkTinKgj_7CFRKHp-wH7EkVg9mQAHaAKTts=vOwjrt@mail.gmail.com>	<08DFE069-C69C-4F1B-9C22-95DC23C61E65@delong.com>	<AANLkTim_3funAh=TgenrHQC3Q5H7kq1YMQVMBFarCF8a@mail.gmail.com>
	<F2A4D3F8-4269-40DD-9B6F-2C4AE8E6D664@delong.com>
	<4CB1797C.8000202@chl.com>
Message-ID: <8B5E8607-7FBE-4F36-8465-9EEBDE7BA5CB@delong.com>


On Oct 10, 2010, at 1:29 AM, Joe Maimon wrote:

> 
> 
> Owen DeLong wrote:
>> 
>> On Oct 9, 2010, at 10:46 PM, Christopher Morrow wrote:
>> 
>>> On Sun, Oct 10, 2010 at 12:00 AM, Owen DeLong<owen at delong.com>  wrote:
>>> 
>>>> We will cause harm by being stingy with address space beyond these points.
>>> 
>>> you've mentioned (at least 2x in the last 3 days) that /48's for
>>> consumer end sites permit heirarchical dhcpv6-PD, can you explain how
>>> the you see this working? and more importantly why you can't do PD on
>>> ... just about any other boundary? Why can't I do PD of a /64 or /60
>>> inside an already PD'd /56 to my home gateway? (or is this just
>>> inconvenient?)
>>> 
>> For better or worse, /64 as the end subnet size is pretty well codified
>> and required for SLAAC. So, PD of /64 is a non-starter.
> 
> Its only as codified as we all allow it to be by continuing to give SLAAC veto power over the rightmost 64 bits.
> 
That ship really has sailed. SLAAC is deployed, people are using it. Breaking SLAAC would
be a bad thing.

> Its early days yet. In comparable v4 history, it was the leftmost bits that were well codified.
> 
Not early enough.

> There are alternatives to slaac, and apipa has already shown that 16 bits is sufficient in todays world.
> 
I'm not sure what you mean by apipa, but, no, 16 bits isn't sufficient for a stateless scheme.
It's especially insufficient if you want to allow for things like privacy addressing.

> Toss in privacy concerns and slaac is starting to look stodgy.
> 
Actually SLAAC with privacy addressing looks pretty good. Much better than almost any other
addressing scheme today for privacy concerns.

> Automatic numbering and subnetting schemes in v6 are going to have to be a bit more bit flexible if they are to withstand the test of time.
> 
It doesn't get much more flexible than SLAAC except for the requirement for EUI-64 based
end system identifiers.

> In other words, pdv6 would have to ripple up the chain and cause subnet shortening on the fly all the way up in order to be fully robust.
> 
Now you're throwing random technologies in a blender and postulating what comes out.

DHCPv6 PD does actually allow for shortening on the fly as you describe, but, most implementations
don't. However, the problem is that if the shortened result is the CPE->ISP router requesting a
prefix larger than the ISP can or will give, it doesn't matter how much dynamic shortening occurred
or not.

Owen



From scottleibrand at gmail.com  Sun Oct 10 08:37:07 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Sun, 10 Oct 2010 08:37:07 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <6BCFA1B9-2F20-440D-8105-7693D8F16909@delong.com>
References: <C8D39A81.C7AF%ggiesen@akn.ca>
	<B38D4D8F-9EBD-410A-97B7-28041A618D92@delong.com>
	<4CAE2B9A.6040101@chl.com>
	<5025F541-0BBC-4EAF-A5E7-8B9A47F38685@delong.com>
	<4CB17735.2050403@chl.com>
	<6BCFA1B9-2F20-440D-8105-7693D8F16909@delong.com>
Message-ID: <9303FD38-7283-40FF-BF51-B2504CCDDFA7@gmail.com>


On Oct 10, 2010, at 8:27 AM, Owen DeLong <owen at delong.com> wrote:

> 
> On Oct 10, 2010, at 1:20 AM, Joe Maimon wrote:
> 
>> 
>> Is there any reason a large ISP might want more than one 6rd scheme?
>> 
> Not that I can think of, and, the real problem with 6rd is that it doesn't matter what
> size ISP you are... From the tiniest to the largest, they all consume the same
> messed up prefix size for the same number of end bits to the end site.
> 
> So even a tiny ISP with 100 customers, if they want to give /56s to their end sites
> will still consume 56-32 = /24.

Well, if you only have one v4 prefix, you don't need 32 bits.  That only helps in the smallest cases though. 

-Scott


From owen at delong.com  Sun Oct 10 08:42:52 2010
From: owen at delong.com (Owen DeLong)
Date: Sun, 10 Oct 2010 05:42:52 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <9303FD38-7283-40FF-BF51-B2504CCDDFA7@gmail.com>
References: <C8D39A81.C7AF%ggiesen@akn.ca>
	<B38D4D8F-9EBD-410A-97B7-28041A618D92@delong.com>
	<4CAE2B9A.6040101@chl.com>
	<5025F541-0BBC-4EAF-A5E7-8B9A47F38685@delong.com>
	<4CB17735.2050403@chl.com>
	<6BCFA1B9-2F20-440D-8105-7693D8F16909@delong.com>
	<9303FD38-7283-40FF-BF51-B2504CCDDFA7@gmail.com>
Message-ID: <70A7E804-C0BC-491D-BE23-1A18C1126D37@delong.com>


On Oct 10, 2010, at 5:37 AM, Scott Leibrand wrote:

> 
> On Oct 10, 2010, at 8:27 AM, Owen DeLong <owen at delong.com> wrote:
> 
>> 
>> On Oct 10, 2010, at 1:20 AM, Joe Maimon wrote:
>> 
>>> 
>>> Is there any reason a large ISP might want more than one 6rd scheme?
>>> 
>> Not that I can think of, and, the real problem with 6rd is that it doesn't matter what
>> size ISP you are... From the tiniest to the largest, they all consume the same
>> messed up prefix size for the same number of end bits to the end site.
>> 
>> So even a tiny ISP with 100 customers, if they want to give /56s to their end sites
>> will still consume 56-32 = /24.
> 
> Well, if you only have one v4 prefix, you don't need 32 bits.  That only helps in the smallest cases though. 
> 
> -Scott

While I haven't done the crawl through the routing table to be sure, I would posit that the number
of ASNs advertising a single prefix is probably less than 1%.

If someone with more time on their hands cares to validate this, it would be an interesting number
to have.

Owen



From bill at herrin.us  Sun Oct 10 10:09:57 2010
From: bill at herrin.us (William Herrin)
Date: Sun, 10 Oct 2010 10:09:57 -0400
Subject: [arin-ppml] Controlling the IPv6 address consumption rate
Message-ID: <AANLkTik+5zsTzepnf40faZVgOxNF2OOeMt-3o4p2wLEw@mail.gmail.com>

On Sun, Oct 10, 2010 at 12:00 AM, Owen DeLong <owen at delong.com> wrote:
> Bill... See my previous post. End sites should get at least a
>/48... If you serve 20,000,000 end sites, you need 23 bits to
>define those customers. 48-23 is 25. The closest larger nibble
>boundary is 20. ?There are few enough providers serving
>20,000,000 subscribers that I don't see it as a problem.
>Most providers should probably get /28s with larger ones
>getting /24s and smaller ones getting /32s.

Hi Owen,

Let's dig into the math a little more and see what meaning we can
tease out. For anyone who wants to skip the analysis, jump to the last
two paragraphs.


First, IPv6's protocol design robs us of 64 bits. It's technically
possible to build a LAN on a non-/64 boundary but the tools for
dynamic addressing don't work right. So, for better or for worse we
shouldn't talk about 128 bits of host addresses but rather 64 bits of
LAN addresses.

You believe ISPs should preemptively assign 16 bits of LAN addresses
to end sites, even residential customers with a PC or two. Let's set
the upper bound there. I've heard a couple rationales for this. One is
that we'll almost never need to assign more to an end site, so /48
gives us a uniform size for automating the address management process.
Another is that whatever we do assign, networks which grow beyond it
will want additional addresses without renumbering out of their old
ones. Minimizing the number of organizations which need additional
addresses will keep our interior routing tables small.

The lower bound for preemptive assignments appears to be 4 bits.
Assigning only one /64 will cause obvious problems - we can
demonstrate routine uses of 2 and 3 subnets in the home even today and
4 bits allows growth to 16 such subnets. More, nibble boundaries
follow IPv6's design well, minimizing the likely human error when
configuring all those users.

In a previous email you stated that an ISP with 20M customers should
receive a /16, or 32 bits more than their downstream assignment you
recommended at /48. As I understand it, this allows flexibility with
hierarchic routing designs that swap address space for routing slots.
However, we have examples of technology, like 6rd, which will usefully
cause the ISP to consume 33 bits despite their size - 32 bits for 6rd
and separate space for native. Ideally we want nibble boundaries too,
pushing the upper bound for the ISP's consumption lying between
allocation and assignment to an upper bound of 36 bits.

On the other hand, 20M customers will consume at least 25 bits of
assignments. 25 bits is 32M, 24 bits is only 16M.Given networking
inefficiencies, it would be irresponsible not to add at least one bit
to that, so figure 26 bits as a lower bound for tolerable network
design for an ISP with 20M users.

7 billion people in the world, each of which consumes Internet
service, so as a lower bound we'll need 9 bits worth of 20M-equivalent
ISPs to serve them.

The upper bound recognizes that these users have multiple ISPs -- for
their mobile phone, their home, their work. Maybe soon for their
electric meter, their car, etc. Better figure 12 bits worth of 20M-ISP
equivalents.

Finally, we need to hold some bits against the development of new
technologies which use IPv6 differently. We were blindsided in the
ARIN region by 6rd. Perhaps we shouldn't get caught with our pants
down again. Provide an upper bound of 8 bits so that ISPs don't have
to run back to us next time. Lower bound of 4 bits because really, it
would be irresponsible not to include at least some padding.

Sum it:

Upper bound: 64 + 16 + 36 + 12 + 8 = 136 bits.
Lower bound: 64 + 4  + 26 + 9 + 4 = 107 bits.

Now, that's interesting. 136 bits is well over two orders of magnitude
more addresses than we actually have. Three orders more if you
consider only the /3 allocated to the public Internet. This tells us
that we do have to pay at least some attention to IPv6 consumption
rates. The bits aren't as infinite as they at first appear.

Let's see if we can tease out some more instructive meaning. Back down
the number of ISPs needed to serve the world and let's look at only a
single 20M-user ISP again. Today, that ISP requests and receives a /8
of IPv4 space, or about 0.4% of IPv4's total addresses. And we
basically understand consumption rates under that model.

Our upper bound puts the same ISP consuming /4's of IPv6 space, or 6%
of IPv6's address space. That's obviously not a helpful angle, so lets
start at the lower bound and work our way back up instead.

The lower bound requires the 20M user ISP to consume at least a /30.
Take away the /8 we know it consumes in IPv4 and we're left with 22
bits. This means we have a grand total of 22 bits available to fulfill
two criteria:

1. Slowing the IPv6 consumption rate below that of IPv4.
2. Increasing allocations and assignments from the lower bound numbers
for convenience's sake.


ARIN's current model basically puts all 22 bits into responsibly slow
consumption leaving little left over for convenience.

With the 6rd proposal, we've seen a reasonably compelling case for
splitting the 22 bits between 4 bits of convenience and 18 bits of
responsibly slow consumption.

In light of a couple French and German allocations, RIPE has
apparently joined the race to the bottom with 11 bits of convenience
and only 11 bits of responsibly slow consumption.

In prior comments, Owen, you suggest what boils down to 14 bits of
convenience and a mere 8 bits of responsibly slow consumption.



So, I put it to everybody else: how should we divvy up the 22 bits
between IPv4's consumption rate and IPv6's minimum needful consumption
rate? How many bits of convenience and how many bits of responsibly
slow consumption?

We already know we don't have enough bits to apply them everywhere
they'd be nice to have. Once we know how many bits we want to save for
responsibly slow consumption we can look at the evolving choice of
where exactly the convenience bits offer the best bang for the buck.

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  Sun Oct 10 12:08:36 2010
From: owen at delong.com (Owen DeLong)
Date: Sun, 10 Oct 2010 09:08:36 -0700
Subject: [arin-ppml] Controlling the IPv6 address consumption rate
In-Reply-To: <AANLkTik+5zsTzepnf40faZVgOxNF2OOeMt-3o4p2wLEw@mail.gmail.com>
References: <AANLkTik+5zsTzepnf40faZVgOxNF2OOeMt-3o4p2wLEw@mail.gmail.com>
Message-ID: <2B6D8499-377A-40FF-8263-79C6A3BFD3AE@delong.com>


On Oct 10, 2010, at 7:09 AM, William Herrin wrote:

> On Sun, Oct 10, 2010 at 12:00 AM, Owen DeLong <owen at delong.com> wrote:
>> Bill... See my previous post. End sites should get at least a
>> /48... If you serve 20,000,000 end sites, you need 23 bits to
>> define those customers. 48-23 is 25. The closest larger nibble
>> boundary is 20.  There are few enough providers serving
>> 20,000,000 subscribers that I don't see it as a problem.
>> Most providers should probably get /28s with larger ones
>> getting /24s and smaller ones getting /32s.
> 
> Hi Owen,
> 
> Let's dig into the math a little more and see what meaning we can
> tease out. For anyone who wants to skip the analysis, jump to the last
> two paragraphs.
> 
OK...

> 
> First, IPv6's protocol design robs us of 64 bits. It's technically
> possible to build a LAN on a non-/64 boundary but the tools for
> dynamic addressing don't work right. So, for better or for worse we
> shouldn't talk about 128 bits of host addresses but rather 64 bits of
> LAN addresses.
> 
Rob is a strong term. I think that SLAAC is a good thing overall. I think
it's a worthwhile use of 64 bits, and, that it's not unlikely that without
it we'd be looking at a 64-bit IPv6 rather than 128 bits. In any case,
it is what it is and we're there.

> You believe ISPs should preemptively assign 16 bits of LAN addresses
> to end sites, even residential customers with a PC or two. Let's set
> the upper bound there. I've heard a couple rationales for this. One is
> that we'll almost never need to assign more to an end site, so /48
> gives us a uniform size for automating the address management process.
> Another is that whatever we do assign, networks which grow beyond it
> will want additional addresses without renumbering out of their old
> ones. Minimizing the number of organizations which need additional
> addresses will keep our interior routing tables small.
> 
Right.

> The lower bound for preemptive assignments appears to be 4 bits.
> Assigning only one /64 will cause obvious problems - we can
> demonstrate routine uses of 2 and 3 subnets in the home even today and
> 4 bits allows growth to 16 such subnets. More, nibble boundaries
> follow IPv6's design well, minimizing the likely human error when
> configuring all those users.
> 
Additionally, nibble boundaries facilitate rDNS delegations.

> In a previous email you stated that an ISP with 20M customers should
> receive a /16, or 32 bits more than their downstream assignment you
> recommended at /48. As I understand it, this allows flexibility with
> hierarchic routing designs that swap address space for routing slots.
> However, we have examples of technology, like 6rd, which will usefully
> cause the ISP to consume 33 bits despite their size - 32 bits for 6rd
> and separate space for native. Ideally we want nibble boundaries too,
> pushing the upper bound for the ISP's consumption lying between
> allocation and assignment to an upper bound of 36 bits.
> 
We really should be regarding 6rd as a temporary and very limited
technology. I would oppose facilitating /48s in 6rd because of the
vast amount of inefficiency of the 6rd protocol. I think that /56s are
pretty much the only rational end-site result under 6rd.

I actually would suggest ISPs doing 6rd should get that from a
completely separate address space than their native IPv6 space
and that all 6rd allocations should, ideally, come from a separate
address space at the RIR level to facilitate a subsequent community
decision to deprecate it.

I really think we should avoid damaging native deployment because
we are concerned about use for 6rd. That's a very long term consequence
for a relatively short term pragmatism.

> On the other hand, 20M customers will consume at least 25 bits of
> assignments. 25 bits is 32M, 24 bits is only 16M.Given networking
> inefficiencies, it would be irresponsible not to add at least one bit
> to that, so figure 26 bits as a lower bound for tolerable network
> design for an ISP with 20M users.
> 
I think that's what I said. Further, I felt that rounding to a nibble was
a practical consideration, so, I went to 28. 48 - 28 = 20, so, /20
was my suggestion as a minimum with the possible result of
/16 in extreme cases.

> 7 billion people in the world, each of which consumes Internet
> service, so as a lower bound we'll need 9 bits worth of 20M-equivalent
> ISPs to serve them.
> 
Not quite...

People don't map directly to end sites. First, most people will be members
of multiple end sites... Work, home, public access networks, etc.
Second, most end sites incorporate multiple people. (average household
size is, IIRC, 2.8 people). Households, businesses, organizations,
public access networks, etc., all have multiple people among their
address consumers.

So, 7 billion people translates to ~2.5 billion households and probably
about 1 billion other forms of end sites. For convenience, we can round
that up to ~4.2 billion total end sites.

4,200,000,000 / 20,000,000 = 210 = 8 bits worth of 20M-equivalent
ISPs. However, it won't actually work out that way. The vast majority
of ISPs will be much smaller and there will be many more of them.

> The upper bound recognizes that these users have multiple ISPs -- for
> their mobile phone, their home, their work. Maybe soon for their
> electric meter, their car, etc. Better figure 12 bits worth of 20M-ISP
> equivalents.
> 
I think the math I did above produces a more accurate analysis, but, if
you can make a more detailed analysis that you think is better, I'm
open to reviewing it.

> Finally, we need to hold some bits against the development of new
> technologies which use IPv6 differently. We were blindsided in the
> ARIN region by 6rd. Perhaps we shouldn't get caught with our pants
> down again. Provide an upper bound of 8 bits so that ISPs don't have
> to run back to us next time. Lower bound of 4 bits because really, it
> would be irresponsible not to include at least some padding.
> 
> Sum it:
> 
> Upper bound: 64 + 16 + 36 + 12 + 8 = 136 bits.
> Lower bound: 64 + 4  + 26 + 9 + 4 = 107 bits.
> 
This is only true if you assume that EVERY ISP requires the same
number of bits and that the distribution is even. The real world
doesn't work that way.

> Now, that's interesting. 136 bits is well over two orders of magnitude
> more addresses than we actually have. Three orders more if you
> consider only the /3 allocated to the public Internet. This tells us
> that we do have to pay at least some attention to IPv6 consumption
> rates. The bits aren't as infinite as they at first appear.
> 
I've never suggested otherwise. Hence my opposition to both 6rd
proposals as they were written and my call for protections in the
6rd proposals before I could support them.

> Let's see if we can tease out some more instructive meaning. Back down
> the number of ISPs needed to serve the world and let's look at only a
> single 20M-user ISP again. Today, that ISP requests and receives a /8
> of IPv4 space, or about 0.4% of IPv4's total addresses. And we
> basically understand consumption rates under that model.
> 
Actually, they'd get at least a /7.

> Our upper bound puts the same ISP consuming /4's of IPv6 space, or 6%
> of IPv6's address space. That's obviously not a helpful angle, so lets
> start at the lower bound and work our way back up instead.
> 
Your upper bound.. My upper bound had them at /20, or, perhaps /16.

> The lower bound requires the 20M user ISP to consume at least a /30.
> Take away the /8 we know it consumes in IPv4 and we're left with 22
> bits. This means we have a grand total of 22 bits available to fulfill
> two criteria:
> 
I don't follow your relationship here between IPv4 and IPv6. It seems
illogical to me.

> 1. Slowing the IPv6 consumption rate below that of IPv4.
> 2. Increasing allocations and assignments from the lower bound numbers
> for convenience's sake.
> 
> 
> ARIN's current model basically puts all 22 bits into responsibly slow
> consumption leaving little left over for convenience.
> 
So, we agree that the current model is flawed.. That's a good starting point
even if we arrived there via radically different paths.

> With the 6rd proposal, we've seen a reasonably compelling case for
> splitting the 22 bits between 4 bits of convenience and 18 bits of
> responsibly slow consumption.
> 
Not as compelling to me as you believe, and certainly I am not convinced
of the 4 bit point.

> In light of a couple French and German allocations, RIPE has
> apparently joined the race to the bottom with 11 bits of convenience
> and only 11 bits of responsibly slow consumption.
> 
I think characterizing this as a race to the bottom is neither accurate
nor useful.

> In prior comments, Owen, you suggest what boils down to 14 bits of
> convenience and a mere 8 bits of responsibly slow consumption.
> 
If you say so... Your characterizations still don't entirely make sense
to me, so, it's hard to argue the coefficients when the terms that
the coefficients are supposed to quantify are still vague.
> 
> 
> So, I put it to everybody else: how should we divvy up the 22 bits
> between IPv4's consumption rate and IPv6's minimum needful consumption
> rate? How many bits of convenience and how many bits of responsibly
> slow consumption?
> 
_IF_ I understand what you mean by these terms correctly, then, yes,
I think an 8/14 ratio isn't such a bad ratio (although I am not completely
convinced that is the accurate ratio in the current situation as I stated
above).

> We already know we don't have enough bits to apply them everywhere
> they'd be nice to have. Once we know how many bits we want to save for
> responsibly slow consumption we can look at the evolving choice of
> where exactly the convenience bits offer the best bang for the buck.
> 
We get a LOT of bits back if we make sure we plan to deprecate 6rd when
it is no longer necessary. Hence my claim that this should be a critical
part of ANY 6rd policy or plan.

Owen



From owen at delong.com  Sun Oct 10 12:20:08 2010
From: owen at delong.com (Owen DeLong)
Date: Sun, 10 Oct 2010 09:20:08 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <BBC8CE85-7892-4733-8EAD-16EA36A7CAAB@gmail.com>
References: <C8D39A81.C7AF%ggiesen@akn.ca>
	<B38D4D8F-9EBD-410A-97B7-28041A618D92@delong.com>
	<4CAE2B9A.6040101@chl.com>
	<5025F541-0BBC-4EAF-A5E7-8B9A47F38685@delong.com>
	<4CB17735.2050403@chl.com>
	<6BCFA1B9-2F20-440D-8105-7693D8F16909@delong.com>
	<9303FD38-7283-40FF-BF51-B2504CCDDFA7@gmail.com>
	<70A7E804-C0BC-491D-BE23-1A18C1126D37@delong.com>
	<BBC8CE85-7892-4733-8EAD-16EA36A7CAAB@gmail.com>
Message-ID: <C582CC98-9AE0-43B8-82B1-B3F7943BEE08@delong.com>


On Oct 10, 2010, at 9:07 AM, Kris Foster wrote:

> 
> On Oct 10, 2010, at 5:42 AM, Owen DeLong wrote:
> 
>> 
>> On Oct 10, 2010, at 5:37 AM, Scott Leibrand wrote:
>> 
>>> 
>>> On Oct 10, 2010, at 8:27 AM, Owen DeLong <owen at delong.com> wrote:
>>> 
>>>> 
>>>> On Oct 10, 2010, at 1:20 AM, Joe Maimon wrote:
>>>> 
>>>>> 
>>>>> Is there any reason a large ISP might want more than one 6rd scheme?
>>>>> 
>>>> Not that I can think of, and, the real problem with 6rd is that it doesn't matter what
>>>> size ISP you are... From the tiniest to the largest, they all consume the same
>>>> messed up prefix size for the same number of end bits to the end site.
>>>> 
>>>> So even a tiny ISP with 100 customers, if they want to give /56s to their end sites
>>>> will still consume 56-32 = /24.
>>> 
>>> Well, if you only have one v4 prefix, you don't need 32 bits.  That only helps in the smallest cases though. 
>>> 
>>> -Scott
>> 
>> While I haven't done the crawl through the routing table to be sure, I would posit that the number
>> of ASNs advertising a single prefix is probably less than 1%.
>> 
>> If someone with more time on their hands cares to validate this, it would be an interesting number
>> to have.
> 
> Total ASes present in the Internet Routing Table:                 34937
> Origin ASes announcing only one prefix:                           14711
> 
> (Philip Smith seems to email his routing table analysis everywhere except here)
> 
Sorry... I should have been more clear...

I would posit that the number of ISP ASNs advertising a single prefix is probably less than 1%.

The numbers above reflect ALL ASNs, not ISPs alone.

Owen

> --
> kris



From jmaimon at chl.com  Sun Oct 10 12:49:47 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Sun, 10 Oct 2010 12:49:47 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <6BCFA1B9-2F20-440D-8105-7693D8F16909@delong.com>
References: <C8D39A81.C7AF%ggiesen@akn.ca>
	<B38D4D8F-9EBD-410A-97B7-28041A618D92@delong.com>
	<4CAE2B9A.6040101@chl.com>
	<5025F541-0BBC-4EAF-A5E7-8B9A47F38685@delong.com>
	<4CB17735.2050403@chl.com>
	<6BCFA1B9-2F20-440D-8105-7693D8F16909@delong.com>
Message-ID: <4CB1EEAB.1040504@chl.com>



Owen DeLong wrote:
> On Oct 10, 2010, at 1:20 AM, Joe Maimon wrote:
>
>    
>> Is there any reason a large ISP might want more than one 6rd scheme?
>>
>>      
> Not that I can think of, and, the real problem with 6rd is that it doesn't matter what
> size ISP you are... From the tiniest to the largest, they all consume the same
> messed up prefix size for the same number of end bits to the end site.
>
> So even a tiny ISP with 100 customers, if they want to give /56s to their end sites
> will still consume 56-32 = /24.
>
> Owen
>
>
>    
What about traffic engineering? It would be a lot nicer if return trip 
to my users could deterministically stay within region.

Joe


From jmaimon at chl.com  Sun Oct 10 12:53:20 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Sun, 10 Oct 2010 12:53:20 -0400
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <8B5E8607-7FBE-4F36-8465-9EEBDE7BA5CB@delong.com>
References: <C8D4BDBC.C834%ggiesen@akn.ca>	<0FC11925-7D95-48B2-BEB7-E86B3AC062F5@cisco.com>	<3DAD3390-67BB-40A2-9B38-6BE347C76AAE@delong.com>	<AANLkTinKgj_7CFRKHp-wH7EkVg9mQAHaAKTts=vOwjrt@mail.gmail.com>	<08DFE069-C69C-4F1B-9C22-95DC23C61E65@delong.com>	<AANLkTim_3funAh=TgenrHQC3Q5H7kq1YMQVMBFarCF8a@mail.gmail.com>
	<F2A4D3F8-4269-40DD-9B6F-2C4AE8E6D664@delong.com>
	<4CB1797C.8000202@chl.com>
	<8B5E8607-7FBE-4F36-8465-9EEBDE7BA5CB@delong.com>
Message-ID: <4CB1EF80.2080309@chl.com>



Owen DeLong wrote:
>    
> That ship really has sailed. SLAAC is deployed, people are using it. Breaking SLAAC would
> be a bad thing.
>
>    
Fixing slaac would be a good thing. Its absurd to allow something barely 
a decade old control the next several. If it is still a good idea, keep 
it, if it is a better idea to modify it, do it.
>    
> I'm not sure what you mean by apipa, but, no, 16 bits isn't sufficient for a stateless scheme.
>    

It works now. It can work better with more but it does not necessarily 
require 64.

> It doesn't get much more flexible than SLAAC except for the requirement for EUI-64 based
> end system identifiers.
>    
Does this requirement bear out in anything other than slaac?
>    
>> In other words, pdv6 would have to ripple up the chain and cause subnet shortening on the fly all the way up in order to be fully robust.
>>
>>      
> Now you're throwing random technologies in a blender and postulating what comes out.
>
> DHCPv6 PD does actually allow for shortening on the fly as you describe, but, most implementations
> don't. However, the problem is that if the shortened result is the CPE->ISP router requesting a
> prefix larger than the ISP can or will give, it doesn't matter how much dynamic shortening occurred
> or not.
>
> Owen
>
>
>    
If shortening smaller than 64 was available, it would be much more 
robust, regardless of what was available >64 from the ISP. It would work 
at least as well as apipa for another 48 bits, which is quite deep 
hierarchically.

Joe


From sob at sobco.com  Sun Oct 10 13:12:21 2010
From: sob at sobco.com (Scott O. Bradner)
Date: Sun, 10 Oct 2010 13:12:21 -0400
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <4CB1EF80.2080309@chl.com>
References: <C8D4BDBC.C834%ggiesen@akn.ca>	<0FC11925-7D95-48B2-BEB7-E86B3AC062F5@cisco.com>	<3DAD3390-67BB-40A2-9B38-6BE347C76AAE@delong.com>	<AANLkTinKgj_7CFRKHp-wH7EkVg9mQAHaAKTts=vOwjrt@mail.gmail.com>	<08DFE069-C69C-4F1B-9C22-95DC23C61E65@delong.com>	<AANLkTim_3funAh=TgenrHQC3Q5H7kq1YMQVMBFarCF8a@mail.gmail.com>
	<F2A4D3F8-4269-40DD-9B6F-2C4AE8E6D664@delong.com>
	<4CB1797C.8000202@chl.com>
	<8B5E8607-7FBE-4F36-8465-9EEBDE7BA5CB@delong.com>
	<4CB1EF80.2080309@chl.com>
Message-ID: <18CC6A74-6B2F-4663-A7CA-A2C181938EEA@sobco.com>


On Oct 10, 2010, at 12:53 PM, Joe Maimon wrote:

> Fixing slaac would be a good thing. Its absurd to allow something barely a decade old control the next several. If it is still a good idea, keep it, if it is a better idea to modify it, do it.

"fixing SLAAC" is not within ARIN's scope - it is within the scope of the IETF
 the Area Directors of the IETF Internet Area would be a good place to start - see
http://datatracker.ietf.org/wg/

scott

From owen at delong.com  Sun Oct 10 13:58:56 2010
From: owen at delong.com (Owen DeLong)
Date: Sun, 10 Oct 2010 10:58:56 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CB1EEAB.1040504@chl.com>
References: <C8D39A81.C7AF%ggiesen@akn.ca>
	<B38D4D8F-9EBD-410A-97B7-28041A618D92@delong.com>
	<4CAE2B9A.6040101@chl.com>
	<5025F541-0BBC-4EAF-A5E7-8B9A47F38685@delong.com>
	<4CB17735.2050403@chl.com>
	<6BCFA1B9-2F20-440D-8105-7693D8F16909@delong.com>
	<4CB1EEAB.1040504@chl.com>
Message-ID: <198BDD6D-7DBA-4DA5-8F4A-517ED6382DD9@delong.com>


On Oct 10, 2010, at 9:49 AM, Joe Maimon wrote:

> 
> 
> Owen DeLong wrote:
>> On Oct 10, 2010, at 1:20 AM, Joe Maimon wrote:
>> 
>>   
>>> Is there any reason a large ISP might want more than one 6rd scheme?
>>> 
>>>     
>> Not that I can think of, and, the real problem with 6rd is that it doesn't matter what
>> size ISP you are... From the tiniest to the largest, they all consume the same
>> messed up prefix size for the same number of end bits to the end site.
>> 
>> So even a tiny ISP with 100 customers, if they want to give /56s to their end sites
>> will still consume 56-32 = /24.
>> 
>> Owen
>> 
>> 
>>   
> What about traffic engineering? It would be a lot nicer if return trip to my users could deterministically stay within region.
> 
> Joe

Permit me to rephrase... There is nothing that in my mind would justify the community
granting more than one 6rd prefix to an ISP, given the incredible waste inherent in the
first one. I would advocate that, instead, if you want to do TE with your 6rd, you should,
as an ISP, either disaggregate your 6rd prefix accordingly, or, you should move towards
a more native solution where you could get appropriate native allocations with much
less wastage.

Owen



From owen at delong.com  Sun Oct 10 14:09:19 2010
From: owen at delong.com (Owen DeLong)
Date: Sun, 10 Oct 2010 11:09:19 -0700
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <4CB1EF80.2080309@chl.com>
References: <C8D4BDBC.C834%ggiesen@akn.ca>	<0FC11925-7D95-48B2-BEB7-E86B3AC062F5@cisco.com>	<3DAD3390-67BB-40A2-9B38-6BE347C76AAE@delong.com>	<AANLkTinKgj_7CFRKHp-wH7EkVg9mQAHaAKTts=vOwjrt@mail.gmail.com>	<08DFE069-C69C-4F1B-9C22-95DC23C61E65@delong.com>	<AANLkTim_3funAh=TgenrHQC3Q5H7kq1YMQVMBFarCF8a@mail.gmail.com>
	<F2A4D3F8-4269-40DD-9B6F-2C4AE8E6D664@delong.com>
	<4CB1797C.8000202@chl.com>
	<8B5E8607-7FBE-4F36-8465-9EEBDE7BA5CB@delong.com>
	<4CB1EF80.2080309@chl.com>
Message-ID: <F0D91B39-2421-4A51-B1B2-AF6B72EAB98D@delong.com>


On Oct 10, 2010, at 9:53 AM, Joe Maimon wrote:

> 
> 
> Owen DeLong wrote:
>>   That ship really has sailed. SLAAC is deployed, people are using it. Breaking SLAAC would
>> be a bad thing.
>> 
>>   
> Fixing slaac would be a good thing. Its absurd to allow something barely a decade old control the next several. If it is still a good idea, keep it, if it is a better idea to modify it, do it.

It is still a good idea. It's not broken. I'm not in favor of "fixing" it.

>>   I'm not sure what you mean by apipa, but, no, 16 bits isn't sufficient for a stateless scheme.
>>   
> 
> It works now. It can work better with more but it does not necessarily require 64.

OK... I did a little bit of research. APIPA which you are holding out as a shining example
of address allocation is actually an almost completely useless technology. First, it is
only deployed today as a backstop for DHCP server failure, and, even then, it doesn't
work to provide useful network services in the vast majority of cases. Second, it has
serious scaling limitations and depends on all hosts having not only the same host
identifier, but, also the same prefix. It provides no mechanism for learning default
router and has no facility to support dynamic renumbering, prefix assignment, or
multiple addresses per host. All of these things are supported in SLAAC and without
the scaling limitations of APIPA.

For those that, like me, were unfamiliar with the term APIPA prior to this discussion,
APIPA is the formal name (Automatic Private IP Addressiing) for what happens on
a DHCP managed interface when it fails to get an address and assigns some
random number from 169.254/16 and validates uniqueness through ARP.

>> It doesn't get much more flexible than SLAAC except for the requirement for EUI-64 based
>> end system identifiers.
>>   
> Does this requirement bear out in anything other than slaac?

To my knowledge, noone has proposed an alternative stateless address allocation scheme.
If you have one, I'd need to see the details in order to judge the merits.

>>   
>>> In other words, pdv6 would have to ripple up the chain and cause subnet shortening on the fly all the way up in order to be fully robust.
>>> 
>>>     
>> Now you're throwing random technologies in a blender and postulating what comes out.
>> 
>> DHCPv6 PD does actually allow for shortening on the fly as you describe, but, most implementations
>> don't. However, the problem is that if the shortened result is the CPE->ISP router requesting a
>> prefix larger than the ISP can or will give, it doesn't matter how much dynamic shortening occurred
>> or not.
>> 
>> Owen
>> 
>> 
>>   
> If shortening smaller than 64 was available, it would be much more robust, regardless of what was available >64 from the ISP. It would work at least as well as apipa for another 48 bits, which is quite deep hierarchically.
> 
APIPA doesn't work for meaningful regular internet communications. You can't deploy an
enterprise numbered with APIPA. Suggesting it as an alternative for SLAAC is like
suggesting RIP as an alternative for BGP in the network core.

Owen



From jmaimon at chl.com  Sun Oct 10 14:45:08 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Sun, 10 Oct 2010 14:45:08 -0400
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <18CC6A74-6B2F-4663-A7CA-A2C181938EEA@sobco.com>
References: <C8D4BDBC.C834%ggiesen@akn.ca>	<0FC11925-7D95-48B2-BEB7-E86B3AC062F5@cisco.com>	<3DAD3390-67BB-40A2-9B38-6BE347C76AAE@delong.com>	<AANLkTinKgj_7CFRKHp-wH7EkVg9mQAHaAKTts=vOwjrt@mail.gmail.com>	<08DFE069-C69C-4F1B-9C22-95DC23C61E65@delong.com>	<AANLkTim_3funAh=TgenrHQC3Q5H7kq1YMQVMBFarCF8a@mail.gmail.com>
	<F2A4D3F8-4269-40DD-9B6F-2C4AE8E6D664@delong.com>
	<4CB1797C.8000202@chl.com>
	<8B5E8607-7FBE-4F36-8465-9EEBDE7BA5CB@delong.com>
	<4CB1EF80.2080309@chl.com>
	<18CC6A74-6B2F-4663-A7CA-A2C181938EEA@sobco.com>
Message-ID: <4CB209B4.1010800@chl.com>



Scott O. Bradner wrote:
> On Oct 10, 2010, at 12:53 PM, Joe Maimon wrote:
>
>    
>> Fixing slaac would be a good thing. Its absurd to allow something barely a decade old control the next several. If it is still a good idea, keep it, if it is a better idea to modify it, do it.
>>      
> "fixing SLAAC" is not within ARIN's scope - it is within the scope of the IETF
>   the Area Directors of the IETF Internet Area would be a good place to start - see
> http://datatracker.ietf.org/wg/
>
> scott
>
>    

Our collective insistence on this rigid categorization and demarcation 
is a bit ridiculous and produces ridiculous results more often than 
should be tolerated.

Policy needs to take design into account,  but design needs to do the 
same. Suppose policy was that utilization could only be justified at one 
/64 per household. You dont think design might come around and fix 
things up or adapt to policy and operator practices instead of rigidly 
the other way? Isnt that what happened with CIDR and with NAT? There has 
to be proper give and take, instead of this sort of deadlock.

I consider 240/4 to be another example of this tragic comedy.

I would like to see more official liason work between protocol and 
application designers, operators and policy bodies. The issue is broader 
than just this forum.

 From an informal outsider approach, the root of the 64 bit requirement 
seems to be in

rfc4291 2.5.1

    For all unicast addresses, except those that start with the binary
    value 000, Interface IDs are required to be 64 bits long and to be
    constructed in Modified EUI-64 format.

And this is already no longer true in almost any implementation.

This is way OT, so I would welcome further replies on this tangent off-list.
.

Joe


From jmaimon at chl.com  Sun Oct 10 14:49:07 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Sun, 10 Oct 2010 14:49:07 -0400
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <F0D91B39-2421-4A51-B1B2-AF6B72EAB98D@delong.com>
References: <C8D4BDBC.C834%ggiesen@akn.ca>	<0FC11925-7D95-48B2-BEB7-E86B3AC062F5@cisco.com>	<3DAD3390-67BB-40A2-9B38-6BE347C76AAE@delong.com>	<AANLkTinKgj_7CFRKHp-wH7EkVg9mQAHaAKTts=vOwjrt@mail.gmail.com>	<08DFE069-C69C-4F1B-9C22-95DC23C61E65@delong.com>	<AANLkTim_3funAh=TgenrHQC3Q5H7kq1YMQVMBFarCF8a@mail.gmail.com>
	<F2A4D3F8-4269-40DD-9B6F-2C4AE8E6D664@delong.com>
	<4CB1797C.8000202@chl.com>
	<8B5E8607-7FBE-4F36-8465-9EEBDE7BA5CB@delong.com>
	<4CB1EF80.2080309@chl.com>
	<F0D91B39-2421-4A51-B1B2-AF6B72EAB98D@delong.com>
Message-ID: <4CB20AA3.2000405@chl.com>



Owen DeLong wrote:
> On Oct 10, 2010, at 9:53 AM, Joe Maimon wrote:
>
>>      
> APIPA doesn't work for meaningful regular internet communications. You can't deploy an
> enterprise numbered with APIPA. Suggesting it as an alternative for SLAAC is like
> suggesting RIP as an alternative for BGP in the network core.
>
> Owen
>
>
>    

Apipa is an example of auto configuration with dad. In 16 bits. Shining, 
it is not. Functional, it is.  It is part of zeroconf which comes with 
multicast DNS as well as other things. Apple makes extensive use of 
this. It is obviously not intended for a routed managed environment, 
useful only on an ad-hoc basis.

apipa is judged to only be useful when no routing is available, by way 
of static configuration or dhcp on that interface. In that same vein, 
slaac is a useless bit of technology when presented with the ubiquitous 
coupling of dhcp servers inside of routers.

In my view 64 bit subnet sizing hard coded in standards and protocols is 
a mistake. It should be fixed if possible, or it can be made irrelevant 
by subsequent technology, such as DHCP.


Joe




From jmaimon at chl.com  Sun Oct 10 14:53:16 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Sun, 10 Oct 2010 14:53:16 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <198BDD6D-7DBA-4DA5-8F4A-517ED6382DD9@delong.com>
References: <C8D39A81.C7AF%ggiesen@akn.ca>
	<B38D4D8F-9EBD-410A-97B7-28041A618D92@delong.com>
	<4CAE2B9A.6040101@chl.com>
	<5025F541-0BBC-4EAF-A5E7-8B9A47F38685@delong.com>
	<4CB17735.2050403@chl.com>
	<6BCFA1B9-2F20-440D-8105-7693D8F16909@delong.com>
	<4CB1EEAB.1040504@chl.com>
	<198BDD6D-7DBA-4DA5-8F4A-517ED6382DD9@delong.com>
Message-ID: <4CB20B9C.1020707@chl.com>



Owen DeLong wrote:
> On Oct 10, 2010, at 9:49 AM, Joe Maimon wrote:
>
>    
>>      
>>>
>>>
>>>        
>> What about traffic engineering? It would be a lot nicer if return trip to my users could deterministically stay within region.
>>
>> Joe
>>      
> Permit me to rephrase... There is nothing that in my mind would justify the community
> granting more than one 6rd prefix to an ISP, given the incredible waste inherent in the
> first one. I would advocate that, instead, if you want to do TE with your 6rd, you should,
> as an ISP, either disaggregate your 6rd prefix accordingly, or, you should move towards
> a more native solution where you could get appropriate native allocations with much
> less wastage.
>
> Owen
>
>
>    

We agree. My point was that 6rd can open the door to even larger than 
/16 allocations. And all because of the excellent idea to store protocol 
dataset inside of ipv6 128 bits of register^W address space. TE bits 
would come on top of that.

Joe


From cgrundemann at gmail.com  Sun Oct 10 15:39:25 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Sun, 10 Oct 2010 13:39:25 -0600
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D030879153D6@ex1.cait.wustl.edu>
References: <AANLkTingLkZsMdyiQQJo8pz0h3DDBiTYd0gU9n7jTRhV@mail.gmail.com>
	<AANLkTikfOmmJsUxcqsTQUrUo_GscX=2sZfNr0DicRcvP@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D030879153D6@ex1.cait.wustl.edu>
Message-ID: <AANLkTi=LBL_k0Bmo-DHRFu4khAArD6vWLzDt589PUxNE@mail.gmail.com>

On Sun, Oct 10, 2010 at 06:05, Bill Darte <BillD at cait.wustl.edu> wrote:
> Chris,
>
> As you know, at our lunch table discussion 'fighting over the crumbs of v4',
> I made mention that I believed it was beyond the scope of ARIN's mission to
> 'mandate a business practice change' like requiring v6 implementation as a
> condition of receiving future v4 allocations.

And I argue that ARIN policy already dictates business practice
through needs based assignment/allocation based on efficient
utilization.

> In a brief discussion about the legality of such....I now believe(or
> interpret what I heard) that ARIN might arguably do this without undue
> risk....

I'm sorry - does that say that you now believe ARIN *can* do this
without risk or can *not* do this without risk? Could you provide any
more detail?

> FYI...

Thanks,
~Chris

>
> bd
> _______________________________________________
> 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 BillD at cait.wustl.edu  Sun Oct 10 16:37:38 2010
From: BillD at cait.wustl.edu (Bill Darte)
Date: Sun, 10 Oct 2010 15:37:38 -0500
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
References: <AANLkTingLkZsMdyiQQJo8pz0h3DDBiTYd0gU9n7jTRhV@mail.gmail.com><AANLkTikfOmmJsUxcqsTQUrUo_GscX=2sZfNr0DicRcvP@mail.gmail.com><EACF8B735E9CBA4B8BAF9E4165D030879153D6@ex1.cait.wustl.edu>
	<AANLkTi=LBL_k0Bmo-DHRFu4khAArD6vWLzDt589PUxNE@mail.gmail.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D030879153D8@ex1.cait.wustl.edu>

could do this....or can...as you wish.


-----Original Message-----
From: Chris Grundemann [mailto:cgrundemann at gmail.com]
Sent: Sun 10/10/2010 2:39 PM
To: Bill Darte
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
 
On Sun, Oct 10, 2010 at 06:05, Bill Darte <BillD at cait.wustl.edu> wrote:
> Chris,
>
> As you know, at our lunch table discussion 'fighting over the crumbs of v4',
> I made mention that I believed it was beyond the scope of ARIN's mission to
> 'mandate a business practice change' like requiring v6 implementation as a
> condition of receiving future v4 allocations.

And I argue that ARIN policy already dictates business practice
through needs based assignment/allocation based on efficient
utilization.

> In a brief discussion about the legality of such....I now believe(or
> interpret what I heard) that ARIN might arguably do this without undue
> risk....

I'm sorry - does that say that you now believe ARIN *can* do this
without risk or can *not* do this without risk? Could you provide any
more detail?

> FYI...

Thanks,
~Chris

>
> bd
> _______________________________________________
> 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

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

From cgrundemann at gmail.com  Sun Oct 10 17:15:33 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Sun, 10 Oct 2010 15:15:33 -0600
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D030879153D8@ex1.cait.wustl.edu>
References: <AANLkTingLkZsMdyiQQJo8pz0h3DDBiTYd0gU9n7jTRhV@mail.gmail.com>
	<AANLkTikfOmmJsUxcqsTQUrUo_GscX=2sZfNr0DicRcvP@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D030879153D6@ex1.cait.wustl.edu>
	<AANLkTi=LBL_k0Bmo-DHRFu4khAArD6vWLzDt589PUxNE@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D030879153D8@ex1.cait.wustl.edu>
Message-ID: <AANLkTinzn8jWZO3qANDYg-D+iMMEqi4S5ucQQKMUxKbr@mail.gmail.com>

On Sun, Oct 10, 2010 at 14:37, Bill Darte <BillD at cait.wustl.edu> wrote:
> could do this....or can...as you wish.

I'll stick with can for now. =)   Thanks for clarifying Bill.

~Chris

>
> -----Original Message-----
> From: Chris Grundemann [mailto:cgrundemann at gmail.com]
> Sent: Sun 10/10/2010 2:39 PM
> To: Bill Darte
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
>
> On Sun, Oct 10, 2010 at 06:05, Bill Darte <BillD at cait.wustl.edu> wrote:
>> Chris,
>>
>> As you know, at our lunch table discussion 'fighting over the crumbs of
>> v4',
>> I made mention that I believed it was beyond the scope of ARIN's mission
>> to
>> 'mandate a business practice change' like requiring v6 implementation as a
>> condition of receiving future v4 allocations.
>
> And I argue that ARIN policy already dictates business practice
> through needs based assignment/allocation based on efficient
> utilization.
>
>> In a brief discussion about the legality of such....I now believe(or
>> interpret what I heard) that ARIN might arguably do this without undue
>> risk....
>
> I'm sorry - does that say that you now believe ARIN *can* do this
> without risk or can *not* do this without risk? Could you provide any
> more detail?
>
>> FYI...
>
> Thanks,
> ~Chris
>
>>
>> bd
>> _______________________________________________
>> 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  Sun Oct 10 19:51:11 2010
From: owen at delong.com (Owen DeLong)
Date: Sun, 10 Oct 2010 16:51:11 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CB20B9C.1020707@chl.com>
References: <C8D39A81.C7AF%ggiesen@akn.ca>
	<B38D4D8F-9EBD-410A-97B7-28041A618D92@delong.com>
	<4CAE2B9A.6040101@chl.com>
	<5025F541-0BBC-4EAF-A5E7-8B9A47F38685@delong.com>
	<4CB17735.2050403@chl.com>
	<6BCFA1B9-2F20-440D-8105-7693D8F16909@delong.com>
	<4CB1EEAB.1040504@chl.com>
	<198BDD6D-7DBA-4DA5-8F4A-517ED6382DD9@delong.com>
	<4CB20B9C.1020707@chl.com>
Message-ID: <32FD3ED0-C9C5-4E55-94CF-56AF6D7E54B0@delong.com>


On Oct 10, 2010, at 11:53 AM, Joe Maimon wrote:

> 
> 
> Owen DeLong wrote:
>> On Oct 10, 2010, at 9:49 AM, Joe Maimon wrote:
>> 
>>   
>>>     
>>>> 
>>>> 
>>>>       
>>> What about traffic engineering? It would be a lot nicer if return trip to my users could deterministically stay within region.
>>> 
>>> Joe
>>>     
>> Permit me to rephrase... There is nothing that in my mind would justify the community
>> granting more than one 6rd prefix to an ISP, given the incredible waste inherent in the
>> first one. I would advocate that, instead, if you want to do TE with your 6rd, you should,
>> as an ISP, either disaggregate your 6rd prefix accordingly, or, you should move towards
>> a more native solution where you could get appropriate native allocations with much
>> less wastage.
>> 
>> Owen
>> 
>> 
>>   
> 
> We agree. My point was that 6rd can open the door to even larger than /16 allocations. And all because of the excellent idea to store protocol dataset inside of ipv6 128 bits of register^W address space. TE bits would come on top of that.
> 
> Joe

Yes... If we do anything to facilitate 6rd, it is critical to treat whatever we do as a necessary
evil done for expediency in a time of urgency and not allow it to become any more entrenched
than absolutely necessary.

Owen



From owen at delong.com  Sun Oct 10 19:55:29 2010
From: owen at delong.com (Owen DeLong)
Date: Sun, 10 Oct 2010 16:55:29 -0700
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <4CB20AA3.2000405@chl.com>
References: <C8D4BDBC.C834%ggiesen@akn.ca>	<0FC11925-7D95-48B2-BEB7-E86B3AC062F5@cisco.com>	<3DAD3390-67BB-40A2-9B38-6BE347C76AAE@delong.com>	<AANLkTinKgj_7CFRKHp-wH7EkVg9mQAHaAKTts=vOwjrt@mail.gmail.com>	<08DFE069-C69C-4F1B-9C22-95DC23C61E65@delong.com>	<AANLkTim_3funAh=TgenrHQC3Q5H7kq1YMQVMBFarCF8a@mail.gmail.com>
	<F2A4D3F8-4269-40DD-9B6F-2C4AE8E6D664@delong.com>
	<4CB1797C.8000202@chl.com>
	<8B5E8607-7FBE-4F36-8465-9EEBDE7BA5CB@delong.com>
	<4CB1EF80.2080309@chl.com>
	<F0D91B39-2421-4A51-B1B2-AF6B72EAB98D@delong.com>
	<4CB20AA3.2000405@chl.com>
Message-ID: <91A8C1D0-9F01-4CAF-8ED1-9FEBC7B83C61@delong.com>


On Oct 10, 2010, at 11:49 AM, Joe Maimon wrote:

> 
> 
> Owen DeLong wrote:
>> On Oct 10, 2010, at 9:53 AM, Joe Maimon wrote:
>> 
>>>     
>> APIPA doesn't work for meaningful regular internet communications. You can't deploy an
>> enterprise numbered with APIPA. Suggesting it as an alternative for SLAAC is like
>> suggesting RIP as an alternative for BGP in the network core.
>> 
>> Owen
>> 
>> 
>>   
> 
> Apipa is an example of auto configuration with dad. In 16 bits. Shining, it is not. Functional, it is.  It is part of zeroconf which comes with multicast DNS as well as other things. Apple makes extensive use of this. It is obviously not intended for a routed managed environment, useful only on an ad-hoc basis.
> 
s/functional/dysfunctional/ and I would agree with you.

SLAAC is useful in a routed managed environment. APIPA is _NOT_ anywhere near suitable
as a  replacement.

> apipa is judged to only be useful when no routing is available, by way of static configuration or dhcp on that interface. In that same vein, slaac is a useless bit of technology when presented with the ubiquitous coupling of dhcp servers inside of routers.
> 
Ah, among other things, APIPA assumes the lack of static or DHCP configuration indicates a lcak
of routing availability which is an invalid and incorrect assumption and causes significant problems
in the real world.

> In my view 64 bit subnet sizing hard coded in standards and protocols is a mistake. It should be fixed if possible, or it can be made irrelevant by subsequent technology, such as DHCP.
> 
As others have said... The IETF lists are that away. ---->

Changing RFCs is completely outside of ARIN scope.

Owen



From christopher.morrow at gmail.com  Sun Oct 10 21:14:56 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Sun, 10 Oct 2010 21:14:56 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CB17735.2050403@chl.com>
References: <C8D39A81.C7AF%ggiesen@akn.ca>
	<B38D4D8F-9EBD-410A-97B7-28041A618D92@delong.com>
	<4CAE2B9A.6040101@chl.com>
	<5025F541-0BBC-4EAF-A5E7-8B9A47F38685@delong.com>
	<4CB17735.2050403@chl.com>
Message-ID: <AANLkTi=p_TpgSST+e-HRzcLVC6OFf99vV_Na=6_1Pwo+@mail.gmail.com>

On Sun, Oct 10, 2010 at 4:20 AM, Joe Maimon <jmaimon at chl.com> wrote:
>
> Is there any reason a large ISP might want more than one 6rd scheme?

a /28 is a rather large item... it should let them TE traffic decently
enough (inbound at least). I wonder though if the ipv4 mapped
addresses could end up with lots of odd internal traffic matrixes...
and thus smaller deployments could conserve intra-isp traffic
requirements?

Or maybe you can force traffic into native-v6 closer to the user edge
and cheat that way?

(overlay/encap technologies ... ick)
-chris


From mpetach at netflight.com  Sun Oct 10 23:28:52 2010
From: mpetach at netflight.com (Matthew Petach)
Date: Sun, 10 Oct 2010 20:28:52 -0700
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <AANLkTikfOmmJsUxcqsTQUrUo_GscX=2sZfNr0DicRcvP@mail.gmail.com>
References: <AANLkTingLkZsMdyiQQJo8pz0h3DDBiTYd0gU9n7jTRhV@mail.gmail.com>
	<AANLkTikfOmmJsUxcqsTQUrUo_GscX=2sZfNr0DicRcvP@mail.gmail.com>
Message-ID: <AANLkTimrcrSEZb9XLgAJor9sKzmj5w4SrgU8WG=H_PsJ@mail.gmail.com>

On Sat, Oct 9, 2010 at 12:34 PM, Chris Grundemann <cgrundemann at gmail.com> wrote:
> Let me offer a general response to all of the great feedback:
>
> The basic idea here is to redefine efficient utilization. The fact is
> that at this point (and for quite some time now) IPv4 addresses that
> are not deployed along with IPv6 addresses are simply not being
> efficiently utilized. Just like assigning a v4/24 to a PTP link is
> wasteful, deploying IPv4 only is wasteful.

I would argue that this is where the market will step in; this is a wonderful
opportunity for Transition Service Providers to help providers who are not
dual stacked get access to the portion of the Internet for which they do not
have direct, native connectivity.

Why use policy to try to shape an outcome that can be achieved through
normal market interplay, creating thousands of jobs in the process?

Deploying IPv4 only creates scarcity; scarcity drives up demand; higher
demand creates market opportunities (so long as we don't overly restrict
them); market opportunities allow new businesses to spring up to fulfill
the need, bringing new jobs into the sector.

Personally, I'm against a soft landing.  We did just fine when faced with
the hard deadline of Y2k; it created thousands of jobs for people working
to get things ready for doomsday.  Let's let the same situation work here;
as people become aware of the dual nature of the new internet, they'll
start clamoring for service providers who can do application gatewaying
for them, between the old and the new, or vice versa.  And given that
80% of the traffic these days is HTTP based, those translation service
providers will have a fairly easy time of it; just set up racks of Apache
Traffic Server boxes (http://en.wikipedia.org/wiki/Traffic_Server) that can
answer and proxy requests from both v4 and v6 on the front-and-back sides,
configure a DNS server that replies to all lookups for the "other" protocol
with the address of the trafficserver farm, and for most of the traffic, the
end site suddenly is able to see both the "old" internet and the "new"
internet.

Let's not try to wrap our heads too much around the idea of "fairness";
the market is driven by imbalances in resource allocation, and it's in
the transfer of unequally distributed resources that money is to be
made.

> Cheers,
> ~Chris
>
> "Those who do not create the future they want must endure the future they get."
> ~Draper L. Kaufman, Jr.

I'm voting to create a nice new internet boom, at least for the next several
years, by providing a wonderful market opportunity.  So, I'd have to say "no"
to the idea of trying to create any more of a soft landing than the
/10 transition
block already does.  I'm aiming to create a future that lets a few more
engineers become millionaires again, rather than endure a future of
ever-smaller crumb-splitting.

Matt


From marty at akamai.com  Mon Oct 11 01:13:19 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Mon, 11 Oct 2010 01:13:19 -0400
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <AANLkTimrcrSEZb9XLgAJor9sKzmj5w4SrgU8WG=H_PsJ@mail.gmail.com>
Message-ID: <C8D8152F.12CAC%marty@akamai.com>




On 10/10/10 11:28 PM, "Matthew Petach" <mpetach at netflight.com> wrote:

> On Sat, Oct 9, 2010 at 12:34 PM, Chris Grundemann <cgrundemann at gmail.com>
> wrote:
>> Let me offer a general response to all of the great feedback:
>> 
>> The basic idea here is to redefine efficient utilization. The fact is
>> that at this point (and for quite some time now) IPv4 addresses that
>> are not deployed along with IPv6 addresses are simply not being
>> efficiently utilized. Just like assigning a v4/24 to a PTP link is
>> wasteful, deploying IPv4 only is wasteful.
> 
> I would argue that this is where the market will step in; this is a wonderful
> opportunity for Transition Service Providers to help providers who are not
> dual stacked get access to the portion of the Internet for which they do not
> have direct, native connectivity.
> 
> Why use policy to try to shape an outcome that can be achieved through
> normal market interplay, creating thousands of jobs in the process?


So far, I found four jobs at one major job site and a few more on another,
some duplicate. :-) I searched for IPv6 news articles on [your favorite
search engine] and found them to be few and far between. I think that this
is indicative of the level of readiness our there with respect to v6 and
which is why I think that doing something is better than nothing.

I would think we'd all rather be wrong at the cost of a /8 or so vs. wrong
at the cost of a billion(s) of dollars and not necessarily the creation of
jobs. Seems like it could go either way depending upon who can buy v4
addresses to fund their transition ambition. If we create millionaries and
lots of jobs that would be great, but that sounds like a cliff scenario and
that would be fail IMHO.

I heard some interesting assertions on what addresses will cost post
depletion last week and nothing was convincing to the point where I thought
that $100 an address minimum was not unreasonable. Honestly, not sure which
way would be best. 

 
> Deploying IPv4 only creates scarcity; scarcity drives up demand; higher

Agreed. Demand drives up cost and we leave the middle guys in the house of
pain. At least it seems that way to me.

> demand creates market opportunities (so long as we don't overly restrict
> them); market opportunities allow new businesses to spring up to fulfill
> the need, bringing new jobs into the sector.
> 
> Personally, I'm against a soft landing.  We did just fine when faced with
> the hard deadline of Y2k; it created thousands of jobs for people working

y2k was overhyped IMHO. This has been under-hyped. YMMV!


Best,

-M<



From owen at delong.com  Mon Oct 11 01:15:31 2010
From: owen at delong.com (Owen DeLong)
Date: Sun, 10 Oct 2010 22:15:31 -0700
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <AANLkTimrcrSEZb9XLgAJor9sKzmj5w4SrgU8WG=H_PsJ@mail.gmail.com>
References: <AANLkTingLkZsMdyiQQJo8pz0h3DDBiTYd0gU9n7jTRhV@mail.gmail.com>
	<AANLkTikfOmmJsUxcqsTQUrUo_GscX=2sZfNr0DicRcvP@mail.gmail.com>
	<AANLkTimrcrSEZb9XLgAJor9sKzmj5w4SrgU8WG=H_PsJ@mail.gmail.com>
Message-ID: <AEB9883E-8836-46C7-8181-EC3FC1E2676D@delong.com>


On Oct 10, 2010, at 8:28 PM, Matthew Petach wrote:

> On Sat, Oct 9, 2010 at 12:34 PM, Chris Grundemann <cgrundemann at gmail.com> wrote:
>> Let me offer a general response to all of the great feedback:
>> 
>> The basic idea here is to redefine efficient utilization. The fact is
>> that at this point (and for quite some time now) IPv4 addresses that
>> are not deployed along with IPv6 addresses are simply not being
>> efficiently utilized. Just like assigning a v4/24 to a PTP link is
>> wasteful, deploying IPv4 only is wasteful.
> 
> I would argue that this is where the market will step in; this is a wonderful
> opportunity for Transition Service Providers to help providers who are not
> dual stacked get access to the portion of the Internet for which they do not
> have direct, native connectivity.
> 
> Why use policy to try to shape an outcome that can be achieved through
> normal market interplay, creating thousands of jobs in the process?
> 
Indeed, this approach has worked quite well as a job creation tactic
in the operating system world. Why hold Micr0$0ft accountable for their
security practices (or lack thereof) when you can, instead, let them
create a massive market for FUD and FUD-related products such as
anti-virus, anti-malware, firewalls, security suites, and vast numbers of
jobs writing various applications all intended to overcome the basic
shortcomings of their products?

Having watched from the sidelines as the industry poured buckets
of money into that pit, I have to say I don't really relish the thought
of repeating that exercise on the internet.

I'm not sure that this particular proposal is a great idea, but, I will say
that your "kill 'em all and let the market gods sort 'em out" analogy
definitely doesn't help the case for inaction.
> 
> 
> Let's not try to wrap our heads too much around the idea of "fairness";
> the market is driven by imbalances in resource allocation, and it's in
> the transfer of unequally distributed resources that money is to be
> made.
> 
In other words, since somebody can get rich from it, other peoples
pain is OK and should be encouraged. An interesting view of the
world.

Owen



From bicknell at ufp.org  Mon Oct 11 08:48:43 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 11 Oct 2010 05:48:43 -0700
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <91A8C1D0-9F01-4CAF-8ED1-9FEBC7B83C61@delong.com>
References: <AANLkTinKgj_7CFRKHp-wH7EkVg9mQAHaAKTts=vOwjrt@mail.gmail.com>
	<08DFE069-C69C-4F1B-9C22-95DC23C61E65@delong.com>
	<AANLkTim_3funAh=TgenrHQC3Q5H7kq1YMQVMBFarCF8a@mail.gmail.com>
	<F2A4D3F8-4269-40DD-9B6F-2C4AE8E6D664@delong.com>
	<4CB1797C.8000202@chl.com>
	<8B5E8607-7FBE-4F36-8465-9EEBDE7BA5CB@delong.com>
	<4CB1EF80.2080309@chl.com>
	<F0D91B39-2421-4A51-B1B2-AF6B72EAB98D@delong.com>
	<4CB20AA3.2000405@chl.com>
	<91A8C1D0-9F01-4CAF-8ED1-9FEBC7B83C61@delong.com>
Message-ID: <20101011124843.GA94891@ussenterprise.ufp.org>

In a message written on Sun, Oct 10, 2010 at 04:55:29PM -0700, Owen DeLong wrote:
> SLAAC is useful in a routed managed environment. APIPA is _NOT_ anywhere near suitable
> as a  replacement.

History begs to differ.

Back in the day there was this protocol called Appletalk.  It used
a 2 byte network number, and a one byte node number.  The network
number was learned from the routers in a procedure not unlike IPv6's
to learn the network number.  The node number though was chosen
entirely at random.  If there was a collision, the system chose
again, repeating until it had a free number.

I won't hold Appletalk up as a shining example of anything, but
there were some large deployments using a APIPA style random
assignment, using a very small number space, which worked just fine.

Back to the current day, IPv6 designers seemed to feel we were
moving to EUI-64's, and that fit nicely with the 64 bit boundary.
There are technologies that use EUI-64, but Ethernet is not one of
them yet.  It seems to me a lot of the 6rd problem could be solved
if we could use a /80 boundary for the local LAN.  Rather than use
EUI-64 on the LAN, EUI-48 (the MAC address directly) could be used.
Everything would work exactly the same as it does today (DAD, RA's,
DHCPv6, etc) only on the smallar address space.  Only some minor
changes need to be made so the host can detect if it is on a /64
or /80 boundary.

The result is that even giving 16 bits of subnet to the home 6rd
now fits in a /32 (128 - 48 - 16 - 32).  More importantly, an ISP
will only have in its routing table the portions of that /32
corresponding to their IPv4 infrastructure; all of the rest of it
can be used normally as native IPv6.  While this may mean a few of
the larger ISP's need more IPv6 space, for a lot of the smaller
guys they will have more than they need.

I realize this isn't the IETF list, but we keep trying to "fix"
problems with the 64 bits on the left side of the address, and that
still rubs me the wrong way.  Already ISP's have found why using a
/64 on your P2P interfaces is a bad idea and are using /126's and
/127's.  I find it hard to believe that advertising the prefix
length with the prefix would be that much harder, and could allow
flexability to solve most of these issues.

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

From owen at delong.com  Mon Oct 11 09:06:09 2010
From: owen at delong.com (Owen DeLong)
Date: Mon, 11 Oct 2010 06:06:09 -0700
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <20101011124843.GA94891@ussenterprise.ufp.org>
References: <AANLkTinKgj_7CFRKHp-wH7EkVg9mQAHaAKTts=vOwjrt@mail.gmail.com>
	<08DFE069-C69C-4F1B-9C22-95DC23C61E65@delong.com>
	<AANLkTim_3funAh=TgenrHQC3Q5H7kq1YMQVMBFarCF8a@mail.gmail.com>
	<F2A4D3F8-4269-40DD-9B6F-2C4AE8E6D664@delong.com>
	<4CB1797C.8000202@chl.com>
	<8B5E8607-7FBE-4F36-8465-9EEBDE7BA5CB@delong.com>
	<4CB1EF80.2080309@chl.com>
	<F0D91B39-2421-4A51-B1B2-AF6B72EAB98D@delong.com>
	<4CB20AA3.2000405@chl.com>
	<91A8C1D0-9F01-4CAF-8ED1-9FEBC7B83C61@delong.com>
	<20101011124843.GA94891@ussenterprise.ufp.org>
Message-ID: <6CD9F425-E5D3-4715-95BB-BC1D9DB44109@delong.com>


On Oct 11, 2010, at 5:48 AM, Leo Bicknell wrote:

> In a message written on Sun, Oct 10, 2010 at 04:55:29PM -0700, Owen DeLong wrote:
>> SLAAC is useful in a routed managed environment. APIPA is _NOT_ anywhere near suitable
>> as a  replacement.
> 
> History begs to differ.
> 
> Back in the day there was this protocol called Appletalk.  It used
> a 2 byte network number, and a one byte node number.  The network
> number was learned from the routers in a procedure not unlike IPv6's
> to learn the network number.  The node number though was chosen
> entirely at random.  If there was a collision, the system chose
> again, repeating until it had a free number.
> 
Yes... However...

> I won't hold Appletalk up as a shining example of anything, but
> there were some large deployments using a APIPA style random
> assignment, using a very small number space, which worked just fine.
> 
Did you ever maintain one of these large deployments? The statement
"worked just fine" is only true for a definition of "worked just fine" that
is acceptable to the average user of Windows 3.1.1. History begs
to differ with a more common definition of the term "works just fine".

> Back to the current day, IPv6 designers seemed to feel we were
> moving to EUI-64's, and that fit nicely with the 64 bit boundary.
> There are technologies that use EUI-64, but Ethernet is not one of
> them yet.  It seems to me a lot of the 6rd problem could be solved
> if we could use a /80 boundary for the local LAN.  Rather than use
> EUI-64 on the LAN, EUI-48 (the MAC address directly) could be used.
> Everything would work exactly the same as it does today (DAD, RA's,
> DHCPv6, etc) only on the smallar address space.  Only some minor
> changes need to be made so the host can detect if it is on a /64
> or /80 boundary.
> 
While we have not yet moved to 64 bit EUIs in ethernet, I do think
that is only a matter of time. There are not that many OUIs left in
the 48 bit EUI numbering space and the IEEE will have to do something
at that point. Much like IPv6 is the alternative for solving the addressing
problem in IPv4, EUI-64 is the IEEEs stated plan for addressing
the shortage of EUI-48 identifiers, and, xx:xx:xx:FF:FE:xx:xx:xx is the
reserved EUI-64 numbering space for EUI-48 compatibility addresses.

You're talking about updating an awful lot of hosts to facilitate this
small change and I doubt it could be reliably accomplished in a
sufficiently timely manner to be meaningful.

> The result is that even giving 16 bits of subnet to the home 6rd
> now fits in a /32 (128 - 48 - 16 - 32).  More importantly, an ISP
> will only have in its routing table the portions of that /32
> corresponding to their IPv4 infrastructure; all of the rest of it
> can be used normally as native IPv6.  While this may mean a few of
> the larger ISP's need more IPv6 space, for a lot of the smaller
> guys they will have more than they need.
> 
No, actually, due to the limitations of how the routing/autotunneling
works in a stateless manner, those addresses can't easily be
re-used for native IPv6. It's sad, but, true.

ANY IPv6 address containing the ISPs defined 6rd prefix will
be automatically encapsulated by the CPE into an IPv4 packet
with the destination address corresponding to the embedded
IPv4 address contained in the IPv6 packet.

> I realize this isn't the IETF list, but we keep trying to "fix"
> problems with the 64 bits on the left side of the address, and that
> still rubs me the wrong way.  Already ISP's have found why using a
> /64 on your P2P interfaces is a bad idea and are using /126's and
> /127's.  I find it hard to believe that advertising the prefix
> length with the prefix would be that much harder, and could allow
> flexability to solve most of these issues.
> 
I know of at least one ISP that I think is undeniably a major ISP,
especially in IPv6 that is not having any problem whatsoever with
our /64 PTP links.

And, as you noted, for the changes you are suggesting, the IETF
lists are that away.. ---->


Owen



From cgrundemann at gmail.com  Mon Oct 11 10:35:22 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Mon, 11 Oct 2010 08:35:22 -0600
Subject: [arin-ppml] IPv4 Crumbs Straw Poll
In-Reply-To: <AANLkTi=F0xxfrqJcqCTZSvYrZpwAfJ63DcruMrOdN-HE@mail.gmail.com>
References: <AANLkTi=F0xxfrqJcqCTZSvYrZpwAfJ63DcruMrOdN-HE@mail.gmail.com>
Message-ID: <AANLkTincyu1C4Y=wWPXb-Eczn-Nh1mHA_y9pKtRNguxx@mail.gmail.com>

If you don't want your name displayed - please use initials or some
such. I have a sneaking suspicion that Dick Cheney doesn't read
PPML...

Thanks,
~Chris


On Sat, Oct 9, 2010 at 13:45, Chris Grundemann <cgrundemann at gmail.com> wrote:
> As I mentioned at the mike in response to dp2010-13 (and some of us
> discussed at lunch); I believe strongly that we are down to two
> choices with regard to the crumbs of IPv4: Do nothing and use them up
> under current policy or leverage them to speed IPv6 adoption and thus
> lower the pain of transition.
>
> I am extremely curious as to which of these two options our community
> feels is preferable. To make this easy; I set up a poll on doodle:
> http://doodle.com/wewba7hnpkqhc9e2
>
> Please take a minute to answer it and to share it with other members
> of the ARIN community.
>
> Thank you,
> ~Chris
>

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


From Wesley.E.George at sprint.com  Mon Oct 11 10:51:46 2010
From: Wesley.E.George at sprint.com (George, Wes E IV [NTK])
Date: Mon, 11 Oct 2010 09:51:46 -0500
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <AANLkTingLkZsMdyiQQJo8pz0h3DDBiTYd0gU9n7jTRhV@mail.gmail.com>
References: <AANLkTingLkZsMdyiQQJo8pz0h3DDBiTYd0gU9n7jTRhV@mail.gmail.com>
Message-ID: <F7EB0A7C707E39409A73CD0353242551A8C1F4963E@PLSWM01C.ad.sprint.com>

As we discussed at the meeting, I like the idea of treating IPv4-only deployment as inefficient use of the space, because it puts teeth into what ARIN has been saying for years now, but I think that the execution of this one could get us into a lot of trouble if not done carefully, especially if done as an emergency action.

Might I suggest an alternative method of creating an incentive to deploy IPv6?
Instead of flatly denying new IPv4 resources if you don't already have IPv6 deployed, why not give requestors a choice?
That is, you can either demonstrate that you have deployed IPv6 (and that any customers to whom you delegate that space are also deploying IPv6), or you can pay an increased registration fee for your new IPv4 space. Either it can be a non-trivially increased flat rate (say, 3x existing fees?), or it can be tied to the amount of address space that ARIN has remaining, indexed monthly. Yes, I realize that the second option would create significant variability in the fees that would be hard to plan for, so we'd probably need a published maximum that people could plan for. Either way, I would recommend that it be tied to the current fees the requestor is paying, so that it's not regressive - that is, if you're a size Small, you pay less than an X-large.
Then, as soon as you get IPv6 deployed, you go back to the normal fee schedule. That would create an incentive to rapidly deploy IPv6, and would complement the existing waiver of IPv6 fees nicely.

If people are worried about this looking like a money-making exercise for ARIN, perhaps we could redirect those extra fees into funding assistance and education for IPv6 deployment?
The idea here is to remove the argument that the costs of making your network IPv6-capable is higher than doing nothing (until the absolute last possible minute), without creating the net effect of simply moving the IPv4 exhaustion brick wall forward by 200 feet in the name of a "soft landing."

We all know that there are 900 ways to sink this proposal because it materially impacts someone's ability to do business pre-runout, and there may be things beyond their control in terms of timing, which is why I'm hesitant to support a straight denial without some way of managing the impact of suddenly changing the timeline. However, loopholes/cutouts/exceptions are a quagmire, because everyone will have a reasonable argument for why their chosen line of business should get one, and if we enact them all, the rule has no teeth, and if we don't enact them all, there's a question of fairness that likely leads to legal troubles.

Really, there are 2 categories of folks that would be negatively affected by policy like this -
1) those who have started deployment (for some definition of those two words) but have limiting factors that won't be resolved before their need for additional IPv4 space
2) those who have not started deployment for <reason>

It's difficult to make the case to punish #1 for not going fast enough for our tastes, especially if they've been using the current projections for exhaustion as their rough timeline for when they have to have IPv6 ready. As it is, they'll likely get a punishment of sorts when the projections are wrong and they can't get addresses they were expecting to be able to get.
You might argue that #2 may have a legitimate reason(s), but if they're asking for more space, that argument is shaky to say the least.

Wes George

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Chris Grundemann
> Sent: Friday, October 08, 2010 12:01 PM
> To: arin-ppml at arin.net
> Cc: Jason Schiller
> Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
>
> Problem Statement:
> We have failed to deploy dual-stack in a meaningful way in time to
> avoid transition problems
>
> Objectives:
> -1- Encourage IPv6 deployment prior to depletion
> -2- Enable growth of IPv4 where IPv6 is being deployed
> -3- Improve the utilization of IP addresses
>
> High-Level Requirements:
> -1- ARIN will only make allocations and assignments for networks that
> have already deployed production IPv6
> -2- Any IPv4 addresses received under this policy, must be deployed
> along side of IPv6
> -3- This policy will encourage deployment of IPv6 in existing IPv4-only
> networks
>
> Rough Policy Text:
> ~ Requester defines classes in their network - only classes where IPv6
> is in production qualify for IPv6
> ~ New addresses must be deployed on dual-stacked interfaces plus one
> additional existing IPv4-only interface must be dual stacked, up to
> 80% of all interfaces.
> ~ The service that the address is used to provide must be fully IPv6
> accessible (if you deploy an A record, you must also have a AAAA and
> both must answer)
> ~ All end-sites must dual-stack all Internet facing services before
> getting this space
> ~ For each down stream customer site where these addresses are
> deployed, another pre-existing IPv4 only down stream site must also be
> IPv6 enabled, up to 80% of the total customer base.
>
>
> This is an emergency, let's get something together ASAP. All feedback
> is extremely welcome and greatly appreciated; this problem is all of
> ours. If you are still here in Atlanta come find me, Marty Hannigan
> and/or Jason Schiller to discuss.
>
> Thanks!
> ~Chris
>
>
>
> --
> @ChrisGrundemann
> weblog.chrisgrundemann.com
> www.burningwiththebush.com
> www.coisoc.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.


This e-mail may contain Sprint Nextel 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  Mon Oct 11 11:07:45 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Mon, 11 Oct 2010 11:07:45 -0400
Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
In-Reply-To: <6CD9F425-E5D3-4715-95BB-BC1D9DB44109@delong.com>
References: <AANLkTinKgj_7CFRKHp-wH7EkVg9mQAHaAKTts=vOwjrt@mail.gmail.com>	<08DFE069-C69C-4F1B-9C22-95DC23C61E65@delong.com>	<AANLkTim_3funAh=TgenrHQC3Q5H7kq1YMQVMBFarCF8a@mail.gmail.com>	<F2A4D3F8-4269-40DD-9B6F-2C4AE8E6D664@delong.com>	<4CB1797C.8000202@chl.com>	<8B5E8607-7FBE-4F36-8465-9EEBDE7BA5CB@delong.com>	<4CB1EF80.2080309@chl.com>	<F0D91B39-2421-4A51-B1B2-AF6B72EAB98D@delong.com>	<4CB20AA3.2000405@chl.com>	<91A8C1D0-9F01-4CAF-8ED1-9FEBC7B83C61@delong.com>	<20101011124843.GA94891@ussenterprise.ufp.org>
	<6CD9F425-E5D3-4715-95BB-BC1D9DB44109@delong.com>
Message-ID: <4CB32841.40204@chl.com>



Owen DeLong wrote:
>
> On Oct 11, 2010, at 5:48 AM, Leo Bicknell wrote:

>
>> Back to the current day, IPv6 designers seemed to feel we were
>> moving to EUI-64's, and that fit nicely with the 64 bit boundary.
>> There are technologies that use EUI-64, but Ethernet is not one of
>> them yet.  It seems to me a lot of the 6rd problem could be solved
>> if we could use a /80 boundary for the local LAN.  Rather than use
>> EUI-64 on the LAN, EUI-48 (the MAC address directly) could be used.
>> Everything would work exactly the same as it does today (DAD, RA's,
>> DHCPv6, etc) only on the smallar address space.  Only some minor
>> changes need to be made so the host can detect if it is on a /64
>> or /80 boundary.
>>
> While we have not yet moved to 64 bit EUIs in ethernet, I do think
> that is only a matter of time. There are not that many OUIs left in
> the 48 bit EUI numbering space and the IEEE will have to do something
> at that point. Much like IPv6 is the alternative for solving the addressing
> problem in IPv4, EUI-64 is the IEEEs stated plan for addressing
> the shortage of EUI-48 identifiers, and, xx:xx:xx:FF:FE:xx:xx:xx is the
> reserved EUI-64 numbering space for EUI-48 compatibility addresses.

I remain unconvinced that aligning the L3 network addressing (local 
scope) with the L2 addressing (global scope) has enough to recommend it 
(other than how cute it looks) so that it is deserving of a lifetime 
guarantee of 64 bits. Quite a long lifetime.

In fact, it is a layering violation. Those always look cute initially.

>
> You're talking about updating an awful lot of hosts to facilitate this
> small change and I doubt it could be reliably accomplished in a
> sufficiently timely manner to be meaningful.


That argument is only valid when there is a deadline that when exceeded 
the investment of effort is lost, and there is only a limited amount of 
effort to invest. When that is the case, a careful evaluation of where 
to invest effort is required.

I dont believe that to be the case here. Even if such an effort would 
have been better made years earlier, that does not preclude it from 
being made now, or even years from now. Benefit can still be realized.


> And, as you noted, for the changes you are suggesting, the IETF
> lists are that away.. ---->
>
>
> Owen
>

There is an intersection. The bits the IETF decides how they are to be 
used are expected to come out of the bits we have to operate with and 
that the registry uses to allocate from.

Joe


From info at arin.net  Mon Oct 11 13:20:51 2010
From: info at arin.net (ARIN)
Date: Mon, 11 Oct 2010 13:20:51 -0400
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated Transfer
	Policy
Message-ID: <4CB34773.2070308@arin.net>

ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with the Policy
Development Process.

The ARIN Advisory Council (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.

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,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal 119: Globally Coordinated Transfer Policy

Proposal Originator: Chris Grundemann, Martin Hannigan, Jason Schiller

Proposal Version: 1.0

Date: 11 October 2010

Proposal type: new

Policy term: permanent

Policy statement: Any RIR's member may transfer IPv4 addresses to the
member of another RIR as long as the two RIRs agree and exercise
Internet stewardship and the values expressed in RFC2050.

Rationale: Since individual RIRs now allow transfers, it makes sense to
be able to transfer between regions as well.

Timetable for implementation: upon ratification of all five RIRs

Timetable for de-implementation: upon change to this policy text in any RIR






From tedm at ipinc.net  Mon Oct 11 13:34:47 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 11 Oct 2010 10:34:47 -0700
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated Transfer
 Policy
In-Reply-To: <4CB34773.2070308@arin.net>
References: <4CB34773.2070308@arin.net>
Message-ID: <4CB34AB7.1060001@ipinc.net>

On 10/11/2010 10:20 AM, ARIN wrote:
> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with the Policy
> Development Process.
>
> The ARIN Advisory Council (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.
>
> 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,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Policy Proposal 119: Globally Coordinated Transfer Policy
>
> Proposal Originator: Chris Grundemann, Martin Hannigan, Jason Schiller
>
> Proposal Version: 1.0
>
> Date: 11 October 2010
>
> Proposal type: new
>
> Policy term: permanent
>
> Policy statement: Any RIR's member may transfer IPv4 addresses to the
> member of another RIR as long as the two RIRs agree and exercise
> Internet stewardship and the values expressed in RFC2050.
>
> Rationale: Since individual RIRs now allow transfers, it makes sense to
> be able to transfer between regions as well.
>
> Timetable for implementation: upon ratification of all five RIRs
>
> Timetable for de-implementation: upon change to this policy text in any RIR
>
>

I disagree with the specific implementation but agree with the general
thrust of it.  I would prefer that any globally coordinated transfer
policy such as this would do the following:

1) explicitly set a minimum size of the block.  RFC's can be superseded.
And we do not want a lot of bifurcation of the ownership of the blocks.
/9's. /10's, I can see.  But as you get smaller and smaller the reasons
for allowing this rapidly get fuzzier and fuzzier.

2) Mandate that the transfer is RIR-to-RIR.  The correct verbage would 
be something along the lines of:

Any RIR's member may request their RIR to permit an IPv4 address 
transfer of their IPv4 to another RIR that is earmarked for assignment 
to a member of that RIR.

3) I also want to see an expiration if the transfer fails.  The verbage
would be something like:

In the event that the directed assignment fails due to the receiving
RIR rejecting the assignment, the earmark will expire in 6 months and 
the addresses will revert to the original RIR

Ted


From cgrundemann at gmail.com  Mon Oct 11 16:08:49 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Mon, 11 Oct 2010 14:08:49 -0600
Subject: [arin-ppml] Post-Meeting Revision of 2010-14
Message-ID: <AANLkTimswvutx69N8OGWPH-BC4+V=g5Vohh1HE2=34-+@mail.gmail.com>

Based on feedback during and after the presentation of 2010-14 at the
public policy meeting last week; I have worked with the AC shepherds
to fix the editorial issues raised.

I believe that this new revision is conceptually identical to what was
presented in Atlanta, that the changes are strictly editorial, have
not changed the intent of the policy but have addressed all of the
concerns raised at the meeting.

There were two changes made:
1) The text in section 4.2.3.7.3.1. "Residential Market Area" was
replaced with a direct copy of the current "Cable Address Space
Policy" to avoid any perceived change of intent. The only changes to
this text are it's placement in the NRPM and that it now applies to
all residential access networks, not just cable networks.
2) The "Residential Market Area" section has been stricken from the
IPv6 policy. It is not needed due to the application of the HD ratio
to IPv6 allocations.

The rest of the rational remains unchanged and is included below the
policy text for completeness.

--
Draft Policy 2010-14
Standardize IP Reassignment Registration Requirements

Version/Date: 11 October, 2010

Policy statement:

## Definitions ##

- Add:

2.3. Organizational Information

When required, organization Information must include at a minimum:
Legal name, street address, city, state, zip code equivalent and at
least one valid technical and one valid abuse POC. Each POC shall be
designated by the organization and must include at least a verifiable
email address and phone number.

2.12. Residential Customer

End-users who are individual persons and not organizations and who
receive service at a place of residence for personal use only 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 but not
limited to 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

    * In most cases, ISPs that have residential subscribers assign
address space to their access infrastructure to which their customers
connect rather than to individual subscribers. This assignment
information regarding each market area holding an address block should
be entered via SWIP (or by using RWhois) with the network name used to
identify each market area. Initial allocations are based on total
number of homes that could purchase the service in a given market
area.
    * Using SWIP or RWhois, residential access ISPs must show that
they have reassigned at least 80% of their current address space, with
a 50 to 80% utilization rate, in order to request additional
addresses.
    * Each assignment to a specific end-user (if holding /29 and
larger blocks) requires the submission of a SWIP or use of an RWhois
server. Requesters will also be asked to provide detailed plans for
use of the newly requested space.

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 but not
limited to assignment histories, showing their efficient use.

6.5.5.1. Reassignment information

Each IPv6 assignment containing a /64 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 Customer Privacy

To maintain the privacy of their residential customers, an
organization with downstream residential customers holding /64 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.

## Resource Review ##

- Move section 12.2. paragraph 2. bullet c. to bullet d. and insert
the following:

c. whenever ARIN has reason to believe that an organization is not
complying with reassignment policies, or

--
Rationale:

#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 preferred POC (which allows
for simple reassignments).
4) Expands the privileges previously reserved solely for IPv4 cable
ISPs to all ISPs/LIRs with residential/dhcp-type subscribers.
5) Specifically define the term "residential customer."
6) Allow ARIN to conduct resource reviews based on failure to comply
with registration / reassignment policies.

#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.
d) The IPv6 policy is altered from a /56 minimum needing to be
registered to a /64. A /64 is a single IPv6 subnet where as a /56
contains many subnets (that should all be recorded in the WHOIS
directory if handed out to other organizations).

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 legal name and physical address are
required for client organizations.
b) The definition states that POCs are 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 each POC have a valid email address
and phone number.

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 offsets the ability to register/swip/rwhois market
areas. For all other allocation types, efficient utilization is based
on SWIPs, not on actual utilization. When an organization is able to
SWIP an entire market area, this must be checked against actual
utilization. This policy maintains the current line set at >50%.
**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.

6) Not properly registering reassignment information could be a sign
of other improper or illicit behavior and should justify a resource
review (audit) by ARIN when necessary, regardless of when the last
review took place.

--


Cheers,
~Chris



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


From jdeckness at tctainc.net  Mon Oct 11 16:21:22 2010
From: jdeckness at tctainc.net (Jay Deckness)
Date: Mon, 11 Oct 2010 15:21:22 -0500
Subject: [arin-ppml] Post-Meeting Revision of 2010-14
In-Reply-To: <AANLkTimswvutx69N8OGWPH-BC4+V=g5Vohh1HE2=34-+@mail.gmail.com>
References: <AANLkTimswvutx69N8OGWPH-BC4+V=g5Vohh1HE2=34-+@mail.gmail.com>
Message-ID: <6A0C363AE52B3D428B147D3DD84A8BB87E164A80@TCTEX.MACC043.local>

Is there any support in registering a residential market as a single large registration similar to the process under discussion in RIPE:

	RIPE region is discussing IPv6 registration to
	customer areas, for example, registering a
	DSL customer area [Example, "v6xxxx::/36
	DSL pool in North London(assignment size
	/56)"]

It is my understanding that under existing policy, if an ISP assigns a /56 to each of its residential customers, it will be required to enter a generic ('Private Customer - XYZ Network') SWIP for each one. 

Justin Deckness


-----Original Message-----
From: Chris Grundemann [mailto:cgrundemann at gmail.com] 
Sent: Monday, October 11, 2010 3:09 PM
To: arin-ppml at arin.net
Cc: Azinger, Marla
Subject: [arin-ppml] Post-Meeting Revision of 2010-14

Based on feedback during and after the presentation of 2010-14 at the public policy meeting last week; I have worked with the AC shepherds to fix the editorial issues raised.

I believe that this new revision is conceptually identical to what was presented in Atlanta, that the changes are strictly editorial, have not changed the intent of the policy but have addressed all of the concerns raised at the meeting.

There were two changes made:
1) The text in section 4.2.3.7.3.1. "Residential Market Area" was replaced with a direct copy of the current "Cable Address Space Policy" to avoid any perceived change of intent. The only changes to this text are it's placement in the NRPM and that it now applies to all residential access networks, not just cable networks.
2) The "Residential Market Area" section has been stricken from the
IPv6 policy. It is not needed due to the application of the HD ratio to IPv6 allocations.

The rest of the rational remains unchanged and is included below the policy text for completeness.

--
Draft Policy 2010-14
Standardize IP Reassignment Registration Requirements

Version/Date: 11 October, 2010

Policy statement:

## Definitions ##

- Add:

2.3. Organizational Information

When required, organization Information must include at a minimum:
Legal name, street address, city, state, zip code equivalent and at least one valid technical and one valid abuse POC. Each POC shall be designated by the organization and must include at least a verifiable email address and phone number.

2.12. Residential Customer

End-users who are individual persons and not organizations and who receive service at a place of residence for personal use only 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 but not limited to 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

    * In most cases, ISPs that have residential subscribers assign address space to their access infrastructure to which their customers connect rather than to individual subscribers. This assignment information regarding each market area holding an address block should be entered via SWIP (or by using RWhois) with the network name used to identify each market area. Initial allocations are based on total number of homes that could purchase the service in a given market area.
    * Using SWIP or RWhois, residential access ISPs must show that they have reassigned at least 80% of their current address space, with a 50 to 80% utilization rate, in order to request additional addresses.
    * Each assignment to a specific end-user (if holding /29 and larger blocks) requires the submission of a SWIP or use of an RWhois server. Requesters will also be asked to provide detailed plans for use of the newly requested space.

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 but not limited to assignment histories, showing their efficient use.

6.5.5.1. Reassignment information

Each IPv6 assignment containing a /64 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 Customer Privacy

To maintain the privacy of their residential customers, an organization with downstream residential customers holding /64 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.

## Resource Review ##

- Move section 12.2. paragraph 2. bullet c. to bullet d. and insert the following:

c. whenever ARIN has reason to believe that an organization is not complying with reassignment policies, or

--
Rationale:

#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 preferred POC (which allows for simple reassignments).
4) Expands the privileges previously reserved solely for IPv4 cable ISPs to all ISPs/LIRs with residential/dhcp-type subscribers.
5) Specifically define the term "residential customer."
6) Allow ARIN to conduct resource reviews based on failure to comply with registration / reassignment policies.

#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.
d) The IPv6 policy is altered from a /56 minimum needing to be registered to a /64. A /64 is a single IPv6 subnet where as a /56 contains many subnets (that should all be recorded in the WHOIS directory if handed out to other organizations).

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 legal name and physical address are required for client organizations.
b) The definition states that POCs are 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 each POC have a valid email address and phone number.

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 offsets the ability to register/swip/rwhois market areas. For all other allocation types, efficient utilization is based on SWIPs, not on actual utilization. When an organization is able to SWIP an entire market area, this must be checked against actual utilization. This policy maintains the current line set at >50%.
**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.

6) Not properly registering reassignment information could be a sign of other improper or illicit behavior and should justify a resource review (audit) by ARIN when necessary, regardless of when the last review took place.

--


Cheers,
~Chris



--
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.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 springer at inlandnet.com  Mon Oct 11 18:08:01 2010
From: springer at inlandnet.com (John Springer)
Date: Mon, 11 Oct 2010 15:08:01 -0700 (PDT)
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<AANLkTik5ow0Gbb+-KSsUjm5RLsvGuT7CbgkZkamxwFWw@mail.gmail.com>
Message-ID: <20101011150226.G82597@mail.inlandnet.com>

On Thu, 7 Oct 2010, Heather Schiller wrote:

> Obtaining v6 address space is not the problem, deployment is.

<snipped>

 		This is extremely sensible.
 		in response to:

John Springer


From cgrundemann at gmail.com  Mon Oct 11 18:08:38 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Mon, 11 Oct 2010 16:08:38 -0600
Subject: [arin-ppml] Post-Meeting Revision of 2010-14
In-Reply-To: <6A0C363AE52B3D428B147D3DD84A8BB87E164A80@TCTEX.MACC043.local>
References: <AANLkTimswvutx69N8OGWPH-BC4+V=g5Vohh1HE2=34-+@mail.gmail.com>
	<6A0C363AE52B3D428B147D3DD84A8BB87E164A80@TCTEX.MACC043.local>
Message-ID: <AANLkTi==X8e683rA00smZp2MC3KNxxeSiNZX0_ROKKga@mail.gmail.com>

On Mon, Oct 11, 2010 at 14:21, Jay Deckness <jdeckness at tctainc.net> wrote:
> Is there any support in registering a residential market as a single large registration similar to the process under discussion in RIPE:
>
> ? ? ? ?RIPE region is discussing IPv6 registration to
> ? ? ? ?customer areas, for example, registering a
> ? ? ? ?DSL customer area [Example, "v6xxxx::/36
> ? ? ? ?DSL pool in North London(assignment size
> ? ? ? ?/56)"]

I think the best thing to do at this point is to adopt 2010-14 and
then submit a follow up proposal to address IPv6 market areas. I say
this because there still seems to be a fair amount of confusion around
current IPv6 requirements especially wrt the HD ratio, etc. I think
there is enough conversation needed there to warrant a separate policy
proposal. Plus I think that 2010-14 addresses all of the most urgent
issues, giving us time to have that conversation...

$0.02
~Chris

> It is my understanding that under existing policy, if an ISP assigns a /56 to each of its residential customers, it will be required to enter a generic ('Private Customer - XYZ Network') SWIP for each one.
>
> Justin Deckness
>
>
> -----Original Message-----
> From: Chris Grundemann [mailto:cgrundemann at gmail.com]
> Sent: Monday, October 11, 2010 3:09 PM
> To: arin-ppml at arin.net
> Cc: Azinger, Marla
> Subject: [arin-ppml] Post-Meeting Revision of 2010-14
>
> Based on feedback during and after the presentation of 2010-14 at the public policy meeting last week; I have worked with the AC shepherds to fix the editorial issues raised.
>
> I believe that this new revision is conceptually identical to what was presented in Atlanta, that the changes are strictly editorial, have not changed the intent of the policy but have addressed all of the concerns raised at the meeting.
>
> There were two changes made:
> 1) The text in section 4.2.3.7.3.1. "Residential Market Area" was replaced with a direct copy of the current "Cable Address Space Policy" to avoid any perceived change of intent. The only changes to this text are it's placement in the NRPM and that it now applies to all residential access networks, not just cable networks.
> 2) The "Residential Market Area" section has been stricken from the
> IPv6 policy. It is not needed due to the application of the HD ratio to IPv6 allocations.
>
<snip>
>___________________________________________
> 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 farmer at umn.edu  Mon Oct 11 19:35:57 2010
From: farmer at umn.edu (David Farmer)
Date: Mon, 11 Oct 2010 18:35:57 -0500
Subject: [arin-ppml]  # of subnets to qualify a network
In-Reply-To: <4C97A0E6.1090800@umn.edu>
References: <C8B42DA7.FDAD%marty@akamai.com>	<3026D718-E8C1-4549-9E85-FB9C2139FC68@tcb.net>	<C4C30BF4-6E9A-4DFE-A1D6-A3D18836E998@delong.com>	<03aa01cb55d3$2b09bcf0$811d36d0$@com>	<984E935A-E2BE-4D5D-B24E-A81CE9523373@delong.com>	<0F29D1BA57992E4CAB5AD2C9AE7B42391CF4E005@EMV01-UKBR.domain1.systemhost.net>	<95E4C0A8-4A81-4D0B-8FA1-BB65AC0244E5@delong.com>	<0F29D1BA57992E4CAB5AD2C9AE7B423935E05450@EMV01-UKBR.domain1.systemhost.net>	<AANLkTimWJ26-bBNWquCdmid+zK7F_ibS0_GFTktA=a4x@mail.gmail.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B423935E057B2@EMV01-UKBR.domain1.systemhost.net>
	<4C97A0E6.1090800@umn.edu>
Message-ID: <4CB39F5D.7030303@umn.edu>

On 9/20/10 12:59 CDT, David Farmer wrote:
> On 9/20/10 10:53 CDT, michael.dillon at bt.com wrote:
...
>> Given that we are talking about IPv6 renumbering, not IPv4 renumbering,
>> subnets still seems like a good measure. In IPv6, the subnets are
>> unchanged
>> and you just change the network prefix handed out by SLAAC or DHCPv6.
...
> If we can come to some kind of consensus on a subnet count I would be
> happy to add that into the policy as a fifth clause in section 6.5.8.1
> Initial Assignment Criteria. It will probably be after the up coming
> meeting, as I doubt we can come to a consensus in the next day or two,
> in order get it into the text prior to the 10 day freeze before the
> meeting.

In the presentation of 2010-8 in Atlanta I proposed adding a new clause 
to 6.5.8.1 as follows;

"d. By having a network that makes active use of a minimum of 200 /64 
subnets within 12 months, or;"

I'd be interested in any comments on the appropriateness of the number 
200.  There is no magic in the number, I mostly just picked a number. It 
seemed like it should be at least an order of magnitude less that the 
current host count of 2000. But I'm open to suggestions, especially any 
suggestion with a good rationale for the number.

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 scottleibrand at gmail.com  Mon Oct 11 21:29:24 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 11 Oct 2010 21:29:24 -0400
Subject: [arin-ppml] Post-Meeting Revision of 2010-14
In-Reply-To: <AANLkTimswvutx69N8OGWPH-BC4+V=g5Vohh1HE2=34-+@mail.gmail.com>
References: <AANLkTimswvutx69N8OGWPH-BC4+V=g5Vohh1HE2=34-+@mail.gmail.com>
Message-ID: <AANLkTinLtBF60Mx26PtH7NnMz82a-VodXSjFn3JZMR3x@mail.gmail.com>

Chris,

It looks to me like this text would still require each and every dynamically
assigned residential block to be SWIPped.  I know we talked about several
possible solutions to this at the meeting: do you think it would be useful
to do something like change the first sentence of 6.5.5.1 to read "Each
static IPv6 assignment" instead of "Each IPv6 assignment"?

-Scott

On Mon, Oct 11, 2010 at 4:08 PM, Chris Grundemann <cgrundemann at gmail.com>wrote:

> Based on feedback during and after the presentation of 2010-14 at the
> public policy meeting last week; I have worked with the AC shepherds
> to fix the editorial issues raised.
>
> I believe that this new revision is conceptually identical to what was
> presented in Atlanta, that the changes are strictly editorial, have
> not changed the intent of the policy but have addressed all of the
> concerns raised at the meeting.
>
> There were two changes made:
> 1) The text in section 4.2.3.7.3.1. "Residential Market Area" was
> replaced with a direct copy of the current "Cable Address Space
> Policy" to avoid any perceived change of intent. The only changes to
> this text are it's placement in the NRPM and that it now applies to
> all residential access networks, not just cable networks.
> 2) The "Residential Market Area" section has been stricken from the
> IPv6 policy. It is not needed due to the application of the HD ratio
> to IPv6 allocations.
>
> The rest of the rational remains unchanged and is included below the
> policy text for completeness.
>
> --
> Draft Policy 2010-14
> Standardize IP Reassignment Registration Requirements
>
> Version/Date: 11 October, 2010
>
> Policy statement:
>
> ## Definitions ##
>
> - Add:
>
> 2.3. Organizational Information
>
> When required, organization Information must include at a minimum:
> Legal name, street address, city, state, zip code equivalent and at
> least one valid technical and one valid abuse POC. Each POC shall be
> designated by the organization and must include at least a verifiable
> email address and phone number.
>
> 2.12. Residential Customer
>
> End-users who are individual persons and not organizations and who
> receive service at a place of residence for personal use only 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 but not
> limited to 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
>
>    * In most cases, ISPs that have residential subscribers assign
> address space to their access infrastructure to which their customers
> connect rather than to individual subscribers. This assignment
> information regarding each market area holding an address block should
> be entered via SWIP (or by using RWhois) with the network name used to
> identify each market area. Initial allocations are based on total
> number of homes that could purchase the service in a given market
> area.
>    * Using SWIP or RWhois, residential access ISPs must show that
> they have reassigned at least 80% of their current address space, with
> a 50 to 80% utilization rate, in order to request additional
> addresses.
>    * Each assignment to a specific end-user (if holding /29 and
> larger blocks) requires the submission of a SWIP or use of an RWhois
> server. Requesters will also be asked to provide detailed plans for
> use of the newly requested space.
>
> 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 but not
> limited to assignment histories, showing their efficient use.
>
> 6.5.5.1. Reassignment information
>
> Each IPv6 assignment containing a /64 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 Customer Privacy
>
> To maintain the privacy of their residential customers, an
> organization with downstream residential customers holding /64 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.
>
> ## Resource Review ##
>
> - Move section 12.2. paragraph 2. bullet c. to bullet d. and insert
> the following:
>
> c. whenever ARIN has reason to believe that an organization is not
> complying with reassignment policies, or
>
> --
> Rationale:
>
> #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 preferred POC (which allows
> for simple reassignments).
> 4) Expands the privileges previously reserved solely for IPv4 cable
> ISPs to all ISPs/LIRs with residential/dhcp-type subscribers.
> 5) Specifically define the term "residential customer."
> 6) Allow ARIN to conduct resource reviews based on failure to comply
> with registration / reassignment policies.
>
> #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.
> d) The IPv6 policy is altered from a /56 minimum needing to be
> registered to a /64. A /64 is a single IPv6 subnet where as a /56
> contains many subnets (that should all be recorded in the WHOIS
> directory if handed out to other organizations).
>
> 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 legal name and physical address are
> required for client organizations.
> b) The definition states that POCs are 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 each POC have a valid email address
> and phone number.
>
> 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 offsets the ability to register/swip/rwhois market
> areas. For all other allocation types, efficient utilization is based
> on SWIPs, not on actual utilization. When an organization is able to
> SWIP an entire market area, this must be checked against actual
> utilization. This policy maintains the current line set at >50%.
> **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.
>
> 6) Not properly registering reassignment information could be a sign
> of other improper or illicit behavior and should justify a resource
> review (audit) by ARIN when necessary, regardless of when the last
> review took place.
>
> --
>
>
> Cheers,
> ~Chris
>
>
>
> --
> @ChrisGrundemann
> weblog.chrisgrundemann.com
> www.burningwiththebush.com
> www.coisoc.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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101011/f36095e3/attachment.htm>

From bjohnson at drtel.com  Tue Oct 12 09:50:54 2010
From: bjohnson at drtel.com (Brian Johnson)
Date: Tue, 12 Oct 2010 08:50:54 -0500
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated
	TransferPolicy
In-Reply-To: <4CB34773.2070308@arin.net>
References: <4CB34773.2070308@arin.net>
Message-ID: <29A54911243620478FF59F00EBB12F47021D8C85@ex01.drtel.lan>

>-----Original Message-----
>From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>Behalf Of ARIN
>Sent: Monday, October 11, 2010 12:21 PM
>To: arin-ppml at arin.net
>Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated
TransferPolicy
>
<SNIP>
>
>## * ##
>
>
>Policy Proposal 119: Globally Coordinated Transfer Policy
>
>Proposal Originator: Chris Grundemann, Martin Hannigan, Jason Schiller
>
>Proposal Version: 1.0
>
>Date: 11 October 2010
>
>Proposal type: new
>
>Policy term: permanent
>
>Policy statement: Any RIR's member may transfer IPv4 addresses to the
>member of another RIR as long as the two RIRs agree and exercise
>Internet stewardship and the values expressed in RFC2050.
>
>Rationale: Since individual RIRs now allow transfers, it makes sense to
>be able to transfer between regions as well.
>
>Timetable for implementation: upon ratification of all five RIRs
>
>Timetable for de-implementation: upon change to this policy text in any
RIR
>

Some questions...

 -  Are the transfer parties the RIRs or the individual RIR assignees?
 -  If the individual assignees, will the transferred resources be
re-assigned to the destination RIR?
 -  Are we willing to accept the fragmentation this will cause?

 - Brian J.

()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments





From bjohnson at drtel.com  Tue Oct 12 11:58:26 2010
From: bjohnson at drtel.com (Brian Johnson)
Date: Tue, 12 Oct 2010 10:58:26 -0500
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
Message-ID: <29A54911243620478FF59F00EBB12F47021D8C8E@ex01.drtel.lan>

>-----Original Message-----
>From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>Behalf Of William Herrin
>Sent: Thursday, October 07, 2010 10:46 AM
>To: arin-ppml at arin.net
>Subject: [arin-ppml] Preemptive IPv6 assignment
>
>Hi folks,
>
>Over the course of the week I've had the opportunity to talk to a
>number of wonderful folks in the operator community here at the
>meeting in Atlanta. As expected we often talked of IPv6 and in some
>cases the conversation wandered to a question that has puzzled me for
>some time:
>

I also was there and heard several conversations on this matter. There
are tons of ideas about this, and without diligent research into each,
all of them sound good on their face as a means to prod along
allocations, NOT DEPLOYMENT. We can give every grain of sand on the
planet an IPv6 address/prefix/whatever, but that would not mean that any
of them deploy the prefix. Key difference here.

>"Why not look in the BGP table, take every announced ARIN AS number
>and preemptively assign IPv6 addresses to each associated organization
>that doesn't already have them? Not forever of course... give it three
>years and then the assignments evaporate unless claimed by signing an
>RSA and paying the annual fees."
>

I'm all about the free giveaways at conferences, but this is a bridge
too far. AS assignment != demonstrated need. We need to ensure we do not
move too  far from the principle that we assign resources on a
DEMONSTRATED NEED basis.

>When I posed this question the responses were largely variants on,
>"That would make too much sense."
>

I never said that. :-)

>So I put it to the list. Have we some stick rammed far enough up our
>collective backside that we're willing to tell people: you MUST deploy
>IPv6, it alone will save the Internet's soul. And oh by the way you
>need our permission to start for real. So fill out the form, make your
>checks payable and we'll get back to you.
>

Please keep your backside to yourself. :-)  I have no such stick and do
not see such a stick in the "collective posterior" of ARIN. I'm excited
to move forward and I feel it is important, but, as always, demand and
scarcity will drive the IPv6 train into the future. Even if we start
telling people they have to get a resource that they do not want, even
if it is a bad/silly decision to refuse the resource, it will not drive
adoption or deployment of IPv6 IMHO. It may even create a bit of a chasm
in the community.

>For your consideration,
>Bill Herrin
>

It was great to hear you speak at the meeting and I appreciate your
perspectives on these issues. Please keep in mind that the carrot is
always better than the stick, no matter where you are keeping it. :-)

- Brian J.

()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments

* Please note that all list members and archive readers may consider
themselves Recipients of this message, in reference to the appended
disclaimer.  (I don't add it myself and can't control it, sorry.)


 CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the
intended recipient(s) and may contain confidential and privileged information. Any unauthorized review,
copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original message. Thank you.


From carlosm3011 at gmail.com  Tue Oct 12 12:02:05 2010
From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo)
Date: Tue, 12 Oct 2010 14:02:05 -0200
Subject: [arin-ppml] Question - Where can I find the results of Arin 26
	Policy Meetings ?
Message-ID: <AANLkTiniuMwaieQL4s3ewxoNLzjVFayZi3i3uWUvWevm@mail.gmail.com>

Hello everyone,

thank you for a great Arin26 where I felt very welcome. I was wondering
where can I find the results of the consensus votes on the different
policies. I did not write them down and now I would like to have that
information for our Policy Update in Sao Paulo next week.

If necessary, please contact me off-list at carlos AT lacnic.net

Warm regards,

Carlos Martinez
LACNIC R+D

-- 
--
=========================
Carlos M. Martinez-Cagnazzo
http://cagnazzo.name
=========================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101012/a24b7ed8/attachment.htm>

From mcr at sandelman.ca  Tue Oct 12 14:02:20 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Tue, 12 Oct 2010 14:02:20 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <29A54911243620478FF59F00EBB12F47021D8C8E@ex01.drtel.lan> 
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47021D8C8E@ex01.drtel.lan> 
Message-ID: <10093.1286906540@marajade.sandelman.ca>


There are many discussions about how giving out address space does not
cause deployment.   I agree that is is true for ISPs, which is largely
who is involved in ARIN, and who care about routing table sizes.

It is not the same situation for enterprises.
Please see debate about non-connected IPv6 allocations starting about a
year ago.

Few enterprises have any reason to deploy IPv6 today.  While the smart
ones go and get some address space from a tunnel broker and use that as
their "site-local" address space, this doesn't work for everyone.
(We had a long conversation about ULA-Random, and why it also doesn't
suit everyone).

An enterprise which currently pays no fees to ARIN: either because they
have no resources (or because they were an early adopter last time, and
they have only Legacy resources), can not make a business case for
getting IPv6 space.  Even that ridiculously low cost of $1250 is hard.

There are very few things that ARIN can do about deployment, reducing
one small hurdle is about it.  Given that ARIN-PPML has already spent
far more human resource time discussing this issue than it is worth, I
suggest dropping this discussion.

-- 
]       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 kkargel at polartel.com  Tue Oct 12 14:13:21 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 12 Oct 2010 13:13:21 -0500
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <10093.1286906540@marajade.sandelman.ca>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47021D8C8E@ex01.drtel.lan>
	<10093.1286906540@marajade.sandelman.ca>
Message-ID: <8695009A81378E48879980039EEDAD288C049D3E@MAIL1.polartel.local>

While I agree that assignment does not equal deployment, assignment *does* facilitate deployment.  If netadmins already have the resources available they are more likely to deploy than if they have to fill out a form and wait for an allocation.  

As far as the needs based argument goes, I thought it was pretty much a given that anyone who wanted a minimum allocation of IPv6 and was willing to pay the fee (if any fee applied) would get one.

  



 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Michael Richardson
> Sent: Tuesday, October 12, 2010 1:02 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Preemptive IPv6 assignment
> 
> 
> There are many discussions about how giving out address space does not
> cause deployment.   I agree that is is true for ISPs, which is largely
> who is involved in ARIN, and who care about routing table sizes.
> 
> It is not the same situation for enterprises.
> Please see debate about non-connected IPv6 allocations starting about a
> year ago.
> 
> Few enterprises have any reason to deploy IPv6 today.  While the smart
> ones go and get some address space from a tunnel broker and use that as
> their "site-local" address space, this doesn't work for everyone.
> (We had a long conversation about ULA-Random, and why it also doesn't
> suit everyone).
> 
> An enterprise which currently pays no fees to ARIN: either because they
> have no resources (or because they were an early adopter last time, and
> they have only Legacy resources), can not make a business case for
> getting IPv6 space.  Even that ridiculously low cost of $1250 is hard.
> 
> There are very few things that ARIN can do about deployment, reducing
> one small hurdle is about it.  Given that ARIN-PPML has already spent
> far more human resource time discussing this issue than it is worth, I
> suggest dropping this discussion.
> 
> --
> ]       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.
> _______________________________________________
> 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 Oct 12 14:15:01 2010
From: bill at herrin.us (William Herrin)
Date: Tue, 12 Oct 2010 14:15:01 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <29A54911243620478FF59F00EBB12F47021D8C8E@ex01.drtel.lan>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47021D8C8E@ex01.drtel.lan>
Message-ID: <AANLkTimrLtPpbN6L-EYc_kAqMh8kxh265p7Ua+Hc-ahj@mail.gmail.com>

On Tue, Oct 12, 2010 at 11:58 AM, Brian Johnson <bjohnson at drtel.com> wrote:
>>"Why not look in the BGP table, take every announced ARIN AS number
>>and preemptively assign IPv6 addresses to each associated organization
>>that doesn't already have them? Not forever of course... give it three
>>years and then the assignments evaporate unless claimed by signing an
>>RSA and paying the annual fees."
>
> AS assignment != demonstrated need.

Brian,

I agree. That's why I said _announced_ AS numbers, not merely assigned.

If there's a credible reason to believe that folks announcing IPv4
routes with their own AS number today will radically change course and
deploy IPv6 without announcing their own IPv6 routes tomorrow, I
haven't heard it yet. Have you?

I claim that anyone actually announcing routes with a registry AS
number has demonstrated a defacto need for registry IPv6 addresses.

How does it benefit you and how does it benefit me to wait until the
75% of ISPs that haven't signed on yet get around to asking for IPv6
addresses? It doesn't! Your successful deployment of IPv6 is tied to
theirs. Let's get the allocation process done. These are folks who
won't begin their IPv6 deployment until _after_ they have IPv6
addresses in hand. Every day you save in their deployment process
benefits _you_.

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  Tue Oct 12 14:32:14 2010
From: ggiesen at akn.ca (Gary T. Giesen)
Date: Tue, 12 Oct 2010 14:32:14 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTimrLtPpbN6L-EYc_kAqMh8kxh265p7Ua+Hc-ahj@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47021D8C8E@ex01.drtel.la n>
	<AANLkTimrLtPpbN6L-EYc_kAqMh8kxh265p7Ua+Hc-ahj@mail.gmail.com>
Message-ID: <1286908334.21465.4444.camel@ggiesen-workstation.netsurf.net>

I would say that doing something like APNIC has done (one-click
allocation of v6) is far more useful than summarily handing out
allocations to everyone that you "think" needs one.

GG


On Tue, 2010-10-12 at 14:15 -0400, William Herrin wrote:
> On Tue, Oct 12, 2010 at 11:58 AM, Brian Johnson <bjohnson at drtel.com> wrote:
> >>"Why not look in the BGP table, take every announced ARIN AS number
> >>and preemptively assign IPv6 addresses to each associated organization
> >>that doesn't already have them? Not forever of course... give it three
> >>years and then the assignments evaporate unless claimed by signing an
> >>RSA and paying the annual fees."
> >
> > AS assignment != demonstrated need.
> 
> Brian,
> 
> I agree. That's why I said _announced_ AS numbers, not merely assigned.
> 
> If there's a credible reason to believe that folks announcing IPv4
> routes with their own AS number today will radically change course and
> deploy IPv6 without announcing their own IPv6 routes tomorrow, I
> haven't heard it yet. Have you?
> 
> I claim that anyone actually announcing routes with a registry AS
> number has demonstrated a defacto need for registry IPv6 addresses.
> 
> How does it benefit you and how does it benefit me to wait until the
> 75% of ISPs that haven't signed on yet get around to asking for IPv6
> addresses? It doesn't! Your successful deployment of IPv6 is tied to
> theirs. Let's get the allocation process done. These are folks who
> won't begin their IPv6 deployment until _after_ they have IPv6
> addresses in hand. Every day you save in their deployment process
> benefits _you_.
> 
> Regards,
> Bill Herrin
> 
> 




From cgrundemann at gmail.com  Tue Oct 12 14:51:34 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 12 Oct 2010 12:51:34 -0600
Subject: [arin-ppml] Post-Meeting Revision of 2010-14
In-Reply-To: <AANLkTinLtBF60Mx26PtH7NnMz82a-VodXSjFn3JZMR3x@mail.gmail.com>
References: <AANLkTimswvutx69N8OGWPH-BC4+V=g5Vohh1HE2=34-+@mail.gmail.com>
	<AANLkTinLtBF60Mx26PtH7NnMz82a-VodXSjFn3JZMR3x@mail.gmail.com>
Message-ID: <AANLkTikubRFvDYDx2hWdB0cL4jJMQgfhndV_rvshh7mY@mail.gmail.com>

On Mon, Oct 11, 2010 at 19:29, Scott Leibrand <scottleibrand at gmail.com> wrote:
> Chris,
>
> It looks to me like this text would still require each and every dynamically
> assigned residential block to be SWIPped.? I know we talked about several
> possible solutions to this at the meeting: do you think it would be useful
> to do something like change the first sentence of 6.5.5.1 to read "Each
> static IPv6 assignment" instead of "Each IPv6 assignment"?

I certainly agree that your text captures the intent more explicitly
and I have no problem with that edit.

~Chris

> -Scott
>
>> _______________________________________________
>> 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  Tue Oct 12 14:54:36 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 12 Oct 2010 11:54:36 -0700
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <10093.1286906540@marajade.sandelman.ca>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>	<29A54911243620478FF59F00EBB12F47021D8C8E@ex01.drtel.lan>
	<10093.1286906540@marajade.sandelman.ca>
Message-ID: <4CB4AEEC.6020701@ipinc.net>

On 10/12/2010 11:02 AM, Michael Richardson wrote:
>
> There are many discussions about how giving out address space does not
> cause deployment.   I agree that is is true for ISPs, which is largely
> who is involved in ARIN, and who care about routing table sizes.
>
> It is not the same situation for enterprises.
> Please see debate about non-connected IPv6 allocations starting about a
> year ago.
>
> Few enterprises have any reason to deploy IPv6 today.  While the smart
> ones go and get some address space from a tunnel broker and use that as
> their "site-local" address space, this doesn't work for everyone.
> (We had a long conversation about ULA-Random, and why it also doesn't
> suit everyone).
>
> An enterprise which currently pays no fees to ARIN: either because they
> have no resources (or because they were an early adopter last time, and
> they have only Legacy resources), can not make a business case for
> getting IPv6 space.  Even that ridiculously low cost of $1250 is hard.
>

Correct.  They will use their IPv4 until it's worthless to connect to 
the Internet any further, then they will start paying the $1,250.00 USD
a year.

Might I suggest that ARIN consider instituting MONTHLY billing for these
orgs?  Perhaps sticking them for $150.00 a month instead of $1250 a 
year?  Remember the pointy-haired boss directed Dilbert to purchase a
new computer using about 20 separate PO's for under $500 because that
was his signing authority?  Maybe the same thing would work here, using 
the same principle?

Ted


From mcr at sandelman.ca  Tue Oct 12 15:22:13 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Tue, 12 Oct 2010 15:22:13 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <4CB4AEEC.6020701@ipinc.net> 
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47021D8C8E@ex01.drtel.lan>
	<10093.1286906540@marajade.sandelman.ca>
	<4CB4AEEC.6020701@ipinc.net> 
Message-ID: <20732.1286911333@marajade.sandelman.ca>


>>>>> "Ted" == Ted Mittelstaedt <tedm at ipinc.net> writes:
    Ted> On 10/12/2010 11:02 AM, Michael Richardson wrote:
    >> There are many discussions about how giving out address space
    >> does not cause deployment.  I agree that is is true for ISPs,
    >> which is largely who is involved in ARIN, and who care about
    >> routing table sizes.
    >> 
    >> It is not the same situation for enterprises.  Please see debate
    >> about non-connected IPv6 allocations starting about a year ago.
    >> 
    >> Few enterprises have any reason to deploy IPv6 today.  While the
    >> smart ones go and get some address space from a tunnel broker and
    >> use that as their "site-local" address space, this doesn't work
    >> for everyone.  (We had a long conversation about ULA-Random, and
    >> why it also doesn't suit everyone).
    >> 
    >> An enterprise which currently pays no fees to ARIN: either
    >> because they have no resources (or because they were an early
    >> adopter last time, and they have only Legacy resources), can not
    >> make a business case for getting IPv6 space.  Even that
    >> ridiculously low cost of $1250 is hard.
    >> 

    Ted> Correct.  They will use their IPv4 until it's worthless to
    Ted> connect to the Internet any further, then they will start
    Ted> paying the $1,250.00 USD a year.

    Ted> Might I suggest that ARIN consider instituting MONTHLY billing
    Ted> for these orgs?  Perhaps sticking them for $150.00 a month
    Ted> instead of $1250 a year?  Remember the pointy-haired boss
    Ted> directed Dilbert to purchase a new computer using about 20
    Ted> separate PO's for under $500 because that was his signing
    Ted> authority?  Maybe the same thing would work here, using the
    Ted> same principle?

Thank you, you said it better than I could.
$1250 is not very much, but it is enough that it prevents organizations
from getting it because of authorization levels required.

-- 
]       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 mcr at novavision.ca  Tue Oct 12 15:27:15 2010
From: mcr at novavision.ca (Michael Richardson)
Date: Tue, 12 Oct 2010 15:27:15 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTimrLtPpbN6L-EYc_kAqMh8kxh265p7Ua+Hc-ahj@mail.gmail.com> 
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47021D8C8E@ex01.drtel.lan>
	<AANLkTimrLtPpbN6L-EYc_kAqMh8kxh265p7Ua+Hc-ahj@mail.gmail.com> 
Message-ID: <20835.1286911635@marajade.sandelman.ca>


>>>>> "William" == William Herrin <bill at herrin.us> writes:
    William> On Tue, Oct 12, 2010 at 11:58 AM, Brian Johnson
    William> <bjohnson at drtel.com> wrote:
    >>> "Why not look in the BGP table, take every announced ARIN AS
    >>> number and preemptively assign IPv6 addresses to each associated
    >>> organization that doesn't already have them? Not forever of
    >>> course... give it three years and then the assignments evaporate
    >>> unless claimed by signing an RSA and paying the annual fees."
    >> AS assignment != demonstrated need.

    William> Brian,

    William> I agree. That's why I said _announced_ AS numbers, not
    William> merely assigned.

    William> If there's a credible reason to believe that folks
    William> announcing IPv4 routes with their own AS number today will
    William> radically change course and deploy IPv6 without announcing
    William> their own IPv6 routes tomorrow, I haven't heard it
    William> yet. Have you?

    William> I claim that anyone actually announcing routes with a
    William> registry AS number has demonstrated a defacto need for
    William> registry IPv6 addresses.

I just wish that BGP4 announced both IPv4 and IPv6 prefixes on either v4
or v6 transports.  I think that there isn't anything preventing it in
the protocol, but all the routers I've seen announce
v4-over-v4-transport and s/4/6/. 

Why do I wish this? Because the enterprise that has his new IPv6 prefix
can then just announce it upstream.  One of three things happens:
    a) the upstream router dies because it's not just not IPv6-enabled,
       but it's IPv6-intolerant (router gets replaced, or ISP gets
       replaced)

    b) some SNMP trap or log entry announces to upstream ISP that they
       have another customer who is now IPv6 enabled, whose needs they
       are not serving.

    c) it just works, turns out the upstream is IPv6 enabled, but nobody
       thought it important to tell the customers.

-- 
]   Michael Richardson,       -write something here-           [         
]     mcr at novavision.ca      http://www.novavision.ca/         [
]     mcr at credil.org         http://www.credil.org/            [
]     mcr at sandelman.ca       http://www.sandelman.ca/          [


From bill at herrin.us  Tue Oct 12 15:37:39 2010
From: bill at herrin.us (William Herrin)
Date: Tue, 12 Oct 2010 15:37:39 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <20732.1286911333@marajade.sandelman.ca>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47021D8C8E@ex01.drtel.lan>
	<10093.1286906540@marajade.sandelman.ca>
	<4CB4AEEC.6020701@ipinc.net> <20732.1286911333@marajade.sandelman.ca>
Message-ID: <AANLkTimduTRGc1uYBgZ6UcfzaX6f2xftn10Z7nh7YOYn@mail.gmail.com>

On Tue, Oct 12, 2010 at 3:22 PM, Michael Richardson <mcr at sandelman.ca> wrote:
> $1250 is not very much, but it is enough that it prevents organizations
> from getting it because of authorization levels required.

Folks, we can easily get lost in whether or not this observation is
reasonable. Reasonable or not, it's reality. The question for the rest
of us, then, is this:

Do we want to sit around and wait for these guys while maintaining our
costly dual stacks? Or should we remove the issue from the equation so
that it no longer stands in the way of any IPv6 deployments?

Preemptive assignment is no magic bullet. Some of these folks will
just find the next reason for delay. But why allow ARIN to be the
reason they haven't deployed yet?

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 tedm at ipinc.net  Tue Oct 12 15:46:46 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 12 Oct 2010 12:46:46 -0700
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTimduTRGc1uYBgZ6UcfzaX6f2xftn10Z7nh7YOYn@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47021D8C8E@ex01.drtel.lan>
	<10093.1286906540@marajade.sandelman.ca>
	<4CB4AEEC.6020701@ipinc.net>
	<20732.1286911333@marajade.sandelman.ca>
	<AANLkTimduTRGc1uYBgZ6UcfzaX6f2xftn10Z7nh7YOYn@mail.gmail.com>
Message-ID: <4CB4BB26.60606@ipinc.net>

On 10/12/2010 12:37 PM, William Herrin wrote:
> On Tue, Oct 12, 2010 at 3:22 PM, Michael Richardson<mcr at sandelman.ca>  wrote:
>> $1250 is not very much, but it is enough that it prevents organizations
>> from getting it because of authorization levels required.
>
> Folks, we can easily get lost in whether or not this observation is
> reasonable. Reasonable or not, it's reality. The question for the rest
> of us, then, is this:
>
> Do we want to sit around and wait for these guys while maintaining our
> costly dual stacks? Or should we remove the issue from the equation so
> that it no longer stands in the way of any IPv6 deployments?
>
> Preemptive assignment is no magic bullet. Some of these folks will
> just find the next reason for delay. But why allow ARIN to be the
> reason they haven't deployed yet?
>

I guess I have ot ask why do I care if a private commercial enterprise 
that is not an ISP wants to use IPv4 for the next 100 years?

I would daresay there's still orgs out there running thinnet.  Do I 
care?  Does it offend my sensibilities?

I find the discussion of what private orgs want to do rather pointless.
While some of them have very impressive networks from the perspective
of how many nodes they have, the only people who give a damn outside
the orgs are the vendors who want to sell equipment to them.

There's still people using horses and buggies to get around on the
roads.


Ted


From Wesley.E.George at sprint.com  Tue Oct 12 17:37:50 2010
From: Wesley.E.George at sprint.com (George, Wes E IV [NTK])
Date: Tue, 12 Oct 2010 21:37:50 +0000
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <10093.1286906540@marajade.sandelman.ca>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47021D8C8E@ex01.drtel.lan>
	<10093.1286906540@marajade.sandelman.ca>
Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E6FE9@PLSWM12A.ad.sprint.com>

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Michael Richardson
> Sent: Tuesday, October 12, 2010 2:02 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Preemptive IPv6 assignment
>
> An enterprise which currently pays no fees to ARIN: either because they
> have no resources (or because they were an early adopter last time, and
> they have only Legacy resources), can not make a business case for
> getting IPv6 space.  Even that ridiculously low cost of $1250 is hard.
>

[WES] Not trying to minimize the pain of justifying the costs of deploying IPv6 - I've been living it for years at a much larger scale, and it doesn't get easier just because the company is bigger. However...PD space (assuming your upstream does IPv6) obviates this argument 99% of the time because there are no ARIN fees to pay. If renumbering is more expensive than the ARIN fee for PI space, that makes your business case for you, otherwise you should be using PD.

Wes George

________________________________

This e-mail may contain Sprint Nextel 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 Wesley.E.George at sprint.com  Tue Oct 12 17:38:42 2010
From: Wesley.E.George at sprint.com (George, Wes E IV [NTK])
Date: Tue, 12 Oct 2010 21:38:42 +0000
Subject: [arin-ppml] v6 AFI over v4 BGP (was Preemptive IPv6 assignment)
In-Reply-To: <20835.1286911635@marajade.sandelman.ca>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47021D8C8E@ex01.drtel.lan>
	<AANLkTimrLtPpbN6L-EYc_kAqMh8kxh265p7Ua+Hc-ahj@mail.gmail.com>
	<20835.1286911635@marajade.sandelman.ca>
Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E6FEE@PLSWM12A.ad.sprint.com>

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Michael Richardson
> Sent: Tuesday, October 12, 2010 3:27 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Preemptive IPv6 assignment
>
> I just wish that BGP4 announced both IPv4 and IPv6 prefixes on either
> v4
> or v6 transports.  I think that there isn't anything preventing it in
> the protocol, but all the routers I've seen announce
> v4-over-v4-transport and s/4/6/.
>

[WES] Change of subject line to reflect new topic.
This does work. It just doesn't work particularly *well* because a number of router vendors have implemented next-hop handling strangely, where the route announcement gets dropped by the neighboring router because it's announced with a v4-mapped v6 next-hop or a link-local next-hop, both seen as invalid by the upstream router due to no route to next-hop. We're using a single IPv4 BGP session for both IPv4 and IPv6 unicast AFs for our iBGP sessions, but as it was we had to add route-policies to force the correct next-hop to be set (pending resolution of a couple of bugs), and configuring next-hop-self doesn't always fix. Because we have no way of knowing whether $CPE_vendor supports it correctly in the combination of software and hardware that our customers are running, we default to separate BGP sessions per AF for eBGP.

That said, I don't think it would be as simple as you paint it, because even if you assume that the PTP link addresses sort themselves out automagically, if you're doing BGP, how do you determine what next-hop to announce the routes with? Even if the bugs I detailed above are fixed, they assume that you have a routable next-hop to announce IPv6 routes with. What about BGP filters and max prefix limits that your upstream normally applies to your session? Ultimately, just like with IPv4, a customer is going to have to talk to their provider to get IPv6/BGP set up, there's really no way to completely avoid coordination and have it "just work."

I'm not convinced that this would fundamentally change the speed of deployment anyway. Setting up BGP with your upstream to support IPv6 is easy in comparison to actually having an upstream that supports it and getting all of the devices in your enterprise to be able to do something with that prefix you got.

Wes George

________________________________

This e-mail may contain Sprint Nextel 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 mcr at sandelman.ca  Tue Oct 12 20:55:00 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Tue, 12 Oct 2010 20:55:00 -0400
Subject: [arin-ppml] v6 AFI over v4 BGP (was Preemptive IPv6 assignment)
In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E6FEE@PLSWM12A.ad.sprint.com> 
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47021D8C8E@ex01.drtel.lan>
	<AANLkTimrLtPpbN6L-EYc_kAqMh8kxh265p7Ua+Hc-ahj@mail.gmail.com>
	<20835.1286911635@marajade.sandelman.ca>
	<54E900DC635DAB4DB7A6D799B3C4CD8E6FEE@PLSWM12A.ad.sprint.com> 
Message-ID: <9033.1286931300@marajade.sandelman.ca>


>>>>> "Wes" == Wes E IV George <George> writes:
    Wes> [WES] Change of subject line to reflect new topic.  This does
    Wes> work. It just doesn't work particularly *well* because a number
    Wes> of router vendors have implemented next-hop handling strangely,
    Wes> where the route announcement gets dropped by the neighboring
    Wes> router because it's announced with a v4-mapped v6 next-hop or a
    Wes> link-local next-hop, both seen as invalid by the upstream
    Wes> router due to no route to next-hop. We're using a single IPv4
    Wes> BGP session for both IPv4 and IPv6 unicast AFs for our iBGP
    Wes> sessions, but as it was we had to add route-policies to force
    Wes> the correct next-hop to be set (pending resolution of a couple
    Wes> of bugs), and configuring next-hop-self doesn't always
    Wes> fix. Because we have no way of knowing whether $CPE_vendor
    Wes> supports it correctly in the combination of software and
    Wes> hardware that our customers are running, we default to separate
    Wes> BGP sessions per AF for eBGP.

    Wes> That said, I don't think it would be as simple as you paint it,
    Wes> because even if you assume that the PTP link addresses sort
    Wes> themselves out automagically, if you're doing BGP, how do you

Well, really I would be very worried if it was as simple as I'd
suggested :-)

The ideal situation is really that I'd want people to say, "hey, what
are these complaints in my logs about invalid IPv6 nexthops from
provider FOO? "

    Wes> I'm not convinced that this would fundamentally change the
    Wes> speed of deployment anyway. Setting up BGP with your upstream
    Wes> to support IPv6 is easy in comparison to actually having an
    Wes> upstream that supports it and getting all of the devices in
    Wes> your enterprise to be able to do something with that prefix you
    Wes> got.

Again, a provider with errors in their logs because their customers are
ahead of them is a good thing.

-- 
]       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 marka at isc.org  Tue Oct 12 23:55:20 2010
From: marka at isc.org (Mark Andrews)
Date: Wed, 13 Oct 2010 14:55:20 +1100
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
Message-ID: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>


There is a increadable amount of bad information being spouted here.

To deploy 6rd in parallel with a native deployment you roughly need
double the IPv6 address space of a straight native deployment.

You need a /56 (/48) for every address in the DHCPv4 pools.  For
each DHCP pool you specify a 6rd prefix and set the IPv4MaskLen and
6rdPrefixlen so you are not wasting IPv6 space.

e.g.
If you have a 2 disjoint /16's spead over, multiple pops, then you
will have 2 6rd prefixes in use both with a IPv4MaskLen of 16.  Only
one of these will be handed out to a specific customer.  If you are
handing out /56's then the 6rdPrefixLen would be 40.  Each of these
6rd prefixes would be a /40.

If you are handing out NATed addresses to your customers then you
may need to be more conservative in your DHCP pool sizes as the
pool size impacts on the amount of IPv6 address space needed.

If you are not using DHCPv4 for this you will most probably want to
code up a web page that returns custom 6rd parameter result based
on the IPv4 address the query came from plus the ablity to manually
specify the address that you want the 6rd parameters for.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: marka at isc.org


From bill at herrin.us  Wed Oct 13 07:23:17 2010
From: bill at herrin.us (William Herrin)
Date: Wed, 13 Oct 2010 07:23:17 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
Message-ID: <AANLkTimRZxotiHhy7h4rwTcdZCYd1SLmmiRug-UaxhfV@mail.gmail.com>

On Tue, Oct 12, 2010 at 11:55 PM, Mark Andrews <marka at isc.org> wrote:
> There is a increadable amount of bad information being spouted here.
>
> If you have a 2 disjoint /16's spead over, multiple pops, then you
> will have 2 6rd prefixes in use both with a IPv4MaskLen of 16. ?Only
> one of these will be handed out to a specific customer. ?If you are
> handing out /56's then the 6rdPrefixLen would be 40. ?Each of these
> 6rd prefixes would be a /40.

Hi Mark,

If you have a dozen IPv4 prefixes or more (as many ISPs do) you're not
going to maintain a dozen or more 6rd prefixes. Instead, you're going
to map a full 32 bits into a single 6rd prefix. That's the _practical
reality_ of an operational network, regardless of what 6rd's designers
intended. If you don't map 32 bits, you'll at least map your entire
CGN space in 10.0.0.0/8, and that takes a few bits all by itself.

The discussion has been focused on those folks for whom 6rd is not
useful unless the full 32 bits are mapped. This is not surprising
since any organization small enough to maintain shorter mappings has
no trouble fitting 6rd into their original /32 allocation and thus
doesn't need new policy.

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  Wed Oct 13 07:35:40 2010
From: bill at herrin.us (William Herrin)
Date: Wed, 13 Oct 2010 07:35:40 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <4CB4BB26.60606@ipinc.net>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47021D8C8E@ex01.drtel.lan>
	<10093.1286906540@marajade.sandelman.ca>
	<4CB4AEEC.6020701@ipinc.net> <20732.1286911333@marajade.sandelman.ca>
	<AANLkTimduTRGc1uYBgZ6UcfzaX6f2xftn10Z7nh7YOYn@mail.gmail.com>
	<4CB4BB26.60606@ipinc.net>
Message-ID: <AANLkTi=4m9f7zPaNKtzC5-Ga92w6uRU3udCMLLPn=wmJ@mail.gmail.com>

On Tue, Oct 12, 2010 at 3:46 PM, Ted Mittelstaedt <tedm at ipinc.net> wrote:
> On 10/12/2010 12:37 PM, William Herrin wrote:
>> Preemptive assignment is no magic bullet. Some of these folks will
>> just find the next reason for delay. But why allow ARIN to be the
>> reason they haven't deployed yet?
>
> I guess I have ot ask why do I care if a private commercial enterprise that
> is not an ISP wants to use IPv4 for the next 100 years?

Hi Ted,

Private disconnected networks aren't under discussion here. I don't
care what protocol they use either.

We're talking only about folks who already announce routes into the
public BGP table. If you do any commerce with these folks (and you do)
then you're going to maintain connectivity to them. Until they deploy
IPv6, you will maintain IPv4 connectivity despite the extra cost.

Money. Their non-deployment of IPv6 costs you money. That's why you care.


On Tue, Oct 12, 2010 at 5:37 PM, George, Wes E IV [NTK]
<Wesley.E.George at sprint.com> wrote:
> PD space (assuming your upstream does IPv6) obviates this
> argument 99% of the time because there are no ARIN fees to
> pay. If renumbering is more expensive than the ARIN fee for
> PI space, that makes your business case for you, otherwise
> you should be using PD.

If your percentage is on target then the folks we're talking about
here -- those who already announce routes into the BGP table -- are
squarely within the 1% for whom ISP space does not fit. We know this
because gee, they have an ARIN AS number and are announcing routes
into the BGP table. Anybody can claim need but demonstration doesn't
get much clearer than actual BGP routing on the public Internet.

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  Wed Oct 13 07:46:10 2010
From: bill at herrin.us (William Herrin)
Date: Wed, 13 Oct 2010 07:46:10 -0400
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated Transfer
	Policy
In-Reply-To: <4CB34773.2070308@arin.net>
References: <4CB34773.2070308@arin.net>
Message-ID: <AANLkTimzM66Pvs_2ax__C1hy=2bSWURh6qs6qAd33C1X@mail.gmail.com>

On Mon, Oct 11, 2010 at 1:20 PM, ARIN <info at arin.net> wrote:
> Policy Proposal 119: Globally Coordinated Transfer Policy
>
> Policy statement: Any RIR's member may transfer IPv4 addresses to the
> member of another RIR as long as the two RIRs agree and exercise
> Internet stewardship and the values expressed in RFC2050.

"two RIRs agree" is slightly fuzzy. I suggest slightly  more words:

"so long as the transfer is consistent with both RIR policies for the
inter-region transfer of addresses."

I'd also ditch the stewardship line. It adds fuzziness that's
difficult to evaluate in a practical and consistent way. Besides, if
both RIRs set policy to a different standard of stewardship, why tie
their hands?

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 BillD at cait.wustl.edu  Wed Oct 13 08:07:13 2010
From: BillD at cait.wustl.edu (Bill Darte)
Date: Wed, 13 Oct 2010 07:07:13 -0500
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated Transfer
	Policy
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087B5D3A0@ex1.cait.wustl.edu>

Hello,
 
ARIN has received a proposal for a global, inter-RIR transfer policy
<https://www.arin.net/policy/proposals/policy_proposal_archive.html> .
This policy authored by Chris Grundemann, Martin Hannigan and Jason
Schiller is currently under review by ARIN staff for clarity and
understanding, conforming to the current Policy Development Process
<https://www.arin.net/policy/pdp.html>  of the ARIN Region.
 
Rob Seastrom and Bill Darte have been named the secondary and primary
shepherds within the Advisory Council(AC) for this proposal.
 
Both Rob and I encourage the community to comment on this proposal and
especially ask that posters to the PPML list their comments PRO and CON
in a conscise manner.  This will allow readers within the community to
best assess the merits of this proposal and give guidance to the AC
whether to accept it onto its docket as a Draft Proposal.  The AC meets
again November.
 
Thanks to the authors and to the community for their continued
involvement and support of the ARIN mission in the policy development
process.
 
Bill Darte
Primary Shepherd PP 119
ARIN Advisory Council
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101013/428ea0e0/attachment.htm>

From michael.dillon at bt.com  Wed Oct 13 08:55:38 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 13 Oct 2010 13:55:38 +0100
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated
	Transfer	Policy
In-Reply-To: <AANLkTimzM66Pvs_2ax__C1hy=2bSWURh6qs6qAd33C1X@mail.gmail.com>
References: <4CB34773.2070308@arin.net>
	<AANLkTimzM66Pvs_2ax__C1hy=2bSWURh6qs6qAd33C1X@mail.gmail.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B4239378EAAC3@EMV01-UKBR.domain1.systemhost.net>

> > Policy statement: Any RIR's member may transfer IPv4 addresses to the
> > member of another RIR as long as the two RIRs agree and exercise
> > Internet stewardship and the values expressed in RFC2050.
> 
> "two RIRs agree" is slightly fuzzy. I suggest slightly  more words:
> 
> "so long as the transfer is consistent with both RIR policies for the
> inter-region transfer of addresses."
> 
> I'd also ditch the stewardship line. It adds fuzziness that's
> difficult to evaluate in a practical and consistent way. Besides, if
> both RIRs set policy to a different standard of stewardship, why tie
> their hands?

Given that there is no requirement for IP address blocks to be used
in any specific region and there is no requirement for organizations
to do business with the nearest RIR, I don't see any useful purpose
for this kind of policy.

Expect in one case, where an organization who already deals with RIR A
acquires a block of addresses registered with RIR B. In that case it
is reasonable for the recipient to not have to open and manage a 
second RIR relationship.

But the policy doesn't say that, and I am wondering why.

In fact, I find the proposed text very unclear if you use the dictionary
meaning of the words. I looked in section two of the NRPM (Definitions) 
and did not see a special definition of the word "transfer". I don't believe
it is in our interests to create new ambiguous jargon, so I would like 
to see this policy expressed in clear language before forming a final
opinion of it.

For example, my current employer acquired a number of address blocks by
transfer from acquring my previous employer, who in turn acquired those
addresses by transfer when being spun out of a parent company, who in
turn acquired those addresses by transfer from a company that they acquired.
These are transfers but any new policy should be worded in a way to have
zero impact on such transfers. Or it should explain clearly why we need
to change things in that area.

At present count me in the CON column.

--Michael Dillon



From marka at isc.org  Wed Oct 13 08:57:18 2010
From: marka at isc.org (Mark Andrews)
Date: Wed, 13 Oct 2010 23:57:18 +1100
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: Your message of "Wed, 13 Oct 2010 07:23:17 EDT."
	<AANLkTimRZxotiHhy7h4rwTcdZCYd1SLmmiRug-UaxhfV@mail.gmail.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org><AANLkTimRZxotiHhy7h4rwTcdZCYd1SLmmiRug-UaxhfV@mail.gmail.com>
Message-ID: <20101013125718.4F1BF5AF865@drugs.dv.isc.org>


In message <AANLkTimRZxotiHhy7h4rwTcdZCYd1SLmmiRug-UaxhfV at mail.gmail.com>, Will
iam Herrin writes:
> On Tue, Oct 12, 2010 at 11:55 PM, Mark Andrews <marka at isc.org> wrote:
> > There is a increadable amount of bad information being spouted here.
> >
> > If you have a 2 disjoint /16's spead over, multiple pops, then you
> > will have 2 6rd prefixes in use both with a IPv4MaskLen of 16. =A0Only
> > one of these will be handed out to a specific customer. =A0If you are
> > handing out /56's then the 6rdPrefixLen would be 40. =A0Each of these
> > 6rd prefixes would be a /40.
> 
> Hi Mark,
> 
> If you have a dozen IPv4 prefixes or more (as many ISPs do) you're not
> going to maintain a dozen or more 6rd prefixes. Instead, you're going
> to map a full 32 bits into a single 6rd prefix. That's the _practical
> reality_ of an operational network, regardless of what 6rd's designers
> intended. If you don't map 32 bits, you'll at least map your entire
> CGN space in 10.0.0.0/8, and that takes a few bits all by itself.

Why not?  It's a one time operation to setup it up when you are
allocated a IPv4 prefix from a RIR/LIR.

> The discussion has been focused on those folks for whom 6rd is not
> useful unless the full 32 bits are mapped. This is not surprising
> since any organization small enough to maintain shorter mappings has
> no trouble fitting 6rd into their original /32 allocation and thus
> doesn't need new policy.

Sorry no one needs to have the full /32 bits encoded into a 6rd
prefix.  No one here has addresses allocated from all 221 /8's that
make up the global unicast IPv4 address space.  Most of you would
have address from at most a handful of /8s.  If you must be lazy
then setup a 6rd per covering /8 from which you have addresses
allocated.

> Regards,
> Bill Herrin
> 
> 
> --=20
> William D. Herrin ................ herrin at dirtside.com=A0 bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From Wesley.E.George at sprint.com  Wed Oct 13 09:39:07 2010
From: Wesley.E.George at sprint.com (George, Wes E IV [NTK])
Date: Wed, 13 Oct 2010 13:39:07 +0000
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTi=4m9f7zPaNKtzC5-Ga92w6uRU3udCMLLPn=wmJ@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47021D8C8E@ex01.drtel.lan>
	<10093.1286906540@marajade.sandelman.ca>	<4CB4AEEC.6020701@ipinc.net>
	<20732.1286911333@marajade.sandelman.ca>
	<AANLkTimduTRGc1uYBgZ6UcfzaX6f2xftn10Z7nh7YOYn@mail.gmail.com>
	<4CB4BB26.60606@ipinc.net>
	<AANLkTi=4m9f7zPaNKtzC5-Ga92w6uRU3udCMLLPn=wmJ@mail.gmail.com>
Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E74B0@PLSWM12A.ad.sprint.com>


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of William Herrin
> Sent: Wednesday, October 13, 2010 7:36 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Preemptive IPv6 assignment

> On Tue, Oct 12, 2010 at 5:37 PM, George, Wes E IV [NTK]
> <Wesley.E.George at sprint.com> wrote:
> > PD space (assuming your upstream does IPv6) obviates this
> > argument 99% of the time because there are no ARIN fees to
> > pay. If renumbering is more expensive than the ARIN fee for
> > PI space, that makes your business case for you, otherwise
> > you should be using PD.
>
> If your percentage is on target then the folks we're talking about
> here -- those who already announce routes into the BGP table -- are
> squarely within the 1% for whom ISP space does not fit. We know this
> because gee, they have an ARIN AS number and are announcing routes
> into the BGP table. Anybody can claim need but demonstration doesn't
> get much clearer than actual BGP routing on the public Internet.

[WES] and from a previous mail:
>I claim that anyone actually announcing routes with a registry AS
>number has demonstrated a defacto need for registry IPv6 addresses.

[WES] No, having a registry AS# and announcing routes != having an allocation from $registry. It simply means that they are multihomed. There are plenty of networks who get PD IPv4 from one or more upstreams and announce it to all of them via BGP.
I acknowledge that multihoming with PD space in IPv6 is not necessarily attractive due to risks of your subnet announcements being filtered on some networks, but it's not impossible, nor is that germane to the discussion.

Either way, the point being made referred to cost (ARIN fees) as a barrier, not ability to get space (demonstrated need), and PD is a viable solution for at least some of the folks experiencing that financial problem. Simply handing everyone space won't change that, because if they start using it, they're still responsible for the fees.

I simply don't see the point at which this helps spur deployment. The turnaround time on processing new IPv6 address requests is not so high that pre-allocating will fundamentally save us anything, because it doesn't move the needle in terms of when it actually gets *deployed* and *used* inside of any network that currently isn't doing either. If the problem is that those who need it can't get it, propose policy to fix that. If the problem is that those who need it and want to deploy can't afford it, propose policy to fix that. This isn't a solution to either problem.

Wes George

________________________________

This e-mail may contain Sprint Nextel 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 bicknell at ufp.org  Wed Oct 13 09:42:43 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 13 Oct 2010 06:42:43 -0700
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated Transfer
	Policy
In-Reply-To: <4CB34773.2070308@arin.net>
References: <4CB34773.2070308@arin.net>
Message-ID: <20101013134243.GA81926@ussenterprise.ufp.org>

In a message written on Mon, Oct 11, 2010 at 01:20:51PM -0400, ARIN wrote:
> Policy statement: Any RIR's member may transfer IPv4 addresses to the
> member of another RIR as long as the two RIRs agree and exercise
> Internet stewardship and the values expressed in RFC2050.

I applaud the attempt at super-simple policy.  It is refreshing.

That said, I wish to play a sort of devils advocate for a moment.

There are activities one RIR's community thinks are "bad", but that
other RIR's communities seem to think are "good".  To some extent
that is why we have separate RIR's, but there is also a desire to
limit the badness globally.  I believe the references to RFC2050
are an attempt to restate such a global limit.

Unfortunately RFC2050 is already long in the tooth, and with the
impending IPv4 exhaustion will become less relevant very quickly.
In particular, I think if you look at a post run-out world, it is
likely different people will come to the same conclusion about the
text in various areas.

To that end, I'm actually not sure what the effect of this policy
would be down the road, and being unable to evaluate that effect I
find I cannot support it.

If you don't care about the details, stop reading now, if you do,
continue.

Let's fast forward 2-3 years from now to a world where IANA and all 5
RIR's are "out" for all practical purposes, and look at some of the
statements in RFC 2050 from that context.

Right from the start, there is something quite interesting:

   By approving this document as a Best Current Practice,the IESG
   asserts its belief that this policy described herein is an accurate
   representation of the current practice of the IP address registries
   with respect to address assignment.  This does not constitute
   endorsement or recommendation of this policy by the IESG. The IESG
   will reevaluate its approval of this document in December 1997 taking
   into consideration the results of the discussions that will be take
   place in the IRE Working Group between now and then.

The document is not a standards track RFC, it is a documentation of the
Best Current Practice /in 1996/.  Indeed, I actually think it's well
overdue to be updated to current practice, but that's another discussion
for another day.

  1) Conservation: Fair distribution of globally unique Internet address
     space according to the operational needs of the end-users and Internet
     Service Providers operating networks using this address space.
     Prevention of stockpiling in order to maximize the lifetime of the
     Internet address space.

"Fair distribution" is a very simple thing when there are plenty of
addresses, we can use the Chinese buffet model (take all you want, eat
all you take).  When there is no more space, and we're looking at a
transfer market (paid or otherwise) it takes on an entirely different
color.  Do we have to ensure everyone gets some, regardless of ability
to pay?  Is distribution based on who has the most money fair?  Does
fairness require the RIR's to more aggressively revoke space from those
who are not using it to fairly distribute to those who need it?  The
last sentence about stockpiling would seem to indicate that is
important.

      (Under the end user "Assignment Framework" section)

      c)  the organization's actual requirement for IP space is
          very large, for example, the network prefix required to
          cover the request is of length /18 or shorter.

All of the RIR's have changed their policy to allow longer than /18
prefixes to end users, and I think off the top of my head many now allow
longer prefixes to end users than ISP's.  As we get closer to
exhaustion, prefix length will get smaller.

   Organizations will be assigned address space based on immediate
   utilization plus 1 year projected utilization.  A prefix longer than
   /24 may be issued if deemed appropriate.  Organizations with less
   than 128 hosts will not be issued an IP address directly from the
   IRs.  Organizations may be issued a prefix longer than /24 if the
   organization can provide documentation from a registry recognized ISP
   indicating the ISP will accept the long prefix for injection into the
   global routing system.

I believe there are already web-hosters who have less than "128
hosts", but have received space because they host hundreds of web
sites, each of which might need an IP address.

I'm not pointing these out to argue about any of them individually,
but simply to point out the document, like any, becomes less relevant
over time.  This makes sense, as it is a best current practice, and
not the hard and fast requirements many seem to want to make it.

We're now in a post run out world, and want to assess "need".  There
will be thousands of folks who can demonstrate technical need the
way we have always done it, but we can't service them all.  So a
new criteria needs to be added into the mix.  All of the RIR's seem
to be moving to money via some mechanism for paid transfers.
Economists and capitalists would love this, since clearly those
with the greatest need for a resource are the ones willing to pay
the most money.

It is easy to see an argument being made as this backlog of need
increases that much of (but not all) our current work to verify
need is unnecessary.  Why spend hours verifying an organization
"needs" a /16 and checking all of their engineering plans when all
they can buy in the market place is a /24?  And if they are willing
to pay $50,000 for that /24, isn't that a better indicator of how
much they need it than any engineering plan?

I'm not sure an RIR could argue a pure dollar based method passes
the smell test, for instance 2050 does suggest "Prevention of
stockpiling in order to maximize the lifetime of the Internet address
space.", so perhaps they have to insure someone isn't just buying
it up to stockpile.  However in such a scheme it would be easy to
say your engineering plans do not need to be reviewed unless you
have paid for more than a /20, because if you have very small amounts
of space its rather hard to call it stockpiling.

In short, I fear the best practice that is 2050 is far shaker ground
going forward than many realize.  It won't ever be tested in a
court, but it will be continuously tested in the court of public
opinion.  It is though a snapshot in time of a continuously evolving
process where we have already seen fit to change its guidance.  I
can easily see a future where four of the five RIR's decide a practice
is the best current practice in the future, but one of the four is
a hold out for whatever reason.  To the extent this is a global policy,
IANA would likely side with the four, noting the represent community
consensus.

While IPv4 is getting all the attention at the current time, IPv6
is, as usual, the more interesting topic.  I urge you to consider
a world 20 years from now, where IPv4 has been removed from all of
the large Internet backbones and we're operating in a primarily
IPv6 only world.  Now re-read 2050.  Does it make sense?  How much
of it matches the best current practice in this future world?

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

From owen at delong.com  Wed Oct 13 10:00:41 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 13 Oct 2010 07:00:41 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
Message-ID: <2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>


On Oct 12, 2010, at 8:55 PM, Mark Andrews wrote:

> 
> There is a increadable amount of bad information being spouted here.
> 
> To deploy 6rd in parallel with a native deployment you roughly need
> double the IPv6 address space of a straight native deployment.
> 
> You need a /56 (/48) for every address in the DHCPv4 pools.  For
> each DHCP pool you specify a 6rd prefix and set the IPv4MaskLen and
> 6rdPrefixlen so you are not wasting IPv6 space.
> 
That is not the common practice.

> e.g.
> If you have a 2 disjoint /16's spead over, multiple pops, then you
> will have 2 6rd prefixes in use both with a IPv4MaskLen of 16.  Only
> one of these will be handed out to a specific customer.  If you are
> handing out /56's then the 6rdPrefixLen would be 40.  Each of these
> 6rd prefixes would be a /40.
> 
For the handful  of providers that have only 2 prefixes, that may be.
For the vast majority of providers, the common practice (having more
than a couple of prefixes) is to map the entire IPV4 space onto
a customer prefix size (e.g. /56) yielding a need for a /24 (56-32)
prefix for the ISP. Since no ISP has a significant fraction of the
IPv4 space, much of that /24 is wasted.

> If you are handing out NATed addresses to your customers then you
> may need to be more conservative in your DHCP pool sizes as the
> pool size impacts on the amount of IPv6 address space needed.
> 
> If you are not using DHCPv4 for this you will most probably want to
> code up a web page that returns custom 6rd parameter result based
> on the IPv4 address the query came from plus the ablity to manually
> specify the address that you want the 6rd parameters for.
> 
Regardless of the IPv4 address assignment method, 	the most common
and most likely 6rd deployment mechanisms are incredibly wasteful
of IPv6 address space. Further, limiting end customers to /56 is
also a suboptimal IPv6 deployment.

Unfortunately, the current state of last-mile technologies being the
abysmal mess that it is, we basically have not choice other than
providing for 6rd as an immediate deployment mechanism. As
such, it should be done with the following safeguards:

+	Allocations from a specific prefix to facilitate a community decision
	to deprecate the technology when it is no longer necessary.

+	Native deployments should not be shared among the same
	IPv6 prefix.

+	We should make strong efforts to communicate and preserve
	the notion that this is a transitional and therefore temporary
	solution. That last mile technologies must catch up and
	provide reasonable and workable native IPv6 solutions.

Owen



From michael.dillon at bt.com  Wed Oct 13 10:19:23 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 13 Oct 2010 15:19:23 +0100
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B4239378EAB83@EMV01-UKBR.domain1.systemhost.net>

> +	We should make strong efforts to communicate and preserve
> 	the notion that this is a transitional and therefore temporary
> 	solution. That last mile technologies must catch up and
> 	provide reasonable and workable native IPv6 solutions.

If you apply for an ASN successfully, you get an email that says, 
ARIN has allocated an ASN for you. When you pay the bill, we will
send another email telling you what it is.

So, for 6RD allocations how about sending an email that says
ARIN has allocated an IPv6 allocation for you to use with 6RD
and when you return the attached document with the signature
of a company officer, we will send another email telling you 
what your IPv6 allocation is.

The attached document will be an undertaking to use the allocation
only for 6RD and similar transition technologies and to provide
ARIN with an annual report on the status of the organization's
transition to native IPv6 services. The undertaking will define which
things must be reported in the annual report and some of those
things will be published by ARIN. Other will be kept confidential.

The idea of the annual report comes from the NANPA phone number
allocation system which requires recipients of an NPA block 
of 10,000 numbers to provide annual public reports detailing
how many numbers are assigned, unallocated, and in limbo waiting
for a certain number of months before being assigned to another
subscriber.

--Michael Dillon



From bill at herrin.us  Wed Oct 13 10:30:55 2010
From: bill at herrin.us (William Herrin)
Date: Wed, 13 Oct 2010 10:30:55 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E74B0@PLSWM12A.ad.sprint.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47021D8C8E@ex01.drtel.lan>
	<10093.1286906540@marajade.sandelman.ca>
	<4CB4AEEC.6020701@ipinc.net> <20732.1286911333@marajade.sandelman.ca>
	<AANLkTimduTRGc1uYBgZ6UcfzaX6f2xftn10Z7nh7YOYn@mail.gmail.com>
	<4CB4BB26.60606@ipinc.net>
	<AANLkTi=4m9f7zPaNKtzC5-Ga92w6uRU3udCMLLPn=wmJ@mail.gmail.com>
	<54E900DC635DAB4DB7A6D799B3C4CD8E74B0@PLSWM12A.ad.sprint.com>
Message-ID: <AANLkTin71iyd_MEnbud_g-Xp8CspNO4EHTK46LXqPoab@mail.gmail.com>

On Wed, Oct 13, 2010 at 9:39 AM, George, Wes E IV [NTK]
<Wesley.E.George at sprint.com> wrote:
>>I claim that anyone actually announcing routes with a registry AS
>>number has demonstrated a defacto need for registry IPv6 addresses.
>
> [WES] No, having a registry AS# and announcing
> routes != having an allocation from $registry. It simply
> means that they are multihomed. There are plenty of networks
> who get PD IPv4 from one or more upstreams and announce
> it to all of them via BGP.
> I acknowledge that multihoming with PD space in
> IPv6 is not necessarily attractive due to risks of your
> subnet announcements being filtered on some networks,

It's not really a question of attractiveness Wes, it's a question of:
"does it work?" From what Jason Schiller was telling me, it appears
that about 50% of IPv6 ISPs filter /48 customer cutouts from
ISP-allocated space. If his estimate is correct then the answer is:
No, multihoming using one of your ISPs' space _does not work_ in IPv6.

What does work, now that Verizon is on board and accepting /48
announcements, is a registry IPv6 assignment. So if you're multihomed
and announcing IPv4 prefixes, it's little short of a certainty than
when you deploy IPv6 you will be multihomed and announcing and
announcing a registry-assigned IPv6 prefix.


> but it's not impossible, nor is that germane to the discussion.

Respectfully, "does it actually work" is germane to -every- policy discussion.


> I simply don't see the point at which this helps spur deployment.

Does the quarterback refuse to throw the ball because no receiver is
in a position to make a touchdown? Of course not. Let's get the
allocations and assignments we know are needed in to the network
engineers' hands. Unless we're ready to punt to the v4 CGN team, we
need to move the v6 ball down field.

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  Wed Oct 13 10:43:37 2010
From: bill at herrin.us (William Herrin)
Date: Wed, 13 Oct 2010 10:43:37 -0400
Subject: [arin-ppml] Controlling the IPv6 address consumption rate
In-Reply-To: <2B6D8499-377A-40FF-8263-79C6A3BFD3AE@delong.com>
References: <AANLkTik+5zsTzepnf40faZVgOxNF2OOeMt-3o4p2wLEw@mail.gmail.com>
	<2B6D8499-377A-40FF-8263-79C6A3BFD3AE@delong.com>
Message-ID: <AANLkTikQqyg8508hSUbxM5gMp=_BSuf41jaRByztaGuh@mail.gmail.com>

On Sun, Oct 10, 2010 at 12:08 PM, Owen DeLong <owen at delong.com> wrote:
> On Oct 10, 2010, at 7:09 AM, William Herrin wrote:
>> 7 billion people in the world, each of which consumes Internet
>> service, so as a lower bound we'll need 9 bits worth of 20M-equivalent
>> ISPs to serve them.
>
> 4,200,000,000 / 20,000,000 = 210 = 8 bits worth of 20M-equivalent
> ISPs. However, it won't actually work out that way. The vast majority
> of ISPs will be much smaller and there will be many more of them.

Okay. 8 bits, 9 bits. The key result from all the math is this:

Between an austere deployment of IPv6 (/60 end users, cramped routing,
etc) and a deployment of IPv6 that will consume the entire address
space prior to the retirement of IPv4, we have roughly 22 bits, not
the 96 bits that one might naively expect with an expansion from 32 to
128 bits.

Responsible management demands that we treat some portion of that 22
bits as a consumption suppressor so that we don't quickly run out of
IPv6 addresses. Whatever is left over, be it 4 bits, 20, or anything
in between, that's the number of bits we can actually afford to use
for nice-to-haves, like a larger standard end-user assignment than /60
(/56 or /48), sparse assignment and so on.


>>: how should we divvy up the 22 bits
>> between IPv4's consumption rate and IPv6's minimum needful consumption
>> rate? How many bits of convenience and how many bits of responsibly
>> slow consumption?
>>
> _IF_ I understand what you mean by these terms correctly, then, yes,
> I think an 8/14 ratio isn't such a bad ratio

It sounds to me like you do understand what I mean.

8 bits of conservation worries me. We badly underestimated at the
start of IPv4. I'd be more comfortable starting with a more
conservative number (like 12 or 16) and then working down to 8 bits of
conservation after we gain a decade or two of experience.

On the other hand, if the current address consumption rate holds at
what eyeballs to me vaguely like 0.6(n^2), 8 bits of conservation
should buy us around 115 years. If Geoff is lurking, I'm sure he can
provide better information assuming completion of the IPv6 transition
with IPv6 consumption at 1/256th of IPv4's current consumption and the
same consumption growth rate exhibited over the last 15 years in IPv4.

Anyway, let's run with 8 bits and see what it implies.

8 bits means that the maximum allocation we can allow a single
organization to seek both initially and due to prior consumption is
/20. The largest holding we can allow an affiliated set of
organizations (including merged and acquired ISPs) totals /16. The
4-bit difference comes from that hold-against-development set I talked
about. Larger allocations than this, regardless of cause, are likely
to see us deplete the IPv6 free pool faster than the 8-bits
conservation target we've set.

8 bits also means you have only 14 bits left for the nice-to-haves. If
you spend 12 of those bits bringing the downstream end-user assignment
from the austere /60 to your preferred /48, you'll have only 2 bits
left. That doesn't give you much flexibility with your routing. Are
you sure you wouldn't rather put 4 of your bits to bring the
assignment up to /56 and use the remaining 10 to do smarter things
with your routing hierarchies? 256 LANs is a lot of LANs for all but
the largest customers.

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 cgrundemann at gmail.com  Wed Oct 13 10:45:31 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 13 Oct 2010 08:45:31 -0600
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated Transfer
	Policy
In-Reply-To: <20101013134243.GA81926@ussenterprise.ufp.org>
References: <4CB34773.2070308@arin.net>
	<20101013134243.GA81926@ussenterprise.ufp.org>
Message-ID: <AANLkTinw4e2BmJxpq962jvenXtHgKQ5MsjkYy=yAE4Vj@mail.gmail.com>

On Wed, Oct 13, 2010 at 07:42, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Mon, Oct 11, 2010 at 01:20:51PM -0400, ARIN wrote:
>> Policy statement: Any RIR's member may transfer IPv4 addresses to the
>> member of another RIR as long as the two RIRs agree and exercise
>> Internet stewardship and the values expressed in RFC2050.
>
> I applaud the attempt at super-simple policy. ?It is refreshing.
>
> That said, I wish to play a sort of devils advocate for a moment.
>
> There are activities one RIR's community thinks are "bad", but that
> other RIR's communities seem to think are "good". ?To some extent
> that is why we have separate RIR's, but there is also a desire to
> limit the badness globally. ?I believe the references to RFC2050
> are an attempt to restate such a global limit.
>
> Unfortunately RFC2050 is already long in the tooth, and with the
> impending IPv4 exhaustion will become less relevant very quickly.
> In particular, I think if you look at a post run-out world, it is
> likely different people will come to the same conclusion about the
> text in various areas.

Thanks for the excellent feedback Leo. I do want to point out that
when crafting this ultra-simple policy statement, we chose our words
very carefully: Internet stewardship *and* the _values_ expressed in
RFC2050 is meant to convey the spirit by which the RIRs should
interact ("do the right thing") without binding them explicitly to any
particular (possibly outdated) text.

~Chris


> To that end, I'm actually not sure what the effect of this policy
> would be down the road, and being unable to evaluate that effect I
> find I cannot support it.
>
> If you don't care about the details, stop reading now, if you do,
> continue.
>
> Let's fast forward 2-3 years from now to a world where IANA and all 5
> RIR's are "out" for all practical purposes, and look at some of the
> statements in RFC 2050 from that context.
>
> Right from the start, there is something quite interesting:
>
> ? By approving this document as a Best Current Practice,the IESG
> ? asserts its belief that this policy described herein is an accurate
> ? representation of the current practice of the IP address registries
> ? with respect to address assignment. ?This does not constitute
> ? endorsement or recommendation of this policy by the IESG. The IESG
> ? will reevaluate its approval of this document in December 1997 taking
> ? into consideration the results of the discussions that will be take
> ? place in the IRE Working Group between now and then.
>
> The document is not a standards track RFC, it is a documentation of the
> Best Current Practice /in 1996/. ?Indeed, I actually think it's well
> overdue to be updated to current practice, but that's another discussion
> for another day.
>
> ?1) Conservation: Fair distribution of globally unique Internet address
> ? ? space according to the operational needs of the end-users and Internet
> ? ? Service Providers operating networks using this address space.
> ? ? Prevention of stockpiling in order to maximize the lifetime of the
> ? ? Internet address space.
>
> "Fair distribution" is a very simple thing when there are plenty of
> addresses, we can use the Chinese buffet model (take all you want, eat
> all you take). ?When there is no more space, and we're looking at a
> transfer market (paid or otherwise) it takes on an entirely different
> color. ?Do we have to ensure everyone gets some, regardless of ability
> to pay? ?Is distribution based on who has the most money fair? ?Does
> fairness require the RIR's to more aggressively revoke space from those
> who are not using it to fairly distribute to those who need it? ?The
> last sentence about stockpiling would seem to indicate that is
> important.
>
> ? ? ?(Under the end user "Assignment Framework" section)
>
> ? ? ?c) ?the organization's actual requirement for IP space is
> ? ? ? ? ?very large, for example, the network prefix required to
> ? ? ? ? ?cover the request is of length /18 or shorter.
>
> All of the RIR's have changed their policy to allow longer than /18
> prefixes to end users, and I think off the top of my head many now allow
> longer prefixes to end users than ISP's. ?As we get closer to
> exhaustion, prefix length will get smaller.
>
> ? Organizations will be assigned address space based on immediate
> ? utilization plus 1 year projected utilization. ?A prefix longer than
> ? /24 may be issued if deemed appropriate. ?Organizations with less
> ? than 128 hosts will not be issued an IP address directly from the
> ? IRs. ?Organizations may be issued a prefix longer than /24 if the
> ? organization can provide documentation from a registry recognized ISP
> ? indicating the ISP will accept the long prefix for injection into the
> ? global routing system.
>
> I believe there are already web-hosters who have less than "128
> hosts", but have received space because they host hundreds of web
> sites, each of which might need an IP address.
>
> I'm not pointing these out to argue about any of them individually,
> but simply to point out the document, like any, becomes less relevant
> over time. ?This makes sense, as it is a best current practice, and
> not the hard and fast requirements many seem to want to make it.
>
> We're now in a post run out world, and want to assess "need". ?There
> will be thousands of folks who can demonstrate technical need the
> way we have always done it, but we can't service them all. ?So a
> new criteria needs to be added into the mix. ?All of the RIR's seem
> to be moving to money via some mechanism for paid transfers.
> Economists and capitalists would love this, since clearly those
> with the greatest need for a resource are the ones willing to pay
> the most money.
>
> It is easy to see an argument being made as this backlog of need
> increases that much of (but not all) our current work to verify
> need is unnecessary. ?Why spend hours verifying an organization
> "needs" a /16 and checking all of their engineering plans when all
> they can buy in the market place is a /24? ?And if they are willing
> to pay $50,000 for that /24, isn't that a better indicator of how
> much they need it than any engineering plan?
>
> I'm not sure an RIR could argue a pure dollar based method passes
> the smell test, for instance 2050 does suggest "Prevention of
> stockpiling in order to maximize the lifetime of the Internet address
> space.", so perhaps they have to insure someone isn't just buying
> it up to stockpile. ?However in such a scheme it would be easy to
> say your engineering plans do not need to be reviewed unless you
> have paid for more than a /20, because if you have very small amounts
> of space its rather hard to call it stockpiling.
>
> In short, I fear the best practice that is 2050 is far shaker ground
> going forward than many realize. ?It won't ever be tested in a
> court, but it will be continuously tested in the court of public
> opinion. ?It is though a snapshot in time of a continuously evolving
> process where we have already seen fit to change its guidance. ?I
> can easily see a future where four of the five RIR's decide a practice
> is the best current practice in the future, but one of the four is
> a hold out for whatever reason. ?To the extent this is a global policy,
> IANA would likely side with the four, noting the represent community
> consensus.
>
> While IPv4 is getting all the attention at the current time, IPv6
> is, as usual, the more interesting topic. ?I urge you to consider
> a world 20 years from now, where IPv4 has been removed from all of
> the large Internet backbones and we're operating in a primarily
> IPv6 only world. ?Now re-read 2050. ?Does it make sense? ?How much
> of it matches the best current practice in this future world?
>
> --
> ? ? ? Leo Bicknell - bicknell at ufp.org - CCIE 3440
> ? ? ? ?PGP keys at http://www.ufp.org/~bicknell/
>
> _______________________________________________
> 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  Wed Oct 13 10:54:57 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 13 Oct 2010 15:54:57 +0100
Subject: [arin-ppml] Controlling the IPv6 address consumption rate
In-Reply-To: <AANLkTikQqyg8508hSUbxM5gMp=_BSuf41jaRByztaGuh@mail.gmail.com>
References: <AANLkTik+5zsTzepnf40faZVgOxNF2OOeMt-3o4p2wLEw@mail.gmail.com>
	<2B6D8499-377A-40FF-8263-79C6A3BFD3AE@delong.com>
	<AANLkTikQqyg8508hSUbxM5gMp=_BSuf41jaRByztaGuh@mail.gmail.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B4239378EABD9@EMV01-UKBR.domain1.systemhost.net>

> Responsible management demands that we treat some portion of that 22
> bits as a consumption suppressor so that we don't quickly run out of
> IPv6 addresses. Whatever is left over, be it 4 bits, 20, or anything
> in between, that's the number of bits we can actually afford to use
> for nice-to-haves, like a larger standard end-user assignment than /60
> (/56 or /48), sparse assignment and so on.

Whoaaa there!!!
The IETF defined standard end user assignment is /48.
That is not a nice-to-have, that is the standard. ARIN policy, and every
other RIR policy accepts end user assignments of /48 as standard. 

It is the /56 prefix that is non-standard and this appeared in policy
because cable companies have to address every house that they pass,
not just the ones that they connect. The /56 was introduced as an
OPTIONAL standard assignment for residential users.

Of course people can shoot themselves in the foot with even longer
prefixed is they want to, but that should not be part of this kind of
analysis.

Quite frankly, after seeing your statement above, I didn't read the
rest of your analysis nor did I even bother to check whether your
analysis is meaningful in any way.

--Michael Dillon



From bill at herrin.us  Wed Oct 13 11:16:53 2010
From: bill at herrin.us (William Herrin)
Date: Wed, 13 Oct 2010 11:16:53 -0400
Subject: [arin-ppml] Controlling the IPv6 address consumption rate
In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B4239378EABD9@EMV01-UKBR.domain1.systemhost.net>
References: <AANLkTik+5zsTzepnf40faZVgOxNF2OOeMt-3o4p2wLEw@mail.gmail.com>
	<2B6D8499-377A-40FF-8263-79C6A3BFD3AE@delong.com>
	<AANLkTikQqyg8508hSUbxM5gMp=_BSuf41jaRByztaGuh@mail.gmail.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B4239378EABD9@EMV01-UKBR.domain1.systemhost.net>
Message-ID: <AANLkTinCOsaG-c9Yp3GA-FXbO3TOFE418ZpXrB4TXdvt@mail.gmail.com>

On Wed, Oct 13, 2010 at 10:54 AM,  <michael.dillon at bt.com> wrote:
>> Responsible management demands that we treat some portion of that 22
>> bits as a consumption suppressor so that we don't quickly run out of
>> IPv6 addresses. Whatever is left over, be it 4 bits, 20, or anything
>> in between, that's the number of bits we can actually afford to use
>> for nice-to-haves, like a larger standard end-user assignment than /60
>> (/56 or /48), sparse assignment and so on.
>
> Whoaaa there!!!
> The IETF defined standard end user assignment is /48.
> That is not a nice-to-have, that is the standard. ARIN policy, and every
> other RIR policy accepts end user assignments of /48 as standard.

Michael,

At the same time (maybe even in the same RFC), the IETF decided that
end users would not multihome using BGP with multiple ISPs under IPv6.
That too is the official standard.

We always listen to what the folks in the IETF have to say, but
sometimes they don't know what the eff they're talking about.


> Quite frankly, after seeing your statement above, I didn't read the
> rest of your analysis nor did I even bother to check whether your
> analysis is meaningful in any way.

Your loss. If you'd bothered, you would have discovered that we don't
actually have enough bits in the v6 address to do everything important
in the quantity we're told we should be doing it. Like it or not,
we'll have to pick and choose.

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 michael.dillon at bt.com  Wed Oct 13 11:46:09 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 13 Oct 2010 16:46:09 +0100
Subject: [arin-ppml] Controlling the IPv6 address consumption rate
In-Reply-To: <AANLkTinCOsaG-c9Yp3GA-FXbO3TOFE418ZpXrB4TXdvt@mail.gmail.com>
References: <AANLkTik+5zsTzepnf40faZVgOxNF2OOeMt-3o4p2wLEw@mail.gmail.com>
	<2B6D8499-377A-40FF-8263-79C6A3BFD3AE@delong.com>
	<AANLkTikQqyg8508hSUbxM5gMp=_BSuf41jaRByztaGuh@mail.gmail.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B4239378EABD9@EMV01-UKBR.domain1.systemhost.net>
	<AANLkTinCOsaG-c9Yp3GA-FXbO3TOFE418ZpXrB4TXdvt@mail.gmail.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B4239378EAC5D@EMV01-UKBR.domain1.systemhost.net>


> At the same time (maybe even in the same RFC), the IETF decided that
> end users would not multihome using BGP with multiple ISPs under IPv6.
> That too is the official standard.

I call BS on this one. If you say "maybe even in the same RFC" then you
clearly don't know where this statement is or exactly what was written
or in what context. In fact if it is not in the same RFC then it is clearly
not "at the same time". 

If it is your misinformed opinion, then please say so instead of pretending
to quote from the IETF bible.

> Your loss. If you'd bothered, you would have discovered that we don't
> actually have enough bits in the v6 address to do everything important
> in the quantity we're told we should be doing it. Like it or not,
> we'll have to pick and choose.

The fact is that I believe your analysis is flawed and is based on false premises
and probably riddled with other problems. I think that you simply misunderstand
the issues and have jumped to too many conclusions without detailed analysis
and fact checking.

You can hold whatever opinions you want, but ARIN is under no obligation to
act on any of them.

--Michael Dillon



From owen at delong.com  Wed Oct 13 11:58:20 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 13 Oct 2010 08:58:20 -0700
Subject: [arin-ppml] Controlling the IPv6 address consumption rate
In-Reply-To: <AANLkTikQqyg8508hSUbxM5gMp=_BSuf41jaRByztaGuh@mail.gmail.com>
References: <AANLkTik+5zsTzepnf40faZVgOxNF2OOeMt-3o4p2wLEw@mail.gmail.com>
	<2B6D8499-377A-40FF-8263-79C6A3BFD3AE@delong.com>
	<AANLkTikQqyg8508hSUbxM5gMp=_BSuf41jaRByztaGuh@mail.gmail.com>
Message-ID: <7B65164A-EC15-44EF-809E-90DAE80FC100@delong.com>


On Oct 13, 2010, at 7:43 AM, William Herrin wrote:

> On Sun, Oct 10, 2010 at 12:08 PM, Owen DeLong <owen at delong.com> wrote:
>> On Oct 10, 2010, at 7:09 AM, William Herrin wrote:
>>> 7 billion people in the world, each of which consumes Internet
>>> service, so as a lower bound we'll need 9 bits worth of 20M-equivalent
>>> ISPs to serve them.
>> 
>> 4,200,000,000 / 20,000,000 = 210 = 8 bits worth of 20M-equivalent
>> ISPs. However, it won't actually work out that way. The vast majority
>> of ISPs will be much smaller and there will be many more of them.
> 
> Okay. 8 bits, 9 bits. The key result from all the math is this:
> 
> Between an austere deployment of IPv6 (/60 end users, cramped routing,
> etc) and a deployment of IPv6 that will consume the entire address
> space prior to the retirement of IPv4, we have roughly 22 bits, not
> the 96 bits that one might naively expect with an expansion from 32 to
> 128 bits.
> 
Somewhere between 32 and 40 by my count, but, anyway...

> Responsible management demands that we treat some portion of that 22
> bits as a consumption suppressor so that we don't quickly run out of
> IPv6 addresses. Whatever is left over, be it 4 bits, 20, or anything
> in between, that's the number of bits we can actually afford to use
> for nice-to-haves, like a larger standard end-user assignment than /60
> (/56 or /48), sparse assignment and so on.
> 
Hence the /3 and the reservation of 7/8ths of the address space.
The IETF already put the consumption suppressor stake in the ground there.
I see no reason to move it.

> 
>>> : how should we divvy up the 22 bits
>>> between IPv4's consumption rate and IPv6's minimum needful consumption
>>> rate? How many bits of convenience and how many bits of responsibly
>>> slow consumption?
>>> 
>> _IF_ I understand what you mean by these terms correctly, then, yes,
>> I think an 8/14 ratio isn't such a bad ratio
> 
> It sounds to me like you do understand what I mean.
> 
> 8 bits of conservation worries me. We badly underestimated at the
> start of IPv4. I'd be more comfortable starting with a more
> conservative number (like 12 or 16) and then working down to 8 bits of
> conservation after we gain a decade or two of experience.
> 
Yeah, I think that's pretty absurd.  Conserving 255/256ths of the address
space is somewhat absurd to begin with, but, hey, why not... Plenty of
room in the 1/256th we're talking about, so, OK... Let's try that.

Conserving 4095/4096ths of the address space, well, that's getting
ridiculous on its face. Especially in light of the need for ridiculous
wastes of IPv6 like 6rd in order to get IPv6 deployed because the
vendors of last mile technology managed to get caught with their
pants down by an event that they had more than a decade of warning
was coming.

I agree it's tragic and wasteful. However, I think it is better to deploy
with 6rd than to fail to deploy and end up with LSN more widely
deployed.

> On the other hand, if the current address consumption rate holds at
> what eyeballs to me vaguely like 0.6(n^2), 8 bits of conservation
> should buy us around 115 years. If Geoff is lurking, I'm sure he can
> provide better information assuming completion of the IPv6 transition
> with IPv6 consumption at 1/256th of IPv4's current consumption and the
> same consumption growth rate exhibited over the last 15 years in IPv4.
> 
A very good argument for 8 bits or less...

> Anyway, let's run with 8 bits and see what it implies.
> 
> 8 bits means that the maximum allocation we can allow a single
> organization to seek both initially and due to prior consumption is
> /20. The largest holding we can allow an affiliated set of
> organizations (including merged and acquired ISPs) totals /16. The
> 4-bit difference comes from that hold-against-development set I talked
> about. Larger allocations than this, regardless of cause, are likely
> to see us deplete the IPv6 free pool faster than the 8-bits
> conservation target we've set.
> 
OK.

> 8 bits also means you have only 14 bits left for the nice-to-haves. If
> you spend 12 of those bits bringing the downstream end-user assignment
> from the austere /60 to your preferred /48, you'll have only 2 bits
> left. That doesn't give you much flexibility with your routing. Are
> you sure you wouldn't rather put 4 of your bits to bring the
> assignment up to /56 and use the remaining 10 to do smarter things
> with your routing hierarchies? 256 LANs is a lot of LANs for all but
> the largest customers.
> 
And here's where you run off the rails again by miscounting the bits.

Let's look at the reality...

Tiny ISPs with fewer than 30,000 end sites served fit fine in a /32.
Probably about 15% of total ISPs.
Small to medium ISPs with between 30,000 and 500,000  end
sites served warrant a /28. Probably about 50% of total ISPs.
Large ISPs with between 500,000 and 12,000,000 end
sites served (probably about 30% or more of total ISPs) warrant a /28.
Extraordinarily large ISPs with more more than 12,000,000 end
sites served would get a /20 or in extreme cases, maybe a /16.
I'll divide these up as 4% get a /20 and 1% a /16 for purposes
of discussion. I suspect the real numbers are more like 4.99% and
0.01%.

Assuming for the moment that there are roughly 30,000 ISPs
on the planet, those percentages work out as follows:
Quan	Pfx		/32 equiv.
4,500	/32		4,500
15,000	/28		240,000
9,000	/24		2,304,000
1,200	/20		36,864,000
300		/16		19,660,000

Total			59,072,500 /32s

This would mean that we consume a total of 3.5 /16s to
number the entire existing internet according to my
suggested way of numbering things.

I'm willing to set aside a few other /16s for 6rd to be deployed
temporarily (~5-10 years, hopefully), so long as they are done
in such a way that a community decision to deprecate them and
reclaim them is enforceable. (specific prefixes which can be
filtered without harming native deployments).

Since we've already given each RIR a /12 to start off with and
we still have 506 /12s left in the /3 from which we are
allocating, I think we're OK.

Owen
> 

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

From jmaimon at chl.com  Wed Oct 13 12:34:50 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Wed, 13 Oct 2010 12:34:50 -0400
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated Transfer
 Policy
In-Reply-To: <4CB34773.2070308@arin.net>
References: <4CB34773.2070308@arin.net>
Message-ID: <4CB5DFAA.1000104@chl.com>



ARIN wrote:

>
> Policy statement: Any RIR's member may transfer IPv4 addresses to the
> member of another RIR as long as the two RIRs agree and exercise
> Internet stewardship and the values expressed in RFC2050.
>
> Rationale: Since individual RIRs now allow transfers, it makes sense to
> be able to transfer between regions as well.
>
> Timetable for implementation: upon ratification of all five RIRs
>
> Timetable for de-implementation: upon change to this policy text in any RIR
>
>

I support the policy, but I believe it could use some bolt tightening.

I too would like to see more explicitly that transfers between members 
of different RiR's are to be made only pursuant to the policies of both 
origin and destination registry.

I believe that is the intent of the current language.

Stewardship and RFC reference I am neutral on. Isnt all policy already 
predicated on those terms?

The effect of this policy as opposed to one that mandates registries to 
accept transfers is that it punts the issue straight to each registry, 
allowing it to ignore the issue or take it on as it chooses to.

I wonder what the current status is. Is there anything that explicitly 
prevents registries from behaving in this fashion currently? Or is it 
simple inference and current practice not to do so?

Is there any differentiation to be made either under this policy or 
without it for legacy space?

A registry that does attempt to enable inter-registry transfer according 
to this global policy will probably find the task to be somewhat complex 
and tedious and requiring significant cooperation and coordination 
between the registries to determine process and compatibility.

Joe





From Wesley.E.George at sprint.com  Wed Oct 13 12:35:24 2010
From: Wesley.E.George at sprint.com (George, Wes E IV [NTK])
Date: Wed, 13 Oct 2010 16:35:24 +0000
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTin71iyd_MEnbud_g-Xp8CspNO4EHTK46LXqPoab@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47021D8C8E@ex01.drtel.lan>
	<10093.1286906540@marajade.sandelman.ca> <4CB4AEEC.6020701@ipinc.net>
	<20732.1286911333@marajade.sandelman.ca>
	<AANLkTimduTRGc1uYBgZ6UcfzaX6f2xftn10Z7nh7YOYn@mail.gmail.com>
	<4CB4BB26.60606@ipinc.net>
	<AANLkTi=4m9f7zPaNKtzC5-Ga92w6uRU3udCMLLPn=wmJ@mail.gmail.com>
	<54E900DC635DAB4DB7A6D799B3C4CD8E74B0@PLSWM12A.ad.sprint.com>
	<AANLkTin71iyd_MEnbud_g-Xp8CspNO4EHTK46LXqPoab@mail.gmail.com>
Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E7717@PLSWM12A.ad.sprint.com>

> -----Original Message-----
> From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William
> Herrin
> Sent: Wednesday, October 13, 2010 10:31 AM
> To: George, Wes E IV [NTK]
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Preemptive IPv6 assignment

> Respectfully, "does it actually work" is germane to -every- policy
> discussion.

[WES] Never said otherwise. Matter of fact, I think that's exactly what I'm saying, Bill. Does preemptively assigning every ASN in the table an IPv6 address actually work (by itself) in getting them to deploy? You say "maybe/yes so let's do it just in case" I say no, at least partially because I'm not in support of policy for policy's sake, and we've reached an impasse.

My point in saying that it wasn't germane to the discussion was that I didn't want to turn this into a PI vs PD debate, because I realize that would be oversimplifying things, that's all. I only brought it up as a possible method to address the problem which was raised, which was fees, not allocation justification or paperwork.
>
> > I simply don't see the point at which this helps spur deployment.
>
> Does the quarterback refuse to throw the ball because no receiver is
> in a position to make a touchdown? Of course not. Let's get the
> allocations and assignments we know are needed in to the network
> engineers' hands. Unless we're ready to punt to the v4 CGN team, we
> need to move the v6 ball down field.
[WES] I have this overwhelming urge to start chanting "RU-DY! RU-DY!" ;-)
Seriously, regardless of what metaphor you use, we're not actively doing something to prevent people from getting IPv6 allocations if they can justify them (except possibly for 6rd). CGN is going to happen for a lot of other reasons, few of which have to do with whether people can get IPv6 allocations. Yes, more IPv6 hopefully means less IPv4 NAT, but the fundamental disagreement you are having with me and several others on this list is whether allocations (or lack thereof) are actually serving as a barrier to deployment or not. I *wish* that was actually what is holding the majority of people back from deploying IPv6 or pushing them to use CGN.

Wes George

________________________________

This e-mail may contain Sprint Nextel 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 mark at townsley.net  Wed Oct 13 12:38:14 2010
From: mark at townsley.net (Mark Townsley)
Date: Wed, 13 Oct 2010 18:38:14 +0200
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
Message-ID: <4CB5E076.7000701@townsley.net>

 On 10/13/10 4:00 PM, Owen DeLong wrote:
>
> Regardless of the IPv4 address assignment method, 	the most common
> and most likely 6rd deployment mechanisms are incredibly wasteful
> of IPv6 address space. Further, limiting end customers to /56 is
> also a suboptimal IPv6 deployment.
If you don't like /56, wait until you have tasted /64. That is what is
coming to North America if ISPs in the ARIN region are forced to deploy
within a /32 here. Make no mistake, the Residential Gateway vendors will
figure out how to operate within this restriction, they have over a
decade of experience faking things out for you with IPv4 -- it just will
end up being more brittle and more expensive for the end-user.
> Unfortunately, the current state of last-mile technologies being the
> abysmal mess that it is, we basically have not choice other than
> providing for 6rd as an immediate deployment mechanism. As
> such, it should be done with the following safeguards:
>
> +	Allocations from a specific prefix to facilitate a community decision
> 	to deprecate the technology when it is no longer necessary.
On one hand, you accept that some ISPs are stuck and need 6rd to deploy
IPv6 now, but on the other hand you are saying that the community (i.e.,
the ISP's competitors) have the power to rip their IPv6 deployment out
from under them at any time. I know you want to be sure that 6rd goes
away, but this is still throwing the baby out with the bathwater.

> +	Native deployments should not be shared among the same
> 	IPv6 prefix.
Be careful of unintended consequences here. This kind of directive, if
followed, could actually _discourage_ a smooth transition from 6rd to
native, as well as wasting perfectly usable IPv6 space within the 6rd
block based on hope of future reclamation by ARIN.
> +	We should make strong efforts to communicate and preserve
> 	the notion that this is a transitional and therefore temporary
> 	solution. That last mile technologies must catch up and
> 	provide reasonable and workable native IPv6 solutions.
If ARIN really wanted to take a step forward towards helping the quality
of IPv6 deployment on the Internet via deprecation of IPv6 space, it
would start efforts to see 2002::/16 deprecated. First things first.

- Mark

> 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 jmaimon at chl.com  Wed Oct 13 12:41:38 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Wed, 13 Oct 2010 12:41:38 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
Message-ID: <4CB5E142.9060102@chl.com>



Mark Andrews wrote:
>
> There is a increadable amount of bad information being spouted here.
>
> To deploy 6rd in parallel with a native deployment you roughly need
> double the IPv6 address space of a straight native deployment.

> Mark

Thanks for the clarification that it is possible to deploy 6rd space 
prudently. If I understand you correctly, at a minimum, you need a 
enough bits to differentiate between all relevant IPv4 pools + the 
number of bits in the largest of these pools.

However, draft policy does seem to leave the door open to much more 
wasteful consumption.

Would we all be comfortable with the suggestion that any policy enabling 
allocations for 6rd transition space have as an upper bound  double the 
address space of a straight native deployment?

And if a specific prefix were to be set aside for this, how large would 
it need to be in order to enable all who would likely need or want to 
deploy resources under this policy to do so?

Joe


From bicknell at ufp.org  Wed Oct 13 12:53:19 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 13 Oct 2010 09:53:19 -0700
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated Transfer
	Policy
In-Reply-To: <AANLkTinw4e2BmJxpq962jvenXtHgKQ5MsjkYy=yAE4Vj@mail.gmail.com>
References: <4CB34773.2070308@arin.net>
	<20101013134243.GA81926@ussenterprise.ufp.org>
	<AANLkTinw4e2BmJxpq962jvenXtHgKQ5MsjkYy=yAE4Vj@mail.gmail.com>
Message-ID: <20101013165319.GA3056@ussenterprise.ufp.org>

In a message written on Wed, Oct 13, 2010 at 08:45:31AM -0600, Chris Grundemann wrote:
> Thanks for the excellent feedback Leo. I do want to point out that
> when crafting this ultra-simple policy statement, we chose our words
> very carefully: Internet stewardship *and* the _values_ expressed in
> RFC2050 is meant to convey the spirit by which the RIRs should
> interact ("do the right thing") without binding them explicitly to any
> particular (possibly outdated) text.

For the record, I am ok with:

Policy statement: Any RIR's member may transfer IPv4 addresses to the
                  member of another RIR as long as the two RIRs agree.

Your second sentence should be redundant, as the RIR's were formed
under 2050, and should persue stweardship moving forward as a result.
Including it though I think provides the impression of some limitations
that are at best vague, and likely non-existant.

I used to be worried about a rich company buying up IPv4 space to
keep it from their competitors.  As time as passed, I no longer
worry about that much.

If the price is high, the price may be a far better representation
of "need" than any of our current engineering based metrics.  I do
not want to rule out the possibility that in one or more RIR regions
giving space to the highest bidder may well be needs based good
stweardship.

Since both RIR's have to agree, if ARIN doesn't share this vision
they need not participate in such a process, but if say, LACNIC and
AFRINIC both share that vision I see no reason to stand in their
way at the IANA level.

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

From jmaimon at chl.com  Wed Oct 13 12:54:13 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Wed, 13 Oct 2010 12:54:13 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
Message-ID: <4CB5E435.1090408@chl.com>



Owen DeLong wrote:
>
> On Oct 12, 2010, at 8:55 PM, Mark Andrews wrote:

> Unfortunately, the current state of last-mile technologies being the
> abysmal mess that it is, we basically have not choice other than
> providing for 6rd as an immediate deployment mechanism. As
> such, it should be done with the following safeguards:
>
> +	Allocations from a specific prefix to facilitate a community decision
> 	to deprecate the technology when it is no longer necessary.
>
> +	Native deployments should not be shared among the same
> 	IPv6 prefix.
>
> +	We should make strong efforts to communicate and preserve
> 	the notion that this is a transitional and therefore temporary
> 	solution. That last mile technologies must catch up and
> 	provide reasonable and workable native IPv6 solutions.
>
> Owen

If the concern is spurring transition efforts, how about including as a 
requirement deployment and operation of properly functional 6to4 relays, 
possibly even teredo.

Heck, toss in lisp while we are at it.

The idea is that if you want community support for your transition 
efforts, in return provide support to the other efforts, even those you 
may not be particularly interested in.

Joe


From bicknell at ufp.org  Wed Oct 13 12:59:59 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 13 Oct 2010 09:59:59 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CB5E076.7000701@townsley.net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
Message-ID: <20101013165959.GB3056@ussenterprise.ufp.org>

In a message written on Wed, Oct 13, 2010 at 06:38:14PM +0200, Mark Townsley wrote:
> If you don't like /56, wait until you have tasted /64. That is what is

I would be fine with requiring 6rd to provide a /64, while keeping
the standard that native connections get a /48.  This provides
incentive to the end user to pressure their ISP to move from 6rd
to native, and/or to switch providers to one with native connectivity.

Given the realities of 6rd needing 32 bits to map IPv4 into this
doesn't seem like such a bad thing.

> On one hand, you accept that some ISPs are stuck and need 6rd to deploy
> IPv6 now, but on the other hand you are saying that the community (i.e.,
> the ISP's competitors) have the power to rip their IPv6 deployment out
> from under them at any time. I know you want to be sure that 6rd goes
> away, but this is still throwing the baby out with the bathwater.

I too want to be sure the community can make 6rd go away, because
it is amazing waste of bits, and mapping all the old trash into 6rd
space.  Still, you make a valid point, no one should want to deploy
something that could be ripped out from under them at any time.

I would support making all 6rd prefixes have a minimum lifetime,
perhaps 7-10 years (which should cover even the longest equipment
refresh cycles), after which the community can pull support at any
time.  That way 6rd users have a guaranteed minimum, it can easily
be extended (by the community doing nothing and letting them keep
going), and the community can still pull the plug on this waste.

"ARIN will demand the return of all 6rd prefixes when the prefix is no
longer in use for 6rd services, or when the community decides that 6rd
is no longer a benefit to the community.  This cannot occur before
January 1st, 2020."

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

From bill at herrin.us  Wed Oct 13 14:01:04 2010
From: bill at herrin.us (William Herrin)
Date: Wed, 13 Oct 2010 14:01:04 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E7717@PLSWM12A.ad.sprint.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47021D8C8E@ex01.drtel.lan>
	<10093.1286906540@marajade.sandelman.ca>
	<4CB4AEEC.6020701@ipinc.net> <20732.1286911333@marajade.sandelman.ca>
	<AANLkTimduTRGc1uYBgZ6UcfzaX6f2xftn10Z7nh7YOYn@mail.gmail.com>
	<4CB4BB26.60606@ipinc.net>
	<AANLkTi=4m9f7zPaNKtzC5-Ga92w6uRU3udCMLLPn=wmJ@mail.gmail.com>
	<54E900DC635DAB4DB7A6D799B3C4CD8E74B0@PLSWM12A.ad.sprint.com>
	<AANLkTin71iyd_MEnbud_g-Xp8CspNO4EHTK46LXqPoab@mail.gmail.com>
	<54E900DC635DAB4DB7A6D799B3C4CD8E7717@PLSWM12A.ad.sprint.com>
Message-ID: <AANLkTinohj-=Y5zQ8RpaTseJ2h4Bv70eNU8e+fiugO6M@mail.gmail.com>

On Wed, Oct 13, 2010 at 12:35 PM, George, Wes E IV [NTK]
<Wesley.E.George at sprint.com> wrote:
>> Respectfully, "does it actually work" is germane to -every- policy
>> discussion.
>
> [WES] Never said otherwise. Matter of fact, I think that's exactly
>what I'm saying, Bill. Does preemptively assigning every ASN in
>the table an IPv6 address actually work (by itself) in getting
>them to deploy? You say

I say it moves the ball down field so that the next play or the play
after is in a position to score. That's how you succeed in any major
endeavor - one step at a time.


> Seriously, regardless of what metaphor you use, we're not
>actively doing something to prevent people from getting IPv6
>allocations if they can justify them (except possibly for 6rd).

If we ratify 2010-8 I'll agree with you, at least for end-user
assignments. I respect that you would like to stop there. Stopping
there is fair.

I'd like to go the extra mile -- not just remove barriers but reach
out and actively advocate deployment. As a matter of advocacy, it
stands undisputed that:

"Here are your shiny new addresses. Please start using them."

is a vastly more powerful message than

"You should use IPv6. Pay us and fill out the permission slip."

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 Oct 13 14:01:48 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Wed, 13 Oct 2010 14:01:48 -0400
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated Transfer
 Policy
In-Reply-To: <20101013165319.GA3056@ussenterprise.ufp.org>
Message-ID: <C8DB6C4C.131B1%marty@akamai.com>




On 10/13/10 12:53 PM, "Leo Bicknell" <bicknell at ufp.org> wrote:

> In a message written on Wed, Oct 13, 2010 at 08:45:31AM -0600, Chris
> Grundemann wrote:
>> Thanks for the excellent feedback Leo. I do want to point out that
>> when crafting this ultra-simple policy statement, we chose our words
>> very carefully: Internet stewardship *and* the _values_ expressed in
>> RFC2050 is meant to convey the spirit by which the RIRs should
>> interact ("do the right thing") without binding them explicitly to any
>> particular (possibly outdated) text.
> 
> For the record, I am ok with:
> 
> Policy statement: Any RIR's member may transfer IPv4 addresses to the
>                   member of another RIR as long as the two RIRs agree.
> 
> Your second sentence should be redundant, as the RIR's were formed
> under 2050, and should persue stweardship moving forward as a result.
> Including it though I think provides the impression of some limitations
> that are at best vague, and likely non-existant.
> 
> I used to be worried about a rich company buying up IPv4 space to
> keep it from their competitors.  As time as passed, I no longer
> worry about that much.

A rich company might also buy up address space to insure that their need is
going to be met. That's opposite of the nefarious condition you describe.
The "thwart a competitor" scenario is going to be too expensive and the best
way to thwart anyone is going to be to dual stack and beat them to the
proverbial punch IMHO.





From info at arin.net  Wed Oct 13 14:09:25 2010
From: info at arin.net (ARIN)
Date: Wed, 13 Oct 2010 14:09:25 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - October 2010
Message-ID: <4CB5F5D5.2020807@arin.net>

In accordance with the ARIN Policy Development Process the ARIN Advisory
Council (AC) held a meeting on 8 October 2010 and made decisions about
several draft policies.

The AC moved the following draft policy to last call (it will be posted
separately to last call):

   2010-12: IPv6 Subsequent Allocation

The AC abandoned the following draft policies:

   2010-9: IPv6 for 6rd
   2010-11: Required Resource Reviews
   2010-13: Permitted Uses of space reserved under NRPM 4.10

The AC chose 2010-12 over 2010-9. 2010-13 was abandoned due to lack of
support.

The AC stated the following about 2010-11:
"We understand that the community is concerned about seemingly limited
application of NRPM section 12, however, we believe that a combination
of factors have rendered the need for this policy moot at this time:
   1. Staff has agreed to produce and publish statistics regarding the
application and results of NRPM 12.
   2. The community seems roughly evenly divided on the application of
this policy. An even split is not consensus.
   3. We believe staff has received the message from the community that
we want them to make greater efforts to enforce ARIN policies through
the use of NRPM 12."

The following draft policies remain on the AC's docket for further
development and evaluation:

   2010-8: Rework of IPv6 assignment criteria
   2010-14: Standardize IP Reassignment Registration Requirements

The following draft policy was tabled until the AC's next meeting:

   2010-10 (Global Proposal): Global Policy for IPv4 Allocations by the
IANA Post Exhaustion

Several of the AC's decisions may be petitioned. This includes the draft
policies that were abandoned (2010-9, 2010-11, 2010-13) and the drafts
that were not selected for last call (2010-8, 2010-10, 2010-14). 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 will be five
business days after the AC's draft meeting minutes are published. 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,

Communications and Member Services
American Registry for Internet Numbers (ARIN)




















From info at arin.net  Wed Oct 13 14:10:05 2010
From: info at arin.net (ARIN)
Date: Wed, 13 Oct 2010 14:10:05 -0400
Subject: [arin-ppml] Draft Policy 2010-12: IPv6 Subsequent Allocation - Last
 Call (text revised)
Message-ID: <4CB5F5FD.7090806@arin.net>

The ARIN Advisory Council (AC) met on 8 October 2010 and decided to
send the following draft policy to last call:

    Draft Policy 2010-12: IPv6 Subsequent Allocation

The AC made the following revisions to the text:
   - /24 was added as the maximum prefix size.
   - Allocations will be from a designated block.
   - Requests for transition space will not be exempt from returns.

Feedback is encouraged during the last call period. All comments should
be provided to the Public Policy Mailing List. Last call for 2010-12
will expire on 27 October 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,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2010-12
IPv6 Subsequent Allocation

Version/Date: 13 October 2010

Policy statement:

Modify 6.5.2.1 Subsequent allocation criteria. Add the following:

Subsequent allocations will also be considered for deployments that
cannot be accommodated by, nor were accounted for, under the initial
allocation. Justification for the subsequent subnet size will be based
on the plan and technology provided with a /24 being the maximum allowed
for a transition technology. Justification for these allocations will be
reviewed every 3 years and reclaimed if it is not in use. All such
allocations for transitional technology will be made from a block
designated for this purpose.

Rationale:

Current organizations cannot get an allocation for a IPv6 transitional
technology if they have already received their initial allocation of
IPv6. The reason they cannot get an additional IPV6 allocation is
because they don't meet the HD ratio for a subsequent allocation and
they don't want to use their initial assignment because it is
insufficient, mapped out for other long term plans, or already has
portions in use.

An alternative proposal to permit more allocations was submitted that
supported 6rd but since then community members have come forward with
concern that this should support not just one particular technology but
any that enable v6 deployment.

Justification Example: Below is an example of how the details for a
technology and its subnet requirements could be provided as
justification. This example is based of 6rd.

6rd is intended to be an incremental method for deploying IPv6 and
bridge the gap for End Users to the IPv6 Internet. The method provides a
native dual-stack service to a subscriber site by leveraging existing
infrastructure. If an entity already has a /32 of IPv6 they can not use
the same /32 for native IPv6 as they do for the 6rd routing and a
separate minimum size of a /32 is required while a larger subnet like a
/28 may be needed based on a non-contiguous IPv4 addressing plan.

The 6rd prefix is an RIR delegated IPv6 prefix. It must encapsulate an
IPv4 address and must be short enough so that a /56 or /60 can be given
to subscribers. This example shows how the 6rd prefix is created based
on a /32 IPv6 prefix using RFC1918 address space from 10.0.0.0/8:

SP IPv6 prefix: 2001:0DB8::/32 v4suffix-length: 24 (from 10/8, first
octet (10) is excluded from the encoding) 6rd CE router IPv4 address:
10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56

This example shows how the 6rd prefix is created based on a /28 IPv6
prefix using one of several non-contiguous global address ranges:

SP IPv6 prefix: 2001:0DB0::/28 v4suffix-length: 32 (unable to exclude
common bits due to non-contiguous IPv4 allocations) 6rd CE router IPv4
address: 192.0.2.1 6rd site IPv6 prefix: 2001:0DBC:0000:2010::/60

Timetable for implementation: Immediate







From marty at akamai.com  Wed Oct 13 14:13:42 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Wed, 13 Oct 2010 14:13:42 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - October 2010
In-Reply-To: <4CB5F5D5.2020807@arin.net>
Message-ID: <C8DB6F16.131C3%marty@akamai.com>




On 10/13/10 2:09 PM, "ARIN" <info at arin.net> wrote:


[ clip ]

> 
> The following draft policy was tabled until the AC's next meeting:
> 
>    2010-10 (Global Proposal): Global Policy for IPv4 Allocations by the
> IANA Post Exhaustion
> 


Interesting. 40:5.


-M<





From BillD at cait.wustl.edu  Wed Oct 13 14:21:27 2010
From: BillD at cait.wustl.edu (Bill Darte)
Date: Wed, 13 Oct 2010 13:21:27 -0500
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated
	TransferPolicy
In-Reply-To: <4CB34773.2070308@arin.net>
References: <4CB34773.2070308@arin.net>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087B5D408@ex1.cait.wustl.edu>

I wonder about the term member in this policy proposal....seems that
membership in some regions may include entities from other RIR service
areas, thus providing confusion.

I think 'member of the service region' rather than member of the RIR is
a better description of a constituent who make make application against
the allocation/assigment policies of both RIRs.  


LACNIC
Organizations that receive IP addresses directly from LACNIC
automatically become members. According the size of the address space
each organization administers, there are different member categories and
levels. Membership is open to any interested person or organization;
this means that those organizations that do not receive IP addresses
directly from LACNIC can also apply for membership. 

AFRINIC
There are three types of membership:

    * Member Only (Members without Ressources assigned or allocated)
    * End User (Non-LIR and ASN holders)
    * LIR

APNIC
APNIC membership is open to all organizations and individuals.

RIPE-NCC
Any organisation or individual with a legal address in any country in
the RIPE NCC Service Region can become a member. We refer to our members
as 'Local Internet Registries' (LIRs).

ARIN
General members are comprised of entities with direct allocations of IP
address space from ARIN, either IPv4 or IPv6 resources. These entities
are automatically granted membership status when they receive their
initial address block. Additionally, any entity that has a signed
Registration Services Agreement (RSA) or Legacy RSA with ARIN and holds
a number resource from ARIN may choose to pay a fee to become an ARIN
member.

Trustee members are comprised of the individuals elected or appointed to
the ARIN Board of Trustees and the President of ARIN. Trustees are
members during their tenure on the Board. In some instances, a Trustee
member may also be a General Member if the entity by which they are
employed holds resources from ARIN.

Maybe something like this....

"Any member of an RIR's service region, unable to obtain addresses
within their region, may request the tranfer of available IPv4 addresses
from another RIR as long as the requestor qualifies under current
address allocation/assignment policy of BOTH RIRs"

That may even be overly broad as member of the service region would be
defined how?  Having and address and with owned, leased or rental
property?  Perhaps 'anyone' could apply for transfer of resources as
long as they were available and the requestor could meet the holding
regions allocation/assignment policy?

bd



> 
> 
> Policy Proposal 119: Globally Coordinated Transfer Policy
> 
> Proposal Originator: Chris Grundemann, Martin Hannigan, Jason Schiller
> 
> Proposal Version: 1.0
> 
> Date: 11 October 2010
> 
> Proposal type: new
> 
> Policy term: permanent
> 
> Policy statement: Any RIR's member may transfer IPv4 
> addresses to the member of another RIR as long as the two 
> RIRs agree and exercise Internet stewardship and the values 
> expressed in RFC2050.
> 
> Rationale: Since individual RIRs now allow transfers, it 
> makes sense to be able to transfer between regions as well.
> 
> Timetable for implementation: upon ratification of all five RIRs
> 
> Timetable for de-implementation: upon change to this policy 
> text in any RIR
> 
> 
> 
> 
> _______________________________________________
> 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 scottleibrand at gmail.com  Wed Oct 13 14:33:11 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 13 Oct 2010 14:33:11 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - October 2010
In-Reply-To: <4CB5F5D5.2020807@arin.net>
References: <4CB5F5D5.2020807@arin.net>
Message-ID: <AANLkTik+5Rz2kn8EFkdfnHzsTsFWB-oWVTKo7+sz4GMC@mail.gmail.com>

On Wed, Oct 13, 2010 at 2:09 PM, ARIN <info at arin.net> wrote:

> In accordance with the ARIN Policy Development Process the ARIN Advisory
> Council (AC) held a meeting on 8 October 2010 and made decisions about
> several draft policies.
>
> <snip>
>
> The following draft policies remain on the AC's docket for further
> development and evaluation:
>
>  2010-8: Rework of IPv6 assignment criteria
>  2010-14: Standardize IP Reassignment Registration Requirements
>
> The following draft policy was tabled until the AC's next meeting:
>
>  2010-10 (Global Proposal): Global Policy for IPv4 Allocations by the
> IANA Post Exhaustion
>
>
Some additional context (my own perspective, not speaking for the AC):

It is my impression that all three of these draft policies have the support
of most of the AC, and are likely to move forward to last call.  2010-8 and
2010-14 are being revised, and IMO should go out to last call once the
community is satisfied with the text on PPML.  That could happen at the
November AC meeting.

I saw pretty comprehensive support for 2010-10 from the community and most
of the AC, but given the urgency of 2010-12 (which took up most of our
meeting time), and the fact that 2010-10 is still being considered by the
other RIRs, it seemed to me that we should wait until next month's AC
meeting to make any decisions on whether to send it to last call as is,
revise it, or hold onto it until the other RIRs have all had a chance to
discuss it.

-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101013/36f14f07/attachment.htm>

From BillD at cait.wustl.edu  Wed Oct 13 14:45:08 2010
From: BillD at cait.wustl.edu (Bill Darte)
Date: Wed, 13 Oct 2010 13:45:08 -0500
Subject: [arin-ppml] Advisory Council Meeting Results - October 2010
In-Reply-To: <C8DB6F16.131C3%marty@akamai.com>
References: <4CB5F5D5.2020807@arin.net> <C8DB6F16.131C3%marty@akamai.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087B5D419@ex1.cait.wustl.edu>

No conspiracy.

This policy was tabled because the AC within the finite meeting
timeframe was unable to find concrete language that described the
addresses...that Geoff Huston and others referenced in the
meeting....which are the addresses residually held by the RIR of record
as the administrator of /8 blocks allocated across RIRs...as I
understand it.... and for which space an agreement between RIRs exists
(apparently) for the future distribution to other RIRs......or something
like that.

We struggled on how to craft language which would have described this
space along with the 'special use' addresses reference in section (2).
Also there were other changes in wording suggested at the meeting which
took some time to craft.

The AC awaits some label or description of those addresses which would
be consitently recognized across RIRs before crafting final language for
this Draft Policy.

I believe (speaking for myself only at this point), that the AC was
otherwise disposed to referring this Draft Policy to last call.

Bill Darte
Primary Shepherd 
Draft Policy 2010-10
ARIN AC


> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Hannigan, Martin
> Sent: Wednesday, October 13, 2010 1:14 PM
> To: ARIN; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Advisory Council Meeting Results - 
> October 2010
> 
> 
> 
> 
> On 10/13/10 2:09 PM, "ARIN" <info at arin.net> wrote:
> 
> 
> [ clip ]
> 
> > 
> > The following draft policy was tabled until the AC's next meeting:
> > 
> >    2010-10 (Global Proposal): Global Policy for IPv4 Allocations by 
> > the IANA Post Exhaustion
> > 
> 
> 
> Interesting. 40:5.
> 
> 
> -M<
> 
> 
> 
> _______________________________________________
> 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 marty at akamai.com  Wed Oct 13 14:56:55 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Wed, 13 Oct 2010 14:56:55 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - October 2010
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087B5D419@ex1.cait.wustl.edu>
Message-ID: <C8DB7937.131F8%marty@akamai.com>




On 10/13/10 2:45 PM, "Bill Darte" <BillD at cait.wustl.edu> wrote:

> No conspiracy.

Bill,

I didn't use the word conspiracy and didn't imply it. What I did say was
that there was overwhelming consensus and I'm interested as to why the AC
opted to table an issue that didn't have a consensus issue like most of the
proposals that we've been seeing in the last six months. The abandonments
were easy as they were clearly losers with respect to consensus.


> This policy was tabled because the AC within the finite meeting
> timeframe was unable to find concrete language that described the
> addresses...that Geoff Huston and others referenced in the
> meeting....which are the addresses residually held by the RIR of record
> as the administrator of /8 blocks allocated across RIRs...as I
> understand it.... and for which space an agreement between RIRs exists
> (apparently) for the future distribution to other RIRs......or something
> like that.

Why were the modifications suggested from the floor of the meeting
inadequate?

Best,

-mM<







From BillD at cait.wustl.edu  Wed Oct 13 15:12:35 2010
From: BillD at cait.wustl.edu (Bill Darte)
Date: Wed, 13 Oct 2010 14:12:35 -0500
Subject: [arin-ppml] Advisory Council Meeting Results - October 2010
In-Reply-To: <C8DB7937.131F8%marty@akamai.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087B5D419@ex1.cait.wustl.edu>
	<C8DB7937.131F8%marty@akamai.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087B5D425@ex1.cait.wustl.edu>

Marty,

Sorry if you construed my ill-advised conspiracy comment to apply to
you.  Just a figure of speach I often use when there is a lack of
transparency or inadequate explanation.

In answer to your further inquiry about the modifications suggested from
the floor.  I don't recall that there was a really clear statement or
wording change, but I take responsibility for not being able to
formulate the correct and acceptable language in my motion to send the
Draft Policy to last call.

Legitimate questions arose about the language and meaning and the
ensuing effort failed to reach clear, simple appropriate language which
all policies deserve.

bd

> -----Original Message-----
> From: Hannigan, Martin [mailto:marty at akamai.com] 
> Sent: Wednesday, October 13, 2010 1:57 PM
> To: Bill Darte; ARIN; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Advisory Council Meeting Results - 
> October 2010
> 
> 
> 
> 
> On 10/13/10 2:45 PM, "Bill Darte" <BillD at cait.wustl.edu> wrote:
> 
> > No conspiracy.
> 
> Bill,
> 
> I didn't use the word conspiracy and didn't imply it. What I 
> did say was that there was overwhelming consensus and I'm 
> interested as to why the AC opted to table an issue that 
> didn't have a consensus issue like most of the proposals that 
> we've been seeing in the last six months. The abandonments 
> were easy as they were clearly losers with respect to consensus.
> 
> 
> > This policy was tabled because the AC within the finite meeting 
> > timeframe was unable to find concrete language that described the 
> > addresses...that Geoff Huston and others referenced in the 
> > meeting....which are the addresses residually held by the RIR of 
> > record as the administrator of /8 blocks allocated across 
> RIRs...as I 
> > understand it.... and for which space an agreement between 
> RIRs exists
> > (apparently) for the future distribution to other RIRs......or 
> > something like that.
> 
> Why were the modifications suggested from the floor of the 
> meeting inadequate?
> 
> Best,
> 
> -mM<
> 
> 
> 
> 
> 
> 


From john.sweeting at twcable.com  Wed Oct 13 15:22:21 2010
From: john.sweeting at twcable.com (Sweeting, John)
Date: Wed, 13 Oct 2010 15:22:21 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - October 2010
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087B5D419@ex1.cait.wustl.edu>
Message-ID: <C8DB7F2D.170C6%john.sweeting@twcable.com>

Bill is correct. As we, the AC, understand it the problem with the address space referenced by Geoff will become a "moot point" in the next 2 weeks or so. We really could not find a correct way to identify this space as it is currently identified as "legacy" but not all legacy is part of this space. We decided to table until our next call as we really were at a dead end on how to handle this exception in the draft policy text.

Marty (or anyone),

Do you have a suggestion on how to handle that space in the text of the draft policy?

Thanks,
Johnn


+++


On 10/13/10 2:45 PM, "Bill Darte" <BillD at cait.wustl.edu> wrote:

No conspiracy.

This policy was tabled because the AC within the finite meeting
timeframe was unable to find concrete language that described the
addresses...that Geoff Huston and others referenced in the
meeting....which are the addresses residually held by the RIR of record
as the administrator of /8 blocks allocated across RIRs...as I
understand it.... and for which space an agreement between RIRs exists
(apparently) for the future distribution to other RIRs......or something
like that.

We struggled on how to craft language which would have described this
space along with the 'special use' addresses reference in section (2).
Also there were other changes in wording suggested at the meeting which
took some time to craft.

The AC awaits some label or description of those addresses which would
be consitently recognized across RIRs before crafting final language for
this Draft Policy.

I believe (speaking for myself only at this point), that the AC was
otherwise disposed to referring this Draft Policy to last call.

Bill Darte
Primary Shepherd
Draft Policy 2010-10
ARIN AC


> -----Original Message-----
> From: arin-ppml-bounces at arin.net
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Hannigan, Martin
> Sent: Wednesday, October 13, 2010 1:14 PM
> To: ARIN; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Advisory Council Meeting Results -
> October 2010
>
>
>
>
> On 10/13/10 2:09 PM, "ARIN" <info at arin.net> wrote:
>
>
> [ clip ]
>
> >
> > The following draft policy was tabled until the AC's next meeting:
> >
> >    2010-10 (Global Proposal): Global Policy for IPv4 Allocations by
> > the IANA Post Exhaustion
> >
>
>
> Interesting. 40:5.
>
>
> -M<
>
>
>
> _______________________________________________
> 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 E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.


From marty at akamai.com  Wed Oct 13 15:28:13 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Wed, 13 Oct 2010 15:28:13 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - October 2010
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087B5D425@ex1.cait.wustl.edu>
Message-ID: <C8DB808D.1320B%marty@akamai.com>




On 10/13/10 3:12 PM, "Bill Darte" <BillD at cait.wustl.edu> wrote:

[ snip ]


> In answer to your further inquiry about the modifications suggested from
> the floor.  I don't recall that there was a really clear statement or
> wording change, but I take responsibility for not being able to
> formulate the correct and acceptable language in my motion to send the
> Draft Policy to last call.

If I believed that the AC should act as individuals vs. a collective, I'd
accept that. It demonstrates that the AC might not be firing on all cylinder
from my perspective.

There were two suggestions made from the floor and an encouragement to make
the modifications to include "various registries" as excepted to address
Geoff Hustons hypothetical scenario.
 
> Legitimate questions arose about the language and meaning and the
> ensuing effort failed to reach clear, simple appropriate language which
> all policies deserve.
> 

What were those questions? It's not unfair to ask the AC to legitimize the
tabling of this proposal all considered.


Best Regards,

-M<



From john.sweeting at twcable.com  Wed Oct 13 15:36:45 2010
From: john.sweeting at twcable.com (Sweeting, John)
Date: Wed, 13 Oct 2010 15:36:45 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - October 2010
In-Reply-To: <C8DB808D.1320B%marty@akamai.com>
Message-ID: <C8DB828D.170D1%john.sweeting@twcable.com>

Marty,

Thanks for the opportunity to respond:

The main issue is that the official label for those addresses is legacy addresses but not all legacy addresses are wrapped up in that particular issue. Since we became aware that the issue surrounding these particular addresses should/would/will be cleared up in the next 10 days or so and given the struggle that we had trying to find language that would work we decided as a body to table the motion to send it to last call. This will be dealt with on our very next AC call which is scheduled for November 18th.

Thanks again,
John

+++


On 10/13/10 3:28 PM, "Hannigan, Martin" <marty at akamai.com> wrote:





On 10/13/10 3:12 PM, "Bill Darte" <BillD at cait.wustl.edu> wrote:

[ snip ]


> In answer to your further inquiry about the modifications suggested from
> the floor.  I don't recall that there was a really clear statement or
> wording change, but I take responsibility for not being able to
> formulate the correct and acceptable language in my motion to send the
> Draft Policy to last call.

If I believed that the AC should act as individuals vs. a collective, I'd
accept that. It demonstrates that the AC might not be firing on all cylinder
from my perspective.

There were two suggestions made from the floor and an encouragement to make
the modifications to include "various registries" as excepted to address
Geoff Hustons hypothetical scenario.

> Legitimate questions arose about the language and meaning and the
> ensuing effort failed to reach clear, simple appropriate language which
> all policies deserve.
>

What were those questions? It's not unfair to ask the AC to legitimize the
tabling of this proposal all considered.


Best Regards,

-M<

_______________________________________________
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 and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.


From BillD at cait.wustl.edu  Wed Oct 13 15:56:36 2010
From: BillD at cait.wustl.edu (Bill Darte)
Date: Wed, 13 Oct 2010 14:56:36 -0500
Subject: [arin-ppml] Advisory Council Meeting Results - October 2010
In-Reply-To: <C8DB808D.1320B%marty@akamai.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087B5D425@ex1.cait.wustl.edu>
	<C8DB808D.1320B%marty@akamai.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087B5D43E@ex1.cait.wustl.edu>

Marty,

The AC has a responsibility to the Internet community and the ARIN
service region to ensure that policy it recommends is clear and
understandable as well as needed.  The AC makes recommendation to
dispose of a policy through or out of the PDP by vote, needing 8,
individual, votes to take an action.  In that they are individuals and a
collective in their responsibility. 

The AC owes you and the community the same transparency....the formal
posting of its actions on the ppml along with statements about those
actions when something is dropped from the PDP. It also owes you minutes
of the meetings and those will be forthcoming.

It, in my opionion, does not owe you a word-for-word transcript of the
meeting.

I have been as clear as I can be about the disposition of 2010-10...the
reasons it was tabled and the ambiguity that resulted from the wording
used when I motioned for the Draft Policy to be forward to last call.  I
regret that is went contrary to your interests, mine and I believe the
rest of the community's.

As the Primary Shepherd for the Draft Policy 2010-10, I am currently
making every effort to address the concerns of my colleagues on the AC,
to produce clear, appropriate and acceptable language that will allow me
to make a successful motion at our November AC meeting.  That is my duty
and responsibility.

If will fulfill that duty and responsibility to the best of my ability
as I have always.  I believe that the AC not only fires on all
cylinders, but does a heroic job in their efforts to secure the best and
most appropriate policy for the constituents in the ARIN region.


Bill Darte

> -----Original Message-----
> From: Hannigan, Martin [mailto:marty at akamai.com] 
> Sent: Wednesday, October 13, 2010 2:28 PM
> To: Bill Darte; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Advisory Council Meeting Results - 
> October 2010
> 
> 
> 
> 
> On 10/13/10 3:12 PM, "Bill Darte" <BillD at cait.wustl.edu> wrote:
> 
> [ snip ]
> 
> 
> > In answer to your further inquiry about the modifications suggested 
> > from the floor.  I don't recall that there was a really clear 
> > statement or wording change, but I take responsibility for 
> not being 
> > able to formulate the correct and acceptable language in my 
> motion to 
> > send the Draft Policy to last call.
> 
> If I believed that the AC should act as individuals vs. a 
> collective, I'd accept that. It demonstrates that the AC 
> might not be firing on all cylinder from my perspective.
> 
> There were two suggestions made from the floor and an 
> encouragement to make the modifications to include "various 
> registries" as excepted to address Geoff Hustons hypothetical 
> scenario.
>  
> > Legitimate questions arose about the language and meaning and the 
> > ensuing effort failed to reach clear, simple appropriate language 
> > which all policies deserve.
> > 
> 
> What were those questions? It's not unfair to ask the AC to 
> legitimize the tabling of this proposal all considered.
> 
> 
> Best Regards,
> 
> -M<
> 
> 


From bill at herrin.us  Wed Oct 13 16:10:34 2010
From: bill at herrin.us (William Herrin)
Date: Wed, 13 Oct 2010 16:10:34 -0400
Subject: [arin-ppml] Draft Policy 2010-12: IPv6 Subsequent Allocation -
 Last Call (text revised)
In-Reply-To: <4CB5F5FD.7090806@arin.net>
References: <4CB5F5FD.7090806@arin.net>
Message-ID: <AANLkTimwjiRWQJTbJnJUAHPHPEQw=rOYqJzCMMV5zTdn@mail.gmail.com>

On Wed, Oct 13, 2010 at 2:10 PM, ARIN <info at arin.net> wrote:
> Draft Policy 2010-12
> IPv6 Subsequent Allocation
>
> Policy statement:
>
> Modify 6.5.2.1 Subsequent allocation criteria. Add the following:
>
> Subsequent allocations will also be considered for deployments that
> cannot be accommodated by, nor were accounted for, under the initial
> allocation. Justification for the subsequent subnet size will be based
> on the plan and technology provided with a /24 being the maximum allowed
> for a transition technology. Justification for these allocations will be
> reviewed every 3 years and reclaimed if it is not in use. All such
> allocations for transitional technology will be made from a block
> designated for this purpose.

This is much better but I think it could still benefit from a little tweaking.

I suggest replacing "Justification...transition technology" with:

"Justification for the subsequent subnet size will be based on the
plan and technology provided. No organization may hold more than a /24
under this subsection."

I'm being a little pedantic here, but the language doesn't specify
transition technologies for allowing an additional allocation yet does
specify transition technologies for the limit. I think it's smart not
to limit the application to "transition technologies" but the safety
limit should apply across the board.

The text also specifies /24 as the limit per allocation. It doesn't
clearly stop folks from coming back for additional /24 allocations.


I realize this is a last call, but given the time constraints for this
policy to be helpful, I offer these suggestions here in lieu of
objecting to the major changes from draft to last call that would
ordinarily recommend returning the document to discussion for the next
meeting.

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  Wed Oct 13 16:17:33 2010
From: bill at herrin.us (William Herrin)
Date: Wed, 13 Oct 2010 16:17:33 -0400
Subject: [arin-ppml] Controlling the IPv6 address consumption rate
In-Reply-To: <7B65164A-EC15-44EF-809E-90DAE80FC100@delong.com>
References: <AANLkTik+5zsTzepnf40faZVgOxNF2OOeMt-3o4p2wLEw@mail.gmail.com>
	<2B6D8499-377A-40FF-8263-79C6A3BFD3AE@delong.com>
	<AANLkTikQqyg8508hSUbxM5gMp=_BSuf41jaRByztaGuh@mail.gmail.com>
	<7B65164A-EC15-44EF-809E-90DAE80FC100@delong.com>
Message-ID: <AANLkTim6-itGJ-xd0k+Qa1xz6d99YNmyvEekm8njjENV@mail.gmail.com>

On Wed, Oct 13, 2010 at 11:58 AM, Owen DeLong <owen at delong.com> wrote:
> On Oct 13, 2010, at 7:43 AM, William Herrin wrote:
>> 8 bits of conservation worries me. We badly underestimated at the
>> start of IPv4. I'd be more comfortable starting with a more
>> conservative number (like 12 or 16) and then working down to 8 bits of
>> conservation after we gain a decade or two of experience.
>
> Yeah, I think that's pretty absurd. ?Conserving 255/256ths of the address
> space is somewhat absurd to begin with, but, hey, why not... Plenty of
> room in the 1/256th we're talking about, so, OK

Hi Owen,

I should clarify that I'm worried about actually enforcing 8 bits of
conservation over time. We'll keep finding reasons why we need more
bits for something else, and the century that 8 bits gives can't lose
many bits before IPv6's lifespan shortens below 20 years.


>> 8 bits also means you have only 14 bits left for the nice-to-haves. If
>> you spend 12 of those bits bringing the downstream end-user assignment
>> from the austere /60 to your preferred /48, you'll have only 2 bits
>> left. That doesn't give you much flexibility with your routing. Are
>> you sure you wouldn't rather put 4 of your bits to bring the
>> assignment up to /56 and use the remaining 10 to do smarter things
>> with your routing hierarchies? 256 LANs is a lot of LANs for all but
>> the largest customers.
>
> And here's where you run off the rails again by miscounting the bits.

I didn't exactly do anything deep with the math. Where do you think I
miscounted?

128 bits total
- 64 bits LAN
- at least 4 bits end user assignment
- at least 25 bits of assignments to satisfy 20M users in a big ISP without NAT
- at least 9 bits of 20M-user ISPs to satisfy 7B people in the world
- at least 4 bits to deal with the implications of future technology changes
- 8 bits of conservation to slow v6 depletion versus v4 depletion
= 14 bits remaining.

Take away 12 more bits to bring your end-user assignment from /60 back
up to the /48 that you and Michael want and you've just 2 bits to
spare on routing optimization.

Or take away the extra 7 bits (32 total) you need in the ISP
allocation to do 6rd. Really 8 bits (33 total) since you want native
and 6rd in the same aggregate allocation. That leaves you with only 6
bits for any other routing optimizations or improving the end user
assignment from /60.


Seriously, I understand your argument that it's OK to burn through
2000::/3 and then worry about these numbers in the remaining 7/8ths of
the space. You're not wrong. But there's no miscount. These numbers
are the real deal.



On Wed, Oct 13, 2010 at 11:46 AM,  <michael.dillon at bt.com> wrote:
>> At the same time (maybe even in the same RFC), the IETF decided that
>> end users would not multihome using BGP with multiple ISPs under IPv6.
>> That too is the official standard.
>
> I call BS on this one. If you say "maybe even in the same RFC" then you
> clearly don't know where this statement is or exactly what was written
> or in what context.

Michael,

I must have misunderstood your source and references when you said,
"Yes, those architects strayed from network architecture into
political and economic engineering when they assumed that the
provider-centric addressing scheme would be the only supported way of
building IPv6 networks."

http://lists.arin.net/pipermail/arin-ppml/2006-April/004952.html

Perhaps YOU would explain why YOU believed that the IETF was opposed
to provider independent addresses for multihomed end users?



> The fact is that I believe your analysis is flawed and is based on false premises
> and probably riddled with other problems.

If you'd care to suggest exactly which premises you think are false
and why, we could probably have a useful discussion. It's hard to
argue the merits of someone standing up and shouting, "you lie!"

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 Oct 13 16:33:13 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Wed, 13 Oct 2010 16:33:13 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - October 2010
In-Reply-To: <C8DB828D.170D1%john.sweeting@twcable.com>
Message-ID: <C8DB8FC9.13225%marty@akamai.com>




On 10/13/10 3:36 PM, "Sweeting, John" <john.sweeting at twcable.com> wrote:

> Marty,
> 
> Thanks for the opportunity to respond:
> 
> The main issue is that the official label for those addresses is legacy
> addresses but not all legacy addresses are wrapped up in that particular
> issue. Since we became aware that the issue surrounding these particular
> addresses should/would/will be cleared up in the next 10 days or so and given
> the struggle that we had trying to find language that would work we decided as
> a body to table the motion to send it to last call. This will be dealt with on
> our very next AC call which is scheduled for November 18th.


John,

I'm not challenging anything other than the fact that the AC opted to table
something that they had strong direction to work on. It's fair for us to ask
for the AC to legitimize a decision especially when there is clear
consensus.

With regards to the global proposal, you both (Bill and you) have now said
that Geoff's hypothetical issues will be moot in a few days. This proposal
is nowhere near adoption or implementation and won't be within ten days. It
will likely take six months or more if it is even adopted globally. I think
that issue is a non-issue unless there's something that don't know that
didn't come out in the list or meeting discussion.

That leaves Owens reading of some language which had identified as unclear
and we asserted that he was in error. Still, we suggested some text to
clarify and since it's only an edit related to clarity and not context it
could also be easily dealt with by the ASO AC at the end of the cycle and in
compliance with their PDP as well as all of the other regions.

This proposal is on the agenda of three other RIR forums at the moment.
LACNIC next week, Rome after that and AfriNIC following that. Making a major
modification at this point is a problem as was demonstrated with 2009-06,
and holding it up for a non context impacting clarity concern doesn't seem
reasonable all considered.

Best,

-M<



From scottleibrand at gmail.com  Wed Oct 13 16:39:02 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 13 Oct 2010 16:39:02 -0400
Subject: [arin-ppml] Draft Policy 2010-12: IPv6 Subsequent Allocation -
 Last Call (text revised)
In-Reply-To: <AANLkTimwjiRWQJTbJnJUAHPHPEQw=rOYqJzCMMV5zTdn@mail.gmail.com>
References: <4CB5F5FD.7090806@arin.net>
	<AANLkTimwjiRWQJTbJnJUAHPHPEQw=rOYqJzCMMV5zTdn@mail.gmail.com>
Message-ID: <AANLkTimwwtnFrOpfj_j=+ZsJ39TCo=MnxhBRHcDeo_Za@mail.gmail.com>

On Wed, Oct 13, 2010 at 4:10 PM, William Herrin <bill at herrin.us> wrote:

> On Wed, Oct 13, 2010 at 2:10 PM, ARIN <info at arin.net> wrote:
> > Draft Policy 2010-12
> > IPv6 Subsequent Allocation
> >
> > Policy statement:
> >
> > Modify 6.5.2.1 Subsequent allocation criteria. Add the following:
> >
> > Subsequent allocations will also be considered for deployments that
> > cannot be accommodated by, nor were accounted for, under the initial
> > allocation. Justification for the subsequent subnet size will be based
> > on the plan and technology provided with a /24 being the maximum allowed
> > for a transition technology. Justification for these allocations will be
> > reviewed every 3 years and reclaimed if it is not in use. All such
> > allocations for transitional technology will be made from a block
> > designated for this purpose.
>
> This is much better but I think it could still benefit from a little
> tweaking.
>
> I suggest replacing "Justification...transition technology" with:
>
> "Justification for the subsequent subnet size will be based on the
> plan and technology provided. No organization may hold more than a /24
> under this subsection."
>
> I'm being a little pedantic here, but the language doesn't specify
> transition technologies for allowing an additional allocation yet does
> specify transition technologies for the limit. I think it's smart not
> to limit the application to "transition technologies" but the safety
> limit should apply across the board.
>

Keep in mind that the way this is worded is to take into account the
sentiment expressed at the meeting that we shouldn't just be limiting
subsequent allocations to those needing it for transitional technologies.
For example, this would make it possible for someone to get a new v6 block
for wireless deployments if they have deployed their first block across all
of their wireline infrastructure, but aren't using enough of it to meet the
HD ratio.


> The text also specifies /24 as the limit per allocation. It doesn't
> clearly stop folks from coming back for additional /24 allocations.
>

My assumption was that additional subsequent allocations would be fine, but
additional large subsequent allocations for something like 6rd would be
denied on the basis that the only reason for getting a block that big is to
be able to number an arbitrarily large network out of the same subnet.


> I realize this is a last call, but given the time constraints for this
> policy to be helpful, I offer these suggestions here in lieu of
> objecting to the major changes from draft to last call that would
> ordinarily recommend returning the document to discussion for the next
> meeting.
>

Agreed.  I think we need to come to a consensus on language during the last
call period, so that the AC can make any necessary changes and send it to
the board ASAP.  I fully expect to see additional policy proposals to
further clean up the language, but that is much less urgent than removing
the v6 deployment roadblock that we have today.

-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101013/819c4d47/attachment.htm>

From scottleibrand at gmail.com  Wed Oct 13 16:50:03 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 13 Oct 2010 16:50:03 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - October 2010
In-Reply-To: <C8DB8FC9.13225%marty@akamai.com>
References: <C8DB828D.170D1%john.sweeting@twcable.com>
	<C8DB8FC9.13225%marty@akamai.com>
Message-ID: <AANLkTikqr-SOLQs2CXUEK0awE6Z7wUExJFxzANJRouct@mail.gmail.com>

On Wed, Oct 13, 2010 at 4:33 PM, Hannigan, Martin <marty at akamai.com> wrote:

>
>  This proposal is on the agenda of three other RIR forums at the moment.
> LACNIC next week, Rome after that and AfriNIC following that. Making a
> major
> modification at this point is a problem as was demonstrated with 2009-06,
> and holding it up for a non context impacting clarity concern doesn't seem
> reasonable all considered.
>

How likely do you think it is that we might see some edits come out of those
meetings?  If there are any such edits, I'd like to be able to make them in
our region as well, without having to start the process over again.  That is
part of the reason I'm reluctant to send it to the board before the other
regions have come to some sort of a consensus with you on language...

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

From john.sweeting at twcable.com  Wed Oct 13 16:53:04 2010
From: john.sweeting at twcable.com (Sweeting, John)
Date: Wed, 13 Oct 2010 16:53:04 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - October 2010
In-Reply-To: <C8DB8FC9.13225%marty@akamai.com>
Message-ID: <C8DB9470.170EF%john.sweeting@twcable.com>

We fully understand your POV on this but as you state, it will take 6 months or more to get through all the process. We will be taking action on it at our Nov 18th meeting, the motion on the floor is to send it to last call. That is the motion we will deal with at our next meeting, I would not be overly alarmed at this and I fully support the decision to table the motion based on the information that was provided, in fact it was a unanimous decision. This in no way is a show of non-support from the AC, just the AC performing its mission in the prescribed manner. I can assure you that Bill is working with Staff for clarity on the addresses in question and has been asked to have final resolution prior to the AC Nov 18th meeting. Thanks.


On 10/13/10 4:33 PM, "Hannigan, Martin" <marty at akamai.com> wrote:





On 10/13/10 3:36 PM, "Sweeting, John" <john.sweeting at twcable.com> wrote:

> Marty,
>
> Thanks for the opportunity to respond:
>
> The main issue is that the official label for those addresses is legacy
> addresses but not all legacy addresses are wrapped up in that particular
> issue. Since we became aware that the issue surrounding these particular
> addresses should/would/will be cleared up in the next 10 days or so and given
> the struggle that we had trying to find language that would work we decided as
> a body to table the motion to send it to last call. This will be dealt with on
> our very next AC call which is scheduled for November 18th.


John,

I'm not challenging anything other than the fact that the AC opted to table
something that they had strong direction to work on. It's fair for us to ask
for the AC to legitimize a decision especially when there is clear
consensus.

With regards to the global proposal, you both (Bill and you) have now said
that Geoff's hypothetical issues will be moot in a few days. This proposal
is nowhere near adoption or implementation and won't be within ten days. It
will likely take six months or more if it is even adopted globally. I think
that issue is a non-issue unless there's something that don't know that
didn't come out in the list or meeting discussion.

That leaves Owens reading of some language which had identified as unclear
and we asserted that he was in error. Still, we suggested some text to
clarify and since it's only an edit related to clarity and not context it
could also be easily dealt with by the ASO AC at the end of the cycle and in
compliance with their PDP as well as all of the other regions.

This proposal is on the agenda of three other RIR forums at the moment.
LACNIC next week, Rome after that and AfriNIC following that. Making a major
modification at this point is a problem as was demonstrated with 2009-06,
and holding it up for a non context impacting clarity concern doesn't seem
reasonable all considered.

Best,

-M<



________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.


From marty at akamai.com  Wed Oct 13 17:06:31 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Wed, 13 Oct 2010 17:06:31 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - October 2010
In-Reply-To: <C8DB9470.170EF%john.sweeting@twcable.com>
Message-ID: <C8DB9797.13237%marty@akamai.com>




On 10/13/10 4:53 PM, "Sweeting, John" <john.sweeting at twcable.com> wrote:

> We fully understand your POV on this but as you state, it will take 6 months
> or more to get through all the process. We will be taking action on it at our
> Nov 18th meeting, the motion on the floor is to send it to last call. That is
> the motion we will deal with at our next meeting, I would not be overly
> alarmed at this and I fully support the decision to table the motion based on
> the information that was provided, in fact it was a unanimous decision. This
> in no way is a show of non-support from the AC, just the AC performing its
> mission in the prescribed manner. I can assure you that Bill is working with
> Staff for clarity on the addresses in question and has been asked to have
> final resolution prior to the AC Nov 18th meeting. Thanks.
> 
> 


John,

So far, no clear legitimization as to why the AC would table something that
had strong consensus. This has far wider implications than just this
particular proposal.

 
Best,

-M<






From scottleibrand at gmail.com  Wed Oct 13 17:11:08 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 13 Oct 2010 17:11:08 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - October 2010
In-Reply-To: <AANLkTikqr-SOLQs2CXUEK0awE6Z7wUExJFxzANJRouct@mail.gmail.com>
References: <C8DB828D.170D1%john.sweeting@twcable.com>
	<C8DB8FC9.13225%marty@akamai.com>
	<AANLkTikqr-SOLQs2CXUEK0awE6Z7wUExJFxzANJRouct@mail.gmail.com>
Message-ID: <AANLkTikpHVXgBhj=W5Jv42M3YRVRvy37ejOeV1ddNvRT@mail.gmail.com>

On Wed, Oct 13, 2010 at 4:50 PM, Scott Leibrand <scottleibrand at gmail.com>wrote:

> On Wed, Oct 13, 2010 at 4:33 PM, Hannigan, Martin <marty at akamai.com>wrote:
>
>>
>>  This proposal is on the agenda of three other RIR forums at the moment.
>> LACNIC next week, Rome after that and AfriNIC following that. Making a
>> major
>> modification at this point is a problem as was demonstrated with 2009-06,
>> and holding it up for a non context impacting clarity concern doesn't seem
>> reasonable all considered.
>>
>
> How likely do you think it is that we might see some edits come out of
> those meetings?  If there are any such edits, I'd like to be able to make
> them in our region as well, without having to start the process over again.
> That is part of the reason I'm reluctant to send it to the board before the
> other regions have come to some sort of a consensus with you on language...
>

And if anyone else has any input on that, or on the larger issue of what to
do with a global policy that's passed in our region but then modified in
other regions, I'd love to hear them.  I know this has been a topic of
discussion at other RIRs (RIPE comes to mind), but we haven't really
discussed the issue here in the ARIN region.  We didn't really have a chance
to discuss this in our AC meeting, either, so I of course am not speaking
for the AC, and don't know whether anyone else on the AC shares my concern
or not.

-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101013/5a555fe5/attachment.htm>

From john.sweeting at twcable.com  Wed Oct 13 17:15:15 2010
From: john.sweeting at twcable.com (Sweeting, John)
Date: Wed, 13 Oct 2010 17:15:15 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - October 2010
In-Reply-To: <C8DB9797.13237%marty@akamai.com>
Message-ID: <C8DB99A3.170FC%john.sweeting@twcable.com>

Marty, I assure you there is no other implications whatsoever. There was a problem with the text in several AC member's mind and we were informed that the problem was about to be resolved. The motion to table was made, seconded and accepted unanimously. There really is nothing more to it than that.


On 10/13/10 5:06 PM, "Hannigan, Martin" <marty at akamai.com> wrote:





On 10/13/10 4:53 PM, "Sweeting, John" <john.sweeting at twcable.com> wrote:

> We fully understand your POV on this but as you state, it will take 6 months
> or more to get through all the process. We will be taking action on it at our
> Nov 18th meeting, the motion on the floor is to send it to last call. That is
> the motion we will deal with at our next meeting, I would not be overly
> alarmed at this and I fully support the decision to table the motion based on
> the information that was provided, in fact it was a unanimous decision. This
> in no way is a show of non-support from the AC, just the AC performing its
> mission in the prescribed manner. I can assure you that Bill is working with
> Staff for clarity on the addresses in question and has been asked to have
> final resolution prior to the AC Nov 18th meeting. Thanks.
>
>


John,

So far, no clear legitimization as to why the AC would table something that
had strong consensus. This has far wider implications than just this
particular proposal.


Best,

-M<







From marka at isc.org  Wed Oct 13 17:18:43 2010
From: marka at isc.org (Mark Andrews)
Date: Thu, 14 Oct 2010 08:18:43 +1100
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: Your message of "Wed, 13 Oct 2010 07:00:41 PDT."
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org><2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
Message-ID: <20101013211843.93D1F5B0367@drugs.dv.isc.org>


In message <2376C0DA-2491-40D4-B509-8C643C507A61 at delong.com>, Owen DeLong write
s:
> 
> On Oct 12, 2010, at 8:55 PM, Mark Andrews wrote:
> 
> > 
> > There is a increadable amount of bad information being spouted here.
> > 
> > To deploy 6rd in parallel with a native deployment you roughly need
> > double the IPv6 address space of a straight native deployment.
> > 
> > You need a /56 (/48) for every address in the DHCPv4 pools.  For
> > each DHCP pool you specify a 6rd prefix and set the IPv4MaskLen and
> > 6rdPrefixlen so you are not wasting IPv6 space.
> > 
> That is not the common practice.

And encoding the full 32 bits is not "best practice".  I also really
doubt that there is enough experience to actually define "common
practice" yet.

> > e.g.
> > If you have a 2 disjoint /16's spead over, multiple pops, then you
> > will have 2 6rd prefixes in use both with a IPv4MaskLen of 16.  Only
> > one of these will be handed out to a specific customer.  If you are
> > handing out /56's then the 6rdPrefixLen would be 40.  Each of these
> > 6rd prefixes would be a /40.
> 
> For the handful  of providers that have only 2 prefixes, that may be.
> For the vast majority of providers, the common practice (having more
> than a couple of prefixes) is to map the entire IPV4 space onto
> a customer prefix size (e.g. /56) yielding a need for a /24 (56-32)
> prefix for the ISP. Since no ISP has a significant fraction of the
> IPv4 space, much of that /24 is wasted.

And doing what I suggests works for any number of prefixes.
 
> > If you are handing out NATed addresses to your customers then you
> > may need to be more conservative in your DHCP pool sizes as the
> > pool size impacts on the amount of IPv6 address space needed.
> > 
> > If you are not using DHCPv4 for this you will most probably want to
> > code up a web page that returns custom 6rd parameter result based
> > on the IPv4 address the query came from plus the ablity to manually
> > specify the address that you want the 6rd parameters for.
> > 
> Regardless of the IPv4 address assignment method, the most common
> and most likely 6rd deployment mechanisms are incredibly wasteful
> of IPv6 address space. Further, limiting end customers to /56 is
> also a suboptimal IPv6 deployment.

If you don't do wasteful assignment you can do /48 customer assignement
just as easily.

> Unfortunately, the current state of last-mile technologies being the
> abysmal mess that it is, we basically have not choice other than
> providing for 6rd as an immediate deployment mechanism. As
> such, it should be done with the following safeguards:
> 
> +	Allocations from a specific prefix to facilitate a community decision
> 	to deprecate the technology when it is no longer necessary.
> 
> +	Native deployments should not be shared among the same
> 	IPv6 prefix.
> 
> +	We should make strong efforts to communicate and preserve
> 	the notion that this is a transitional and therefore temporary
> 	solution. That last mile technologies must catch up an
> 	provide reasonable and workable native IPv6 solutions.
>
> Owen
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From scottleibrand at gmail.com  Wed Oct 13 17:23:21 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 13 Oct 2010 17:23:21 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - October 2010
In-Reply-To: <C8DB9797.13237%marty@akamai.com>
References: <C8DB9470.170EF%john.sweeting@twcable.com>
	<C8DB9797.13237%marty@akamai.com>
Message-ID: <AANLkTikHZLf87U4AZrfxx1Lp4QX0a_wb59r4-+9aCVMa@mail.gmail.com>

On Wed, Oct 13, 2010 at 5:06 PM, Hannigan, Martin <marty at akamai.com> wrote:

>
>
> So far, no clear legitimization as to why the AC would table something that
> had strong consensus. This has far wider implications than just this
> particular proposal.
>
>
As best I can tell, the only difference between what the AC did with
2010-10 and the other two proposals we chose to keep working on (-8 and -14)
was that for -10 we had an actual motion on the floor before we realized
there were some issues we didn't have time to resolve, and decided to wait.
In all three cases, we'll be discussing what action to take at our next
meeting.

In my experience this is fairly routine, as most draft policies that end up
getting forwarded to last call come out of the public policy meeting
requiring some minor edits to address discussion points, which the AC works
with the authors to make prior to sending the draft policy to last call.

We could conceivably deal with more such issues immediately after the
meeting, but AFAICT that would require either a longer AC meeting, or a
concerted effort on behalf of shepherds, authors, and others to give up
their other evening activities to hammer out policy language.

Do you feel that forwarding this policy to last call right away, like we did
for 2010-12, is urgent?  If so, can you explain why?

Thanks,
Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101013/c92f0f1d/attachment.htm>

From marty at akamai.com  Wed Oct 13 17:26:58 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Wed, 13 Oct 2010 17:26:58 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - October 2010
In-Reply-To: <C8DB99A3.170FC%john.sweeting@twcable.com>
Message-ID: <C8DB9C62.1324B%marty@akamai.com>




On 10/13/10 5:15 PM, "Sweeting, John" <john.sweeting at twcable.com> wrote:

> Marty, I assure you there is no other implications whatsoever. There was a
> problem with the text in several AC member's mind and we were informed that
> the problem was about to be resolved. The motion to table was made, seconded
> and accepted unanimously. There really is nothing more to it than that.
> 


Let's back up. I made a single comment with respect to an observation that I
made concerning the tabling of a proposal in light of consensus. You guys
circled the wagons in response. That's fine, but continually implying that I
might think that there is some conspiracy or some other underhanded dealing
is not accurate. I don't believe either.

I do believe that the two reasons presented for the tabling of one of the
proposals on the AC docket are weak to say the least. That is the only issue
at hand and worthy of discussion. Otherwise, we're going in circles and we
may as well not bother.

Best,

-M<




From owen at delong.com  Wed Oct 13 17:33:45 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 13 Oct 2010 14:33:45 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CB5E076.7000701@townsley.net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
Message-ID: <C55BCD21-6EBA-4A3C-9563-EF4FEC66C0AE@delong.com>


On Oct 13, 2010, at 9:38 AM, Mark Townsley wrote:

> On 10/13/10 4:00 PM, Owen DeLong wrote:
>> 
>> Regardless of the IPv4 address assignment method, 	the most common
>> and most likely 6rd deployment mechanisms are incredibly wasteful
>> of IPv6 address space. Further, limiting end customers to /56 is
>> also a suboptimal IPv6 deployment.
> If you don't like /56, wait until you have tasted /64. That is what is
> coming to North America if ISPs in the ARIN region are forced to deploy
> within a /32 here. Make no mistake, the Residential Gateway vendors will
> figure out how to operate within this restriction, they have over a
> decade of experience faking things out for you with IPv4 -- it just will
> end up being more brittle and more expensive for the end-user.

I'm not advocating /64. I'm advocating /48 which requires native rather
than 6rd deployment. I'm saying that 6rd is a necessary evil for the
moment, but, must be regarded as a temporary expedient and still
evil vs. native IPv6 deployment with /48s as was the proper design
of the IPv6 addressing space.

>> Unfortunately, the current state of last-mile technologies being the
>> abysmal mess that it is, we basically have not choice other than
>> providing for 6rd as an immediate deployment mechanism. As
>> such, it should be done with the following safeguards:
>> 
>> +	Allocations from a specific prefix to facilitate a community decision
>> 	to deprecate the technology when it is no longer necessary.
> On one hand, you accept that some ISPs are stuck and need 6rd to deploy
> IPv6 now, but on the other hand you are saying that the community (i.e.,
> the ISP's competitors) have the power to rip their IPv6 deployment out
> from under them at any time. I know you want to be sure that 6rd goes
> away, but this is still throwing the baby out with the bathwater.
> 
The community is the entire global community. All of us that have to deal
with IP addressing issues. So, for some hold-out provider that failed
to evolve beyond 6rd in a timely manner, sure, they could get
overwhelmed by their competitors deciding not to continue routing
that space. However, if it's several large-scale deployments that
are still stuck with 6rd, I doubt that such filtration would occur on a
meaningful scale.

>> +	Native deployments should not be shared among the same
>> 	IPv6 prefix.
> Be careful of unintended consequences here. This kind of directive, if
> followed, could actually _discourage_ a smooth transition from 6rd to
> native, as well as wasting perfectly usable IPv6 space within the 6rd
> block based on hope of future reclamation by ARIN.

I doubt it.  I think if we craft policy to make it clear that service providers
can easily get a separate prefix for native and 6rd purposes, the
6rd coming from space set aside for later deprecation, we have
a good mix in the situation. Providers can easily put their native
deployments on separate and more efficiently assigned address
space and when they no longer need to maintain the 6rd hack
and have migrated the last of their customers off of it, the space
can be reclaimed. When enough providers no longer need it,
6rd in its entirety can be deprecated and providers can start to
choose to filter that space if they wish.

>> +	We should make strong efforts to communicate and preserve
>> 	the notion that this is a transitional and therefore temporary
>> 	solution. That last mile technologies must catch up and
>> 	provide reasonable and workable native IPv6 solutions.
> If ARIN really wanted to take a step forward towards helping the quality
> of IPv6 deployment on the Internet via deprecation of IPv6 space, it
> would start efforts to see 2002::/16 deprecated. First things first.
> 
I don't think we should deprecate 6to4 any faster than we should
deprecate 6rd. In reality, they share pretty much the same level of
problems and ugliness. 6rd has a few advantages in terms of
provider control. 6to4 has advantages in terms of addressing
efficiency. Both have more warts than benefit over all and both
are intended as short-term transitional solutions.

As Leo stated at the microphone. Temporary isn't. As such, we
must take steps to insure that it is or we will be stuck with this for
a very long time. That would be bad.

I will be able to make much better comments on this subject once
the output of the AC meeting last week is made public.


Owen



From scottleibrand at gmail.com  Wed Oct 13 17:34:47 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 13 Oct 2010 17:34:47 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - October 2010
In-Reply-To: <C8DB9C62.1324B%marty@akamai.com>
References: <C8DB99A3.170FC%john.sweeting@twcable.com>
	<C8DB9C62.1324B%marty@akamai.com>
Message-ID: <AANLkTi=9xrNk9SdZ=iy61eak4jPR_+Mc+7JuUzSd4COv@mail.gmail.com>

On Wed, Oct 13, 2010 at 5:26 PM, Hannigan, Martin <marty at akamai.com> wrote:

>
> I do believe that the two reasons presented for the tabling of one of the
> proposals on the AC docket are weak to say the least. That is the only
> issue
> at hand and worthy of discussion. Otherwise, we're going in circles and we
> may as well not bother.
>

Would you care to address the question of whether we should wait until each
RIR has had a chance to discuss the proposal at a public meeting before we
send it on to last call and then to the board?

I support this proposal, but I think it has a better chance of success if we
work to accept input from the other regions.  IMO that was our (my) biggest
failing with 2009-3: we passed the modified version it in our region, but
never brought the modified version up for discussion anywhere else.

Thanks,
Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101013/56753f20/attachment.htm>

From cgrundemann at gmail.com  Wed Oct 13 17:44:25 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 13 Oct 2010 15:44:25 -0600
Subject: [arin-ppml] Advisory Council Meeting Results - October 2010
In-Reply-To: <AANLkTi=9xrNk9SdZ=iy61eak4jPR_+Mc+7JuUzSd4COv@mail.gmail.com>
References: <C8DB99A3.170FC%john.sweeting@twcable.com>
	<C8DB9C62.1324B%marty@akamai.com>
	<AANLkTi=9xrNk9SdZ=iy61eak4jPR_+Mc+7JuUzSd4COv@mail.gmail.com>
Message-ID: <AANLkTi==Vd4DR+4dUt2OnJB_C5af+9NPW3SCYDqQEzXo@mail.gmail.com>

On Wed, Oct 13, 2010 at 15:34, Scott Leibrand <scottleibrand at gmail.com> wrote:
>
> Would you care to address the question of whether we should wait until each
> RIR has had a chance to discuss the proposal at a public meeting before we
> send it on to last call and then to the board?

The problem with the "wait and see" approach is that if all the RIRs
adopt it, then the policy never goes anywhere because no RIR actually
does anything (since they are all waiting to see what the others do).

Note: I do not think that is what is happening here but I do want to
ensure that it does not become that.

I fully support the AC spending a proper amount of time (and effort)
on each proposal, even if that means taking several meetings to
advance a policy to last call. In this case, there is some urgency
around 2010-10 simply because global policies seem to need momentum.
Having the policy in last call in one region before the conversation
in the next helps build that momentum. Of course, the strong consensus
in the room in Atlanta coupled with the AC's commitment to discuss the
draft at their next meeting at length are both strong indicators of
momentum as well.

We need to remember that this policy is needed at (preferably before)
the time of IANA IPv4 exhaustion, which is quickly approaching no
matter who's clock you use.

> I support this proposal, but I think it has a better chance of success if we
> work to accept input from the other regions.? IMO that was our (my) biggest
> failing with 2009-3: we passed the modified version it in our region, but
> never brought the modified version up for discussion anywhere else.

Very true - one thing to note in this case however is that the
proposed policy text was floated in all five regions before being
submitted as an official proposal and has since been discussed at two
meetings now (APNIC and ARIN).  I believe that the intent of the
policy is sound and will not need to be materially changed in any
region.

I would rather move the policy to an extended last-call where it can
receive any final edits prior to adoption by the board.

Cheers,
~Chris


> Thanks,
> Scott
>
> _______________________________________________
> 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  Wed Oct 13 17:45:54 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 13 Oct 2010 14:45:54 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <20101013165959.GB3056@ussenterprise.ufp.org>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<20101013165959.GB3056@ussenterprise.ufp.org>
Message-ID: <CF727814-54AF-439B-83E6-541E2F32D92A@delong.com>


On Oct 13, 2010, at 9:59 AM, Leo Bicknell wrote:

> In a message written on Wed, Oct 13, 2010 at 06:38:14PM +0200, Mark Townsley wrote:
>> If you don't like /56, wait until you have tasted /64. That is what is
> 
> I would be fine with requiring 6rd to provide a /64, while keeping
> the standard that native connections get a /48.  This provides
> incentive to the end user to pressure their ISP to move from 6rd
> to native, and/or to switch providers to one with native connectivity.
> 
More likely it provides the lasting impression that /64s are the normal
subscriber allocation and breaks significant possible innovation.
My complaint about /56s was that they are too small, not that they
are too large.

> Given the realities of 6rd needing 32 bits to map IPv4 into this
> doesn't seem like such a bad thing.
> 
I say we swallow hard and let 6rd eat something approaching a /12
of /24s handed out to providers to facilitate /56s. Hopefully the fact that
/56 is not /48 will eventually lead to the deprecation of 6rd in favor of
native IPv6, but, at least we aren't completely breaking end user
innovations in favor of unnecessary address conservation.

>> On one hand, you accept that some ISPs are stuck and need 6rd to deploy
>> IPv6 now, but on the other hand you are saying that the community (i.e.,
>> the ISP's competitors) have the power to rip their IPv6 deployment out
>> from under them at any time. I know you want to be sure that 6rd goes
>> away, but this is still throwing the baby out with the bathwater.
> 
> I too want to be sure the community can make 6rd go away, because
> it is amazing waste of bits, and mapping all the old trash into 6rd
> space.  Still, you make a valid point, no one should want to deploy
> something that could be ripped out from under them at any time.
> 
Noone should WANT to deploy 6rd. It's one of those things that we
swallow hard, hold our noses, and deploy as a hot-fix until our
vendors catch up and provide working IPv6 last mile technologies.

Once the vendors catch up, we should all want to rip it out as quickly
as practicable. Not just because it's a huge waste of bits (in fact, that's
among the least of its issues IMHO).

> I would support making all 6rd prefixes have a minimum lifetime,
> perhaps 7-10 years (which should cover even the longest equipment
> refresh cycles), after which the community can pull support at any
> time.  That way 6rd users have a guaranteed minimum, it can easily
> be extended (by the community doing nothing and letting them keep
> going), and the community can still pull the plug on this waste.
> 
The pulling of support won't come in the form of an ARIN decision,
it will come in the form of providers deciding to filter the prefixes
that were dedicated to 6rd.

> "ARIN will demand the return of all 6rd prefixes when the prefix is no
> longer in use for 6rd services, or when the community decides that 6rd
> is no longer a benefit to the community.  This cannot occur before
> January 1st, 2020."
> 
ARIN demand for return is pretty irrelevant to the equation.

Owen




From owen at delong.com  Wed Oct 13 17:56:55 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 13 Oct 2010 14:56:55 -0700
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated
	TransferPolicy
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087B5D408@ex1.cait.wustl.edu>
References: <4CB34773.2070308@arin.net>
	<EACF8B735E9CBA4B8BAF9E4165D03087B5D408@ex1.cait.wustl.edu>
Message-ID: <8CD218DA-6DAA-44B8-97D3-EA52980B3FF0@delong.com>

Worse, it would preclude non-members in the ARIN region, many of
which are resource holders, from participating in the policy.

Owen

On Oct 13, 2010, at 11:21 AM, Bill Darte wrote:

> I wonder about the term member in this policy proposal....seems that
> membership in some regions may include entities from other RIR service
> areas, thus providing confusion.
> 
> I think 'member of the service region' rather than member of the RIR is
> a better description of a constituent who make make application against
> the allocation/assigment policies of both RIRs.  
> 
> 
> LACNIC
> Organizations that receive IP addresses directly from LACNIC
> automatically become members. According the size of the address space
> each organization administers, there are different member categories and
> levels. Membership is open to any interested person or organization;
> this means that those organizations that do not receive IP addresses
> directly from LACNIC can also apply for membership. 
> 
> AFRINIC
> There are three types of membership:
> 
>    * Member Only (Members without Ressources assigned or allocated)
>    * End User (Non-LIR and ASN holders)
>    * LIR
> 
> APNIC
> APNIC membership is open to all organizations and individuals.
> 
> RIPE-NCC
> Any organisation or individual with a legal address in any country in
> the RIPE NCC Service Region can become a member. We refer to our members
> as 'Local Internet Registries' (LIRs).
> 
> ARIN
> General members are comprised of entities with direct allocations of IP
> address space from ARIN, either IPv4 or IPv6 resources. These entities
> are automatically granted membership status when they receive their
> initial address block. Additionally, any entity that has a signed
> Registration Services Agreement (RSA) or Legacy RSA with ARIN and holds
> a number resource from ARIN may choose to pay a fee to become an ARIN
> member.
> 
> Trustee members are comprised of the individuals elected or appointed to
> the ARIN Board of Trustees and the President of ARIN. Trustees are
> members during their tenure on the Board. In some instances, a Trustee
> member may also be a General Member if the entity by which they are
> employed holds resources from ARIN.
> 
> Maybe something like this....
> 
> "Any member of an RIR's service region, unable to obtain addresses
> within their region, may request the tranfer of available IPv4 addresses
> from another RIR as long as the requestor qualifies under current
> address allocation/assignment policy of BOTH RIRs"
> 
> That may even be overly broad as member of the service region would be
> defined how?  Having and address and with owned, leased or rental
> property?  Perhaps 'anyone' could apply for transfer of resources as
> long as they were available and the requestor could meet the holding
> regions allocation/assignment policy?
> 
> bd
> 
> 
> 
>> 
>> 
>> Policy Proposal 119: Globally Coordinated Transfer Policy
>> 
>> Proposal Originator: Chris Grundemann, Martin Hannigan, Jason Schiller
>> 
>> Proposal Version: 1.0
>> 
>> Date: 11 October 2010
>> 
>> Proposal type: new
>> 
>> Policy term: permanent
>> 
>> Policy statement: Any RIR's member may transfer IPv4 
>> addresses to the member of another RIR as long as the two 
>> RIRs agree and exercise Internet stewardship and the values 
>> expressed in RFC2050.
>> 
>> Rationale: Since individual RIRs now allow transfers, it 
>> makes sense to be able to transfer between regions as well.
>> 
>> Timetable for implementation: upon ratification of all five RIRs
>> 
>> Timetable for de-implementation: upon change to this policy 
>> text in any RIR
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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  Wed Oct 13 17:54:26 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 13 Oct 2010 14:54:26 -0700
Subject: [arin-ppml] Draft Policy 2010-12: IPv6 Subsequent Allocation -
	Last Call (text revised)
In-Reply-To: <4CB5F5FD.7090806@arin.net>
References: <4CB5F5FD.7090806@arin.net>
Message-ID: <F28A2A7A-9452-49E4-BCF0-BBDB9C8F4556@delong.com>

To clarify, the /24 maximum and the designated block apply ONLY
to subsequent allocations for transitional purposes. Subsequent allocations
for native IPv6 deployment are not restricted or encumbered in any way
other than the standards set forth in existing policy.

Owen

On Oct 13, 2010, at 11:10 AM, ARIN wrote:

> The ARIN Advisory Council (AC) met on 8 October 2010 and decided to
> send the following draft policy to last call:
> 
>   Draft Policy 2010-12: IPv6 Subsequent Allocation
> 
> The AC made the following revisions to the text:
>  - /24 was added as the maximum prefix size.
>  - Allocations will be from a designated block.
>  - Requests for transition space will not be exempt from returns.
> 
> Feedback is encouraged during the last call period. All comments should
> be provided to the Public Policy Mailing List. Last call for 2010-12
> will expire on 27 October 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,
> 
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Draft Policy 2010-12
> IPv6 Subsequent Allocation
> 
> Version/Date: 13 October 2010
> 
> Policy statement:
> 
> Modify 6.5.2.1 Subsequent allocation criteria. Add the following:
> 
> Subsequent allocations will also be considered for deployments that
> cannot be accommodated by, nor were accounted for, under the initial
> allocation. Justification for the subsequent subnet size will be based
> on the plan and technology provided with a /24 being the maximum allowed
> for a transition technology. Justification for these allocations will be
> reviewed every 3 years and reclaimed if it is not in use. All such
> allocations for transitional technology will be made from a block
> designated for this purpose.
> 
> Rationale:
> 
> Current organizations cannot get an allocation for a IPv6 transitional
> technology if they have already received their initial allocation of
> IPv6. The reason they cannot get an additional IPV6 allocation is
> because they don't meet the HD ratio for a subsequent allocation and
> they don't want to use their initial assignment because it is
> insufficient, mapped out for other long term plans, or already has
> portions in use.
> 
> An alternative proposal to permit more allocations was submitted that
> supported 6rd but since then community members have come forward with
> concern that this should support not just one particular technology but
> any that enable v6 deployment.
> 
> Justification Example: Below is an example of how the details for a
> technology and its subnet requirements could be provided as
> justification. This example is based of 6rd.
> 
> 6rd is intended to be an incremental method for deploying IPv6 and
> bridge the gap for End Users to the IPv6 Internet. The method provides a
> native dual-stack service to a subscriber site by leveraging existing
> infrastructure. If an entity already has a /32 of IPv6 they can not use
> the same /32 for native IPv6 as they do for the 6rd routing and a
> separate minimum size of a /32 is required while a larger subnet like a
> /28 may be needed based on a non-contiguous IPv4 addressing plan.
> 
> The 6rd prefix is an RIR delegated IPv6 prefix. It must encapsulate an
> IPv4 address and must be short enough so that a /56 or /60 can be given
> to subscribers. This example shows how the 6rd prefix is created based
> on a /32 IPv6 prefix using RFC1918 address space from 10.0.0.0/8:
> 
> SP IPv6 prefix: 2001:0DB8::/32 v4suffix-length: 24 (from 10/8, first
> octet (10) is excluded from the encoding) 6rd CE router IPv4 address:
> 10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56
> 
> This example shows how the 6rd prefix is created based on a /28 IPv6
> prefix using one of several non-contiguous global address ranges:
> 
> SP IPv6 prefix: 2001:0DB0::/28 v4suffix-length: 32 (unable to exclude
> common bits due to non-contiguous IPv4 allocations) 6rd CE router IPv4
> address: 192.0.2.1 6rd site IPv6 prefix: 2001:0DBC:0000:2010::/60
> 
> 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.



From bicknell at ufp.org  Wed Oct 13 18:07:58 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 13 Oct 2010 15:07:58 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <CF727814-54AF-439B-83E6-541E2F32D92A@delong.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<20101013165959.GB3056@ussenterprise.ufp.org>
	<CF727814-54AF-439B-83E6-541E2F32D92A@delong.com>
Message-ID: <20101013220758.GA27979@ussenterprise.ufp.org>

In a message written on Wed, Oct 13, 2010 at 02:45:54PM -0700, Owen DeLong wrote:
> More likely it provides the lasting impression that /64s are the normal
> subscriber allocation and breaks significant possible innovation.
> My complaint about /56s was that they are too small, not that they
> are too large.

Let's be honest here, in broad strokes, at least in the US...

Cable and FTTH providers are on a track to do native dual stack,
and will likely be doing /48's although a few may opt for /56's.

DSL providers, and their vendors, have been caught with their pants
down with respect to doing dual-stack and are looking hard at 6rd
as a bridge deployment until they can either migrate users to FTTH
or deploy dual stack capable DSL equipment.

Given most areas have a cable plus DSL duopoly if the DSL folks
have to deploy /64's because that's all the mess we can make with
the address space they will be at a competitive disadvantage compared
to the cable providers handing out /48's (or maybe /56's).

> I say we swallow hard and let 6rd eat something approaching a /12
> of /24s handed out to providers to facilitate /56s. Hopefully the fact that
> /56 is not /48 will eventually lead to the deprecation of 6rd in favor of
> native IPv6, but, at least we aren't completely breaking end user
> innovations in favor of unnecessary address conservation.

If you're going to go that big, then why not go the whole way?  A
/16 will allow a provider to do 32 bits of 6rd and still give out
/48's.  Let's craft the policy so you must be turning up at least,
oh, 100,000 subs using this technology.  I think we're now down to
perhaps 10-20 ISP's in the US that can meet that bar and want to
deploy 6rd, they can do it right, and we'll probably burn less than
a /12.

But I have to say, we're in scary land.  For all the IPv6 has lots of
numbers arguments a /16 is only 65536 netblocks.  If we do this for the
top 10-20 providers in every country in the world we're talking about
using up 10-20% of the entire IPv6 space just for ONE transition
technology.  

The only way I can support any of this is if we have strong controls to
make it temporary, but the more folks we turn up on it the more pressure
there is going to be that it not be temporary, or at least that
temporary is a very long time.

The best way to make temporary be really temporary is to make sure
it is more painful than the alternatives.  While I want to put 6rd
in the hands of the folks who need it (especially large DSL providers
with millions of subscribers) I want to make it painful for them
at every step.  Smaller subnets than their competitors, justify it
to ARIN every 3 months, pay 10x the fees, etc.  We must use EVERY tool
at our disposal to make this odious, while staying within the bounds of
it being useful.

> Noone should WANT to deploy 6rd. It's one of those things that we
> swallow hard, hold our noses, and deploy as a hot-fix until our
> vendors catch up and provide working IPv6 last mile technologies.

I agree, but quite frankly, and this is very much opionion, we're
bailing out the folks who were asleep at the switch.  Cable Labs figured
out how to do IPv6 over Cable in plenty of time, and while folks have
not deployed as fast as I would like the gear is there, it works, and is
being deployed.  For some reason the DSL folks, vendors and customers,
stuck their head in the sand and lost a number of years here where they
could have been deploying better stuff.  I am lothe to reward that
behavior.

> The pulling of support won't come in the form of an ARIN decision,
> it will come in the form of providers deciding to filter the prefixes
> that were dedicated to 6rd.

True, but a lot more people will be likely to filter if ARIN says
"experiment over".  I realze the real work is feet on the street, but I
think this is a critical symbolic step.

> ARIN demand for return is pretty irrelevant to the equation.

I disagree strongly.  There will be folks tempted to keep their
customers in the 6rd space so they don't have to renumber.  We've
already seen presentations on native + 6rd hosts from the same block in
Atlanta.  To allow that will create incredably sparely allocated blocks,
and further reward the folks who failed to plan with gigantic blocks
they will never use.  I don't know how that will bite us in the
future, but it will.

If we're going to allocate new blocks specifically for transition
technologies they need to come back to ARIN.

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

From owen at delong.com  Wed Oct 13 18:13:30 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 13 Oct 2010 15:13:30 -0700
Subject: [arin-ppml] Draft Policy 2010-12: IPv6 Subsequent Allocation -
	Last Call (text revised)
In-Reply-To: <AANLkTimwjiRWQJTbJnJUAHPHPEQw=rOYqJzCMMV5zTdn@mail.gmail.com>
References: <4CB5F5FD.7090806@arin.net>
	<AANLkTimwjiRWQJTbJnJUAHPHPEQw=rOYqJzCMMV5zTdn@mail.gmail.com>
Message-ID: <462ACA3F-B76A-4E6F-853E-19F42483145F@delong.com>


On Oct 13, 2010, at 1:10 PM, William Herrin wrote:

> On Wed, Oct 13, 2010 at 2:10 PM, ARIN <info at arin.net> wrote:
>> Draft Policy 2010-12
>> IPv6 Subsequent Allocation
>> 
>> Policy statement:
>> 
>> Modify 6.5.2.1 Subsequent allocation criteria. Add the following:
>> 
>> Subsequent allocations will also be considered for deployments that
>> cannot be accommodated by, nor were accounted for, under the initial
>> allocation. Justification for the subsequent subnet size will be based
>> on the plan and technology provided with a /24 being the maximum allowed
>> for a transition technology. Justification for these allocations will be
>> reviewed every 3 years and reclaimed if it is not in use. All such
>> allocations for transitional technology will be made from a block
>> designated for this purpose.
> 
> This is much better but I think it could still benefit from a little tweaking.
> 
> I suggest replacing "Justification...transition technology" with:
> 
> "Justification for the subsequent subnet size will be based on the
> plan and technology provided. No organization may hold more than a /24
> under this subsection."
> 
That was specifically rejected because we did not feel the need to
encumber general ISP subsequent allocations with such a restriction.
If a  non-transitional native IPv6 deployment can show a need for
a larger prefix, then, we should grant it to them.

> I'm being a little pedantic here, but the language doesn't specify
> transition technologies for allowing an additional allocation yet does
> specify transition technologies for the limit. I think it's smart not
> to limit the application to "transition technologies" but the safety
> limit should apply across the board.
> 
Nope. Specifically it should not. An ISP with more than about
12 million end sites served, each of which gets a /48 will need
more than a /24 to support that.

> The text also specifies /24 as the limit per allocation. It doesn't
> clearly stop folks from coming back for additional /24 allocations.
> 
For better or worse, the feeling was that ISPs should not be
precluded from utilizing multiple transitional technologies.

> 
> I realize this is a last call, but given the time constraints for this
> policy to be helpful, I offer these suggestions here in lieu of
> objecting to the major changes from draft to last call that would
> ordinarily recommend returning the document to discussion for the next
> meeting.
> 
I don't agree that these were major changes. They were minor
adjustments made in response to feedback from the community.

Owen



From bill at herrin.us  Wed Oct 13 18:19:15 2010
From: bill at herrin.us (William Herrin)
Date: Wed, 13 Oct 2010 18:19:15 -0400
Subject: [arin-ppml] Draft Policy 2010-12: IPv6 Subsequent Allocation -
 Last Call (text revised)
In-Reply-To: <F28A2A7A-9452-49E4-BCF0-BBDB9C8F4556@delong.com>
References: <4CB5F5FD.7090806@arin.net>
	<F28A2A7A-9452-49E4-BCF0-BBDB9C8F4556@delong.com>
Message-ID: <AANLkTinGWK4nnxdcOKf=bmGdLG4dRYjncYcv9Wuh5dGB@mail.gmail.com>

On Wed, Oct 13, 2010 at 5:54 PM, Owen DeLong <owen at delong.com> wrote:
> To clarify, the /24 maximum and the designated block apply ONLY
> to subsequent allocations for transitional purposes. Subsequent allocations
> for native IPv6 deployment are not restricted or encumbered in any way
> other than the standards set forth in existing policy.

Ah. In that case, I OPPOSE draft policy 2010-12 as written.

I would support a revised version that applies the /24 limit to any
subsequent allocation _for which the prior efficient utilization
requirements have been waived_, regardless of whether its for
transitional technologies.

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 farmer at umn.edu  Wed Oct 13 18:43:36 2010
From: farmer at umn.edu (David Farmer)
Date: Wed, 13 Oct 2010 17:43:36 -0500
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CB5E076.7000701@townsley.net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
Message-ID: <4CB63618.9080308@umn.edu>

On 10/13/10 11:38 CDT, Mark Townsley wrote:
>   On 10/13/10 4:00 PM, Owen DeLong wrote:
>>
>> Regardless of the IPv4 address assignment method, 	the most common
>> and most likely 6rd deployment mechanisms are incredibly wasteful
>> of IPv6 address space. Further, limiting end customers to /56 is
>> also a suboptimal IPv6 deployment.
> If you don't like /56, wait until you have tasted /64. That is what is
> coming to North America if ISPs in the ARIN region are forced to deploy
> within a /32 here. Make no mistake, the Residential Gateway vendors will
> figure out how to operate within this restriction, they have over a
> decade of experience faking things out for you with IPv4 -- it just will
> end up being more brittle and more expensive for the end-user.

Actually I believe most of us agree that, 6rd is probably the best of 
the currently available IPv6 transition solutions for most broadband 
access providers and therefore extremely important for the actual 
deployment of IPv6.

>> Unfortunately, the current state of last-mile technologies being the
>> abysmal mess that it is, we basically have not choice other than
>> providing for 6rd as an immediate deployment mechanism. As
>> such, it should be done with the following safeguards:
>>
>> +	Allocations from a specific prefix to facilitate a community decision
>> 	to deprecate the technology when it is no longer necessary.
> On one hand, you accept that some ISPs are stuck and need 6rd to deploy
> IPv6 now, but on the other hand you are saying that the community (i.e.,
> the ISP's competitors) have the power to rip their IPv6 deployment out
> from under them at any time. I know you want to be sure that 6rd goes
> away, but this is still throwing the baby out with the bathwater.

I'm not sure that 6rd should be deprecated in the future or when. 
However, I do think preserving a valid option to deprecate it in the 
future is a reasonable precaution, especially given the necessity that 
we move forward with 6rd deployment and not debate the best 6rd endgame 
for an additional 6 months or a year.  And for that matter probably get 
it wrong anyway.

So, I think preserving 6rd endgame options for a future debate and 
moving on to the deployment of 6rd is the most sensible course of action 
for our community at this time.  Making 6rd allocations from a defined 
prefix preserves an option for the community to cleanly deprecate 6rd if 
or when it deems that necessary.  I believe the time to actually start 
the discussion of the proper 6rd endgame is in about 3 to 5 years, not now.

>> +	Native deployments should not be shared among the same
>> 	IPv6 prefix.
> Be careful of unintended consequences here. This kind of directive, if
> followed, could actually _discourage_ a smooth transition from 6rd to
> native, as well as wasting perfectly usable IPv6 space within the 6rd
> block based on hope of future reclamation by ARIN.

Yes, this one cuts both ways, personally I believe this will be the crux 
of the 6rd endgame debate, but only time is going to really tell.  I 
propose we not debate the 6rd endgame now and get 6rd deployed and bring 
up then issue when it is time to start a 6rd endgame discussion in 3 to 
5 years, with a 6rd endgame probably happening 5 to 10 years from now.

>> +	We should make strong efforts to communicate and preserve
>> 	the notion that this is a transitional and therefore temporary
>> 	solution. That last mile technologies must catch up and
>> 	provide reasonable and workable native IPv6 solutions.
> If ARIN really wanted to take a step forward towards helping the quality
> of IPv6 deployment on the Internet via deprecation of IPv6 space, it
> would start efforts to see 2002::/16 deprecated. First things first.

I think you may have a fair point there, maybe 6to4 should be deprecated 
before 6rd.  Maybe deprecating 6to4 could be used and a pilot project 
for deprecating 6rd.  However, we are still probably a little early to 
be talking about the endgame for either of these transition solutions.

It is important to note, that since 6to4 uses a clearly defined prefix 
it should be possible to deprecate 6to4 when that time comes. I think 
all we are saying is that as a community we want that option for 6rd too.

> - Mark
>
>> Owen

So, I support a designated prefix for transition allocations.  Not 
because I believe it is clear that 6rd or other transition allocations 
must be deprecated in the future, but because I'm not sure they won't 
need to be deprecated.   Without a designated prefix it will be 
virtually impossible to deprecate them in future, if community were to 
desire to do that in the future.

-- 
===============================================
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 owen at delong.com  Wed Oct 13 18:51:51 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 13 Oct 2010 15:51:51 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <20101013220758.GA27979@ussenterprise.ufp.org>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<20101013165959.GB3056@ussenterprise.ufp.org>
	<CF727814-54AF-439B-83E6-541E2F32D92A@delong.com>
	<20101013220758.GA27979@ussenterprise.ufp.org>
Message-ID: <40A9E942-9F0D-4B50-AC82-DE9E2F3D567C@delong.com>


On Oct 13, 2010, at 3:07 PM, Leo Bicknell wrote:

> In a message written on Wed, Oct 13, 2010 at 02:45:54PM -0700, Owen DeLong wrote:
>> More likely it provides the lasting impression that /64s are the normal
>> subscriber allocation and breaks significant possible innovation.
>> My complaint about /56s was that they are too small, not that they
>> are too large.
> 
> Let's be honest here, in broad strokes, at least in the US...
> 
> Cable and FTTH providers are on a track to do native dual stack,
> and will likely be doing /48's although a few may opt for /56's.
> 
Actually, most of the PON (FTTH) systems are also caught with their
pants down.

> DSL providers, and their vendors, have been caught with their pants
> down with respect to doing dual-stack and are looking hard at 6rd
> as a bridge deployment until they can either migrate users to FTTH
> or deploy dual stack capable DSL equipment.
> 
This applies to DSL and FTTH. It also applies to some of the CMTS
systems that are still running on DOCSIS 2.

> Given most areas have a cable plus DSL duopoly if the DSL folks
> have to deploy /64's because that's all the mess we can make with
> the address space they will be at a competitive disadvantage compared
> to the cable providers handing out /48's (or maybe /56's).
> 
There are actually a lot of areas where the duopoly isn't like that.
Many areas are DSL vs. DSL or Cable vs. Satellite (also afflicted
with vertically challenged pants syndrome).

>> I say we swallow hard and let 6rd eat something approaching a /12
>> of /24s handed out to providers to facilitate /56s. Hopefully the fact that
>> /56 is not /48 will eventually lead to the deprecation of 6rd in favor of
>> native IPv6, but, at least we aren't completely breaking end user
>> innovations in favor of unnecessary address conservation.
> 
> If you're going to go that big, then why not go the whole way?  A
> /16 will allow a provider to do 32 bits of 6rd and still give out
> /48's.  Let's craft the policy so you must be turning up at least,
> oh, 100,000 subs using this technology.  I think we're now down to
> perhaps 10-20 ISP's in the US that can meet that bar and want to
> deploy 6rd, they can do it right, and we'll probably burn less than
> a /12.
> 
1.	There are lots of providers serving less than 100,000 subs
	that need 6rd and I wouldn't advocate policy that freezes
	them out.

2.	There aren't enough /16s to provide them to all the providers
	that likely need 6rd without serious risk to the address space.


> But I have to say, we're in scary land.  For all the IPv6 has lots of
> numbers arguments a /16 is only 65536 netblocks.  If we do this for the
> top 10-20 providers in every country in the world we're talking about
> using up 10-20% of the entire IPv6 space just for ONE transition
> technology.  
> 
Exactly. Very scary. Hence my recommendation that we limit it
to /24s rather than /16s. 


> The only way I can support any of this is if we have strong controls to
> make it temporary, but the more folks we turn up on it the more pressure
> there is going to be that it not be temporary, or at least that
> temporary is a very long time.
> 
I think that if we make it easy to get additional space for native IPv6,
the costs of running 6rd vs. the costs of native where it is possible
will provide reasonably good incentive to go native as quickly as
practicable.

Use of a reserved prefix so that the community can make a subsequent
decision to start filtering it at the borders will also help ensure the
temporary nature of such allocations.

> The best way to make temporary be really temporary is to make sure
> it is more painful than the alternatives.  While I want to put 6rd
> in the hands of the folks who need it (especially large DSL providers
> with millions of subscribers) I want to make it painful for them
> at every step.  Smaller subnets than their competitors, justify it
> to ARIN every 3 months, pay 10x the fees, etc.  We must use EVERY tool
> at our disposal to make this odious, while staying within the bounds of
> it being useful.
> 
I think the nature of 6rd does that pretty well.

I can't advocate the ultra small subnets. That punishes the end users
for the mistakes of the provider's vendors. I can't advocate huge fees,
either since that also would unfairly penalize the end-user for mistakes
well outside of their control.

>> Noone should WANT to deploy 6rd. It's one of those things that we
>> swallow hard, hold our noses, and deploy as a hot-fix until our
>> vendors catch up and provide working IPv6 last mile technologies.
> 
> I agree, but quite frankly, and this is very much opionion, we're
> bailing out the folks who were asleep at the switch.  Cable Labs figured
> out how to do IPv6 over Cable in plenty of time, and while folks have
> not deployed as fast as I would like the gear is there, it works, and is
> being deployed.  For some reason the DSL folks, vendors and customers,
> stuck their head in the sand and lost a number of years here where they
> could have been deploying better stuff.  I am lothe to reward that
> behavior.
> 
While that's true, I think we have to provide the bail-out. Penalizing
the end-user for the mistakes made primarily by their provider's
vendors is bad policy in my opinion. I'd love to see a way to
penalize the vendors in question, and, if you have one, I'm all
ears.

FWIW, we're also bailing out a number of cable providers that
have not yet upgraded to DOCSIS 3 and will be using this
over DICSIS 2 as well.

>> The pulling of support won't come in the form of an ARIN decision,
>> it will come in the form of providers deciding to filter the prefixes
>> that were dedicated to 6rd.
> 
> True, but a lot more people will be likely to filter if ARIN says
> "experiment over".  I realze the real work is feet on the street, but I
> think this is a critical symbolic step.
> 
I would support doing so based on a community consensus to
adopt policy deprecating the transitional provisions of this policy.
I don't think we should put a date on it now. I think we should
develop a community consensus at the appropriate time.

>> ARIN demand for return is pretty irrelevant to the equation.
> 
> I disagree strongly.  There will be folks tempted to keep their
> customers in the 6rd space so they don't have to renumber.  We've
> already seen presentations on native + 6rd hosts from the same block in
> Atlanta.  To allow that will create incredably sparely allocated blocks,
> and further reward the folks who failed to plan with gigantic blocks
> they will never use.  I don't know how that will bite us in the
> future, but it will.
> 
I think the policy we put forward addresses this.

> If we're going to allocate new blocks specifically for transition
> technologies they need to come back to ARIN.
> 
Agreed.

Owen



From tedm at ipinc.net  Wed Oct 13 18:55:05 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 13 Oct 2010 15:55:05 -0700
Subject: [arin-ppml] Advisory Council Meeting Results - October 2010
In-Reply-To: <C8DB8FC9.13225%marty@akamai.com>
References: <C8DB8FC9.13225%marty@akamai.com>
Message-ID: <4CB638C9.1050602@ipinc.net>

On 10/13/2010 1:33 PM, Hannigan, Martin wrote:
>
>
>
> On 10/13/10 3:36 PM, "Sweeting, John"<john.sweeting at twcable.com>  wrote:
>
>> Marty,
>>
>> Thanks for the opportunity to respond:
>>
>> The main issue is that the official label for those addresses is legacy
>> addresses but not all legacy addresses are wrapped up in that particular
>> issue. Since we became aware that the issue surrounding these particular
>> addresses should/would/will be cleared up in the next 10 days or so and given
>> the struggle that we had trying to find language that would work we decided as
>> a body to table the motion to send it to last call. This will be dealt with on
>> our very next AC call which is scheduled for November 18th.
>
>
> John,
>
> I'm not challenging anything other than the fact that the AC opted to table
> something that they had strong direction to work on. It's fair for us to ask
> for the AC to legitimize a decision especially when there is clear
> consensus.
>
> With regards to the global proposal, you both (Bill and you) have now said
> that Geoff's hypothetical issues will be moot in a few days. This proposal
> is nowhere near adoption or implementation and won't be within ten days. It
> will likely take six months or more if it is even adopted globally. I think
> that issue is a non-issue unless there's something that don't know that
> didn't come out in the list or meeting discussion.
>
> That leaves Owens reading of some language which had identified as unclear
> and we asserted that he was in error. Still, we suggested some text to
> clarify and since it's only an edit related to clarity and not context it
> could also be easily dealt with by the ASO AC at the end of the cycle and in
> compliance with their PDP as well as all of the other regions.
>
> This proposal is on the agenda of three other RIR forums at the moment.
> LACNIC next week, Rome after that and AfriNIC following that. Making a major
> modification at this point is a problem as was demonstrated with 2009-06,
> and holding it up for a non context impacting clarity concern doesn't seem
> reasonable all considered.
>

I have to disagree.  Another month isn't going to harm a good proposal.

When I first proposed the WHOIS POC e-mail cleanup in Aug 2008 that 
eventually morphed into section 3.6.1 of the NRPM, it took almost a 
year, and the proposal was merged into two other subsequent proposals
that came out because of my proposal.  See:

http://lists.arin.net/pipermail/arin-ppml/2008-November/012721.html

linked under

https://www.arin.net/policy/proposals/2008_7.html

And even after it was adopted almost a year later in 2009 it
still took 6-8 months for it to even be implemented by ARIN
staff (and as far as we know it's still being implemented)

So I don't buy the idea that any one proposal is so all fired
important that it must be fast-tracked ONE MONTH.

Pushing to fast track it is an insult to everyone else who has
submitted proposals and patiently waited for the slow grind
of the ARIN bureaucracy even when it was DRIVING THEM INSANE!

My advice is sit back, relax and be reminded of the immortal words
of Douglas Adams:

"...Vogons are one of the most unpleasant races in the galaxy. Not 
actually evil, but bad-tempered, bureaucratic, officious and callous. 
They wouldn't even lift a finger to save their own grandmothers from the 
Ravenous Bugblatter Beast of Traal without orders signed in triplicate, 
sent in, sent back, queried, lost, found, subjected to public inquiry, 
lost again, and finally buried in soft peat for three months and 
recycled as firelighters...."

Once you understand that the policy process is run by Vogons it
will all become clear!!!   ;-)

Ted


From bill at herrin.us  Wed Oct 13 18:56:25 2010
From: bill at herrin.us (William Herrin)
Date: Wed, 13 Oct 2010 18:56:25 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <20101013211843.93D1F5B0367@drugs.dv.isc.org>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<20101013211843.93D1F5B0367@drugs.dv.isc.org>
Message-ID: <AANLkTiknLC+oXF9QLTBGp=XrxGSgPRG8Rg-SJq-8MpSs@mail.gmail.com>

On Wed, Oct 13, 2010 at 5:18 PM, Mark Andrews <marka at isc.org> wrote:
> In message <2376C0DA-2491-40D4-B509-8C643C507A61 at delong.com>, Owen DeLong write
>> On Oct 12, 2010, at 8:55 PM, Mark Andrews wrote:
>> > If you have a 2 disjoint /16's spead over, multiple pops, then you
>> > will have 2 6rd prefixes in use both with a IPv4MaskLen of 16. ?Only
>> > one of these will be handed out to a specific customer. ?If you are
>> > handing out /56's then the 6rdPrefixLen would be 40. ?Each of these
>> > 6rd prefixes would be a /40.
>>
>> For the handful ?of providers that have only 2 prefixes, that may be.
>> For the vast majority of providers, the common practice (having more
>> than a couple of prefixes) is to map the entire IPV4 space onto
>> a customer prefix size (e.g. /56) yielding a need for a /24 (56-32)
>> prefix for the ISP. Since no ISP has a significant fraction of the
>> IPv4 space, much of that /24 is wasted.
>
> And doing what I suggests works for any number of prefixes.

Mark,

In theory, it works for any number of prefixes. So there's this old
joke I heard:

What's the difference between theory and practice?
In theory, there is no difference.

Preparing and maintaining the configuration for one 6rd prefix is easy
enough. Two is not so bad. But a hundred? I wouldn't want to be the
guy stuck with debugging that morass.

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  Wed Oct 13 19:00:47 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 13 Oct 2010 16:00:47 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <40A9E942-9F0D-4B50-AC82-DE9E2F3D567C@delong.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<20101013165959.GB3056@ussenterprise.ufp.org>
	<CF727814-54AF-439B-83E6-541E2F32D92A@delong.com>
	<20101013220758.GA27979@ussenterprise.ufp.org>
	<40A9E942-9F0D-4B50-AC82-DE9E2F3D567C@delong.com>
Message-ID: <AEF81606-AB13-4963-A2CC-C03BFA010151@delong.com>

Apologies to the list for responding to myself.

I will state for the record that my employer does not share
all of my views on this subject.

Owen

On Oct 13, 2010, at 3:51 PM, Owen DeLong wrote:

> 
> On Oct 13, 2010, at 3:07 PM, Leo Bicknell wrote:
> 
>> In a message written on Wed, Oct 13, 2010 at 02:45:54PM -0700, Owen DeLong wrote:
>>> More likely it provides the lasting impression that /64s are the normal
>>> subscriber allocation and breaks significant possible innovation.
>>> My complaint about /56s was that they are too small, not that they
>>> are too large.
>> 
>> Let's be honest here, in broad strokes, at least in the US...
>> 
>> Cable and FTTH providers are on a track to do native dual stack,
>> and will likely be doing /48's although a few may opt for /56's.
>> 
> Actually, most of the PON (FTTH) systems are also caught with their
> pants down.
> 
>> DSL providers, and their vendors, have been caught with their pants
>> down with respect to doing dual-stack and are looking hard at 6rd
>> as a bridge deployment until they can either migrate users to FTTH
>> or deploy dual stack capable DSL equipment.
>> 
> This applies to DSL and FTTH. It also applies to some of the CMTS
> systems that are still running on DOCSIS 2.
> 
>> Given most areas have a cable plus DSL duopoly if the DSL folks
>> have to deploy /64's because that's all the mess we can make with
>> the address space they will be at a competitive disadvantage compared
>> to the cable providers handing out /48's (or maybe /56's).
>> 
> There are actually a lot of areas where the duopoly isn't like that.
> Many areas are DSL vs. DSL or Cable vs. Satellite (also afflicted
> with vertically challenged pants syndrome).
> 
>>> I say we swallow hard and let 6rd eat something approaching a /12
>>> of /24s handed out to providers to facilitate /56s. Hopefully the fact that
>>> /56 is not /48 will eventually lead to the deprecation of 6rd in favor of
>>> native IPv6, but, at least we aren't completely breaking end user
>>> innovations in favor of unnecessary address conservation.
>> 
>> If you're going to go that big, then why not go the whole way?  A
>> /16 will allow a provider to do 32 bits of 6rd and still give out
>> /48's.  Let's craft the policy so you must be turning up at least,
>> oh, 100,000 subs using this technology.  I think we're now down to
>> perhaps 10-20 ISP's in the US that can meet that bar and want to
>> deploy 6rd, they can do it right, and we'll probably burn less than
>> a /12.
>> 
> 1.	There are lots of providers serving less than 100,000 subs
> 	that need 6rd and I wouldn't advocate policy that freezes
> 	them out.
> 
> 2.	There aren't enough /16s to provide them to all the providers
> 	that likely need 6rd without serious risk to the address space.
> 
> 
>> But I have to say, we're in scary land.  For all the IPv6 has lots of
>> numbers arguments a /16 is only 65536 netblocks.  If we do this for the
>> top 10-20 providers in every country in the world we're talking about
>> using up 10-20% of the entire IPv6 space just for ONE transition
>> technology.  
>> 
> Exactly. Very scary. Hence my recommendation that we limit it
> to /24s rather than /16s. 
> 
> 
>> The only way I can support any of this is if we have strong controls to
>> make it temporary, but the more folks we turn up on it the more pressure
>> there is going to be that it not be temporary, or at least that
>> temporary is a very long time.
>> 
> I think that if we make it easy to get additional space for native IPv6,
> the costs of running 6rd vs. the costs of native where it is possible
> will provide reasonably good incentive to go native as quickly as
> practicable.
> 
> Use of a reserved prefix so that the community can make a subsequent
> decision to start filtering it at the borders will also help ensure the
> temporary nature of such allocations.
> 
>> The best way to make temporary be really temporary is to make sure
>> it is more painful than the alternatives.  While I want to put 6rd
>> in the hands of the folks who need it (especially large DSL providers
>> with millions of subscribers) I want to make it painful for them
>> at every step.  Smaller subnets than their competitors, justify it
>> to ARIN every 3 months, pay 10x the fees, etc.  We must use EVERY tool
>> at our disposal to make this odious, while staying within the bounds of
>> it being useful.
>> 
> I think the nature of 6rd does that pretty well.
> 
> I can't advocate the ultra small subnets. That punishes the end users
> for the mistakes of the provider's vendors. I can't advocate huge fees,
> either since that also would unfairly penalize the end-user for mistakes
> well outside of their control.
> 
>>> Noone should WANT to deploy 6rd. It's one of those things that we
>>> swallow hard, hold our noses, and deploy as a hot-fix until our
>>> vendors catch up and provide working IPv6 last mile technologies.
>> 
>> I agree, but quite frankly, and this is very much opionion, we're
>> bailing out the folks who were asleep at the switch.  Cable Labs figured
>> out how to do IPv6 over Cable in plenty of time, and while folks have
>> not deployed as fast as I would like the gear is there, it works, and is
>> being deployed.  For some reason the DSL folks, vendors and customers,
>> stuck their head in the sand and lost a number of years here where they
>> could have been deploying better stuff.  I am lothe to reward that
>> behavior.
>> 
> While that's true, I think we have to provide the bail-out. Penalizing
> the end-user for the mistakes made primarily by their provider's
> vendors is bad policy in my opinion. I'd love to see a way to
> penalize the vendors in question, and, if you have one, I'm all
> ears.
> 
> FWIW, we're also bailing out a number of cable providers that
> have not yet upgraded to DOCSIS 3 and will be using this
> over DICSIS 2 as well.
> 
>>> The pulling of support won't come in the form of an ARIN decision,
>>> it will come in the form of providers deciding to filter the prefixes
>>> that were dedicated to 6rd.
>> 
>> True, but a lot more people will be likely to filter if ARIN says
>> "experiment over".  I realze the real work is feet on the street, but I
>> think this is a critical symbolic step.
>> 
> I would support doing so based on a community consensus to
> adopt policy deprecating the transitional provisions of this policy.
> I don't think we should put a date on it now. I think we should
> develop a community consensus at the appropriate time.
> 
>>> ARIN demand for return is pretty irrelevant to the equation.
>> 
>> I disagree strongly.  There will be folks tempted to keep their
>> customers in the 6rd space so they don't have to renumber.  We've
>> already seen presentations on native + 6rd hosts from the same block in
>> Atlanta.  To allow that will create incredably sparely allocated blocks,
>> and further reward the folks who failed to plan with gigantic blocks
>> they will never use.  I don't know how that will bite us in the
>> future, but it will.
>> 
> I think the policy we put forward addresses this.
> 
>> If we're going to allocate new blocks specifically for transition
>> technologies they need to come back to ARIN.
>> 
> Agreed.
> 
> 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 BillD at cait.wustl.edu  Wed Oct 13 19:25:43 2010
From: BillD at cait.wustl.edu (Bill Darte)
Date: Wed, 13 Oct 2010 18:25:43 -0500
Subject: [arin-ppml] Advisory Council Meeting Results - October 2010
References: <C8DB8FC9.13225%marty@akamai.com> <4CB638C9.1050602@ipinc.net>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D030879153EB@ex1.cait.wustl.edu>

It's the burying in peat part that I like best...
;-)

bd



-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Ted Mittelstaedt
Sent: Wed 10/13/2010 5:55 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Advisory Council Meeting Results - October 2010
 
On 10/13/2010 1:33 PM, Hannigan, Martin wrote:
>
>
>
> On 10/13/10 3:36 PM, "Sweeting, John"<john.sweeting at twcable.com>  wrote:
>
>> Marty,
>>
>> Thanks for the opportunity to respond:
>>
>> The main issue is that the official label for those addresses is legacy
>> addresses but not all legacy addresses are wrapped up in that particular
>> issue. Since we became aware that the issue surrounding these particular
>> addresses should/would/will be cleared up in the next 10 days or so and given
>> the struggle that we had trying to find language that would work we decided as
>> a body to table the motion to send it to last call. This will be dealt with on
>> our very next AC call which is scheduled for November 18th.
>
>
> John,
>
> I'm not challenging anything other than the fact that the AC opted to table
> something that they had strong direction to work on. It's fair for us to ask
> for the AC to legitimize a decision especially when there is clear
> consensus.
>
> With regards to the global proposal, you both (Bill and you) have now said
> that Geoff's hypothetical issues will be moot in a few days. This proposal
> is nowhere near adoption or implementation and won't be within ten days. It
> will likely take six months or more if it is even adopted globally. I think
> that issue is a non-issue unless there's something that don't know that
> didn't come out in the list or meeting discussion.
>
> That leaves Owens reading of some language which had identified as unclear
> and we asserted that he was in error. Still, we suggested some text to
> clarify and since it's only an edit related to clarity and not context it
> could also be easily dealt with by the ASO AC at the end of the cycle and in
> compliance with their PDP as well as all of the other regions.
>
> This proposal is on the agenda of three other RIR forums at the moment.
> LACNIC next week, Rome after that and AfriNIC following that. Making a major
> modification at this point is a problem as was demonstrated with 2009-06,
> and holding it up for a non context impacting clarity concern doesn't seem
> reasonable all considered.
>

I have to disagree.  Another month isn't going to harm a good proposal.

When I first proposed the WHOIS POC e-mail cleanup in Aug 2008 that 
eventually morphed into section 3.6.1 of the NRPM, it took almost a 
year, and the proposal was merged into two other subsequent proposals
that came out because of my proposal.  See:

http://lists.arin.net/pipermail/arin-ppml/2008-November/012721.html

linked under

https://www.arin.net/policy/proposals/2008_7.html

And even after it was adopted almost a year later in 2009 it
still took 6-8 months for it to even be implemented by ARIN
staff (and as far as we know it's still being implemented)

So I don't buy the idea that any one proposal is so all fired
important that it must be fast-tracked ONE MONTH.

Pushing to fast track it is an insult to everyone else who has
submitted proposals and patiently waited for the slow grind
of the ARIN bureaucracy even when it was DRIVING THEM INSANE!

My advice is sit back, relax and be reminded of the immortal words
of Douglas Adams:

"...Vogons are one of the most unpleasant races in the galaxy. Not 
actually evil, but bad-tempered, bureaucratic, officious and callous. 
They wouldn't even lift a finger to save their own grandmothers from the 
Ravenous Bugblatter Beast of Traal without orders signed in triplicate, 
sent in, sent back, queried, lost, found, subjected to public inquiry, 
lost again, and finally buried in soft peat for three months and 
recycled as firelighters...."

Once you understand that the policy process is run by Vogons it
will all become clear!!!   ;-)

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.

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

From marka at isc.org  Wed Oct 13 19:25:03 2010
From: marka at isc.org (Mark Andrews)
Date: Thu, 14 Oct 2010 10:25:03 +1100
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: Your message of "Wed, 13 Oct 2010 18:56:25 EDT."
	<AANLkTiknLC+oXF9QLTBGp=XrxGSgPRG8Rg-SJq-8MpSs@mail.gmail.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<20101013211843.93D1F5B0367@drugs.dv.isc.org><AANLkTiknLC+oXF9QLTBGp=XrxGSgPRG8Rg-SJq-8MpSs@mail.gmail.com>
Message-ID: <20101013232503.E70B05B1A60@drugs.dv.isc.org>


In message <AANLkTiknLC+oXF9QLTBGp=XrxGSgPRG8Rg-SJq-8MpSs at mail.gmail.com>, Will
iam Herrin writes:
> On Wed, Oct 13, 2010 at 5:18 PM, Mark Andrews <marka at isc.org> wrote:
> > In message <2376C0DA-2491-40D4-B509-8C643C507A61 at delong.com>, Owen DeLong=
>  write
> >> On Oct 12, 2010, at 8:55 PM, Mark Andrews wrote:
> >> > If you have a 2 disjoint /16's spead over, multiple pops, then you
> >> > will have 2 6rd prefixes in use both with a IPv4MaskLen of 16. =A0Only
> >> > one of these will be handed out to a specific customer. =A0If you are
> >> > handing out /56's then the 6rdPrefixLen would be 40. =A0Each of these
> >> > 6rd prefixes would be a /40.
> >>
> >> For the handful =A0of providers that have only 2 prefixes, that may be.
> >> For the vast majority of providers, the common practice (having more
> >> than a couple of prefixes) is to map the entire IPV4 space onto
> >> a customer prefix size (e.g. /56) yielding a need for a /24 (56-32)
> >> prefix for the ISP. Since no ISP has a significant fraction of the
> >> IPv4 space, much of that /24 is wasted.
> >
> > And doing what I suggests works for any number of prefixes.
> 
> Mark,
> 
> In theory, it works for any number of prefixes. So there's this old
> joke I heard:
> 
> What's the difference between theory and practice?
> In theory, there is no difference.
> 
> Preparing and maintaining the configuration for one 6rd prefix is easy
> enough. Two is not so bad. But a hundred? I wouldn't want to be the
> guy stuck with debugging that morass.
> 
> Regards,
> Bill Herrin

Well it can be the same 6rd prefix table into every border router.
The only time one would need to have a different 6rd prefix table
is if the border routeirs didn't support the number of 6rd prefixes
in the table.

Remember you only update the table when you get a new IPv4 prefix
or you get rid of a IPv4 prefix.  The table does not need to change
as you move address blocks around internally.

This way any border router can handle any client's traffic.  As to
which router handles which clients traffic is then up to which IPv6
routes it announces for enacapsulation or it could just be on the
ingress paths.  The decapsulation depends on the addresses in the
DHCPv4 6rd option/web page.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From marka at isc.org  Wed Oct 13 19:47:56 2010
From: marka at isc.org (Mark Andrews)
Date: Thu, 14 Oct 2010 10:47:56 +1100
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: Your message of "Thu, 14 Oct 2010 10:25:03 +1100."
	<20101013232503.E70B05B1A60@drugs.dv.isc.org>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<20101013211843.93D1F5B0367@drugs.dv.isc.org><AANLkTiknLC+oXF9QLTBGp=XrxGSgPRG8Rg-SJq-8MpSs@mail.gmail.com><20101013232503.E70B05B1A60@drugs.dv.isc.org>
Message-ID: <20101013234756.505B95B1B3C@drugs.dv.isc.org>


In message <20101013232503.E70B05B1A60 at drugs.dv.isc.org>, Mark Andrews writes:
> 
> In message <AANLkTiknLC+oXF9QLTBGp=XrxGSgPRG8Rg-SJq-8MpSs at mail.gmail.com>, Wi
> ll
> iam Herrin writes:
> > Mark,
> > 
> > In theory, it works for any number of prefixes. So there's this old
> > joke I heard:
> > 
> > What's the difference between theory and practice?
> > In theory, there is no difference.
> > 
> > Preparing and maintaining the configuration for one 6rd prefix is easy
> > enough. Two is not so bad. But a hundred? I wouldn't want to be the
> > guy stuck with debugging that morass.

ISP's allocate address blocks to 1000's of commercial clients.
Finding a new 6rd prefix for a new IPv4 allocation is no harder
that finding a address block for a commercial client.  In fact it
is easier as you can (but it would not be desirable) create multiple
prefixes if you find there is not a existing block that is big
enough.

If ISP's can support 1000's of commercial client address blockss
they can support 100's of 6rd prefixes.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From bill at herrin.us  Wed Oct 13 19:59:47 2010
From: bill at herrin.us (William Herrin)
Date: Wed, 13 Oct 2010 19:59:47 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <20101013234756.505B95B1B3C@drugs.dv.isc.org>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<20101013211843.93D1F5B0367@drugs.dv.isc.org>
	<AANLkTiknLC+oXF9QLTBGp=XrxGSgPRG8Rg-SJq-8MpSs@mail.gmail.com>
	<20101013232503.E70B05B1A60@drugs.dv.isc.org>
	<20101013234756.505B95B1B3C@drugs.dv.isc.org>
Message-ID: <AANLkTi=obst=A-mt35+gKTvpgRgLfCxjWm1izBbOihXc@mail.gmail.com>

On Wed, Oct 13, 2010 at 7:47 PM, Mark Andrews <marka at isc.org> wrote:
> In message <20101013232503.E70B05B1A60 at drugs.dv.isc.org>, Mark Andrews writes:
>> In message <AANLkTiknLC+oXF9QLTBGp=XrxGSgPRG8Rg-SJq-8MpSs at mail.gmail.com>, Wi
>> > Preparing and maintaining the configuration for one 6rd prefix is easy
>> > enough. Two is not so bad. But a hundred? I wouldn't want to be the
>> > guy stuck with debugging that morass.
>
> ISP's allocate address blocks to 1000's of commercial clients.
> Finding a new 6rd prefix for a new IPv4 allocation is no harder
> that finding a address block for a commercial client. ?In fact it
> is easier as you can (but it would not be desirable) create multiple
> prefixes if you find there is not a existing block that is big
> enough.
>
> If ISP's can support 1000's of commercial client address blockss
> they can support 100's of 6rd prefixes.

Go build me a distribution protocol so I can configure the 6rd
translations in just one place (like I do for routes) and expect them
to dynamically propagate to all of my v6/v4 borders. Then we'll talk
about equivalence of effort.

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 bicknell at ufp.org  Wed Oct 13 20:20:15 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 13 Oct 2010 17:20:15 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <40A9E942-9F0D-4B50-AC82-DE9E2F3D567C@delong.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<20101013165959.GB3056@ussenterprise.ufp.org>
	<CF727814-54AF-439B-83E6-541E2F32D92A@delong.com>
	<20101013220758.GA27979@ussenterprise.ufp.org>
	<40A9E942-9F0D-4B50-AC82-DE9E2F3D567C@delong.com>
Message-ID: <20101014002014.GA34976@ussenterprise.ufp.org>

In a message written on Wed, Oct 13, 2010 at 03:51:51PM -0700, Owen DeLong wrote:
> This applies to DSL and FTTH. It also applies to some of the CMTS
> systems that are still running on DOCSIS 2.

I want to take a technology diversion here, because I think it's
critical to the magnitude of the problem we are talking about.

If you're a DOCSIS 2 cable provider, you can:

   a. Deploy a DOCSIS 3 head end, which is widely available,
      and deploy new DOCSIS 3 CPE, which is widely available.
      The head end upgrade also gives you increased capabilities in
      other areas.
   b. Deploy a 6rd "head end" system in your core network, and
      deploy new CPE, either a new modem that speaks DOCSIS 2/3 + 6rd,
      or worse an additional box behind the current modem.

I'm having a hard time why anyone would ever pick b.  Similar
level of effort for less capabilities going forward.

I can't speak to FTTH in detail, don't know enough about it.  My
limited understanding was the head ends were native v6 capable
today, the issue was all CPE, and that much of the current CPE
worked in briding mode.  Of course that's not the preferred deployment
model, they usually deploy in router mode, but it's still an all
CPE problem.  Again, if it's new CPE that does native, vrs new CPE that
does 6rd, why would 6rd even be considered?

You would think DSL providers would be in a similar situation to the
DOCSIS 2 cable providers above, but they are not, due to two fundamental
differences.

  1. IPv6 standards came late to DSL.  My understanding is the first
     standards based DSL gear was demonstrated in the field at the end
     of 2009, years after cable.  What's more, not all DSL vendors have
     IPv6 across their product line yet, so if you have particular
     chassis you may not be able to buy the gear at all.  I even believe
     there are some chassis that cannot be upgraded, so it is a
     forklift.
  2. DSL has a one-to-one port mapping.  Unlike cable where upgrading
     a single head end CMTS might enable hundreds or thousands of users
     in DSL each line upgraded must be upgraded on both the head end and
     customer end.  Thus there is an order of magnitude more head end
     ports to upgrade, and with the gear not yet, or just now becoming
     available even if they wanted to deploy it manpower and
     maufacturing capacity are real issues.

If I have any of this wrong, I'd love more details from folks in the
know.  It goes directly to two important issues, the order of magnitude
of how many folks will request space under this plan, and also how
temporary the space will be used.  If it really is that much cheaper to
deploy 6rd than upgrading a DOCSIS 2 cable plant to DOCSIS 3 that tells
me this is going to stick around for a very long time for cost reasons.

> I can't advocate the ultra small subnets. That punishes the end users
> for the mistakes of the provider's vendors. I can't advocate huge fees,
> either since that also would unfairly penalize the end-user for mistakes
> well outside of their control.

If the customers had no choice I would go with the word punish.
I'm going to assume most customers have alternatives (and yes, I
realize most there is a percentage even I have trouble calling
most), and thus it gives them an incentive to find real connectivity.
We're likely not to agree on this point though...

> While that's true, I think we have to provide the bail-out. Penalizing
> the end-user for the mistakes made primarily by their provider's
> vendors is bad policy in my opinion. I'd love to see a way to
> penalize the vendors in question, and, if you have one, I'm all
> ears.

This probably won't fly as policy, but, let me give it a shot. :)

   Any address space provided by ARIN for 6rd will not be issued
   until the recipient delivers one engineer and one executive from
   the provider of the majority of their non-IPv6 capable equipment
   to an ARIN public policy meeting to receive a public flogging.
   The recipient must provide baseball bats for all policy meeting
   attendees.

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

From marka at isc.org  Wed Oct 13 20:31:17 2010
From: marka at isc.org (Mark Andrews)
Date: Thu, 14 Oct 2010 11:31:17 +1100
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: Your message of "Wed, 13 Oct 2010 19:59:47 EDT."
	<AANLkTi=obst=A-mt35+gKTvpgRgLfCxjWm1izBbOihXc@mail.gmail.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<20101013211843.93D1F5B0367@drugs.dv.isc.org>
	<AANLkTiknLC+oXF9QLTBGp=XrxGSgPRG8Rg-SJq-8MpSs@mail.gmail.com>
	<20101013232503.E70B05B1A60@drugs.dv.isc.org>
	<20101013234756.505B95B1B3C@drugs.dv.isc.org>
	<AANLkTi=obst=A-mt35+gKTvpgRgLfCxjWm1izBbOihXc@mail.gmail.com>
Message-ID: <20101014003118.06CAA5B2714@drugs.dv.isc.org>


In message <AANLkTi=obst=A-mt35+gKTvpgRgLfCxjWm1izBbOihXc at mail.gmail.com>, Will
iam Herrin writes:
> On Wed, Oct 13, 2010 at 7:47 PM, Mark Andrews <marka at isc.org> wrote:
> > In message <20101013232503.E70B05B1A60 at drugs.dv.isc.org>, Mark Andrews wr=
> ites:
> >> In message <AANLkTiknLC+oXF9QLTBGp=3DXrxGSgPRG8Rg-SJq-8MpSs at mail.gmail.c=
> om>, Wi
> >> > Preparing and maintaining the configuration for one 6rd prefix is easy
> >> > enough. Two is not so bad. But a hundred? I wouldn't want to be the
> >> > guy stuck with debugging that morass.
> >
> > ISP's allocate address blocks to 1000's of commercial clients.
> > Finding a new 6rd prefix for a new IPv4 allocation is no harder
> > that finding a address block for a commercial client. =A0In fact it
> > is easier as you can (but it would not be desirable) create multiple
> > prefixes if you find there is not a existing block that is big
> > enough.
> >
> > If ISP's can support 1000's of commercial client address blockss
> > they can support 100's of 6rd prefixes.
> 
> Go build me a distribution protocol so I can configure the 6rd
> translations in just one place (like I do for routes) and expect them
> to dynamically propagate to all of my v6/v4 borders. Then we'll talk
> about equivalence of effort.
> 
> Regards,
> Bill Herrin

I could design it in about 10 minutes as could just about anyone
on this list.

telnet 6rd-prefix-server 6rd-prefix-port | import-6rd-table

Prefix count <4 octets>.
6rdPrefix (16 octets) | IPv4MaskLen (1 octet) | 6rdPrefixLen (1 octet)
...

Done.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From marka at isc.org  Wed Oct 13 20:37:29 2010
From: marka at isc.org (Mark Andrews)
Date: Thu, 14 Oct 2010 11:37:29 +1100
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: Your message of "Thu, 14 Oct 2010 11:31:17 +1100."
Message-ID: <20101014003729.591485B276F@drugs.dv.isc.org>


Mark Andrews writes:
> 
> In message <AANLkTi=obst=A-mt35+gKTvpgRgLfCxjWm1izBbOihXc at mail.gmail.com>, Wi
> ll
> iam Herrin writes:
> > On Wed, Oct 13, 2010 at 7:47 PM, Mark Andrews <marka at isc.org> wrote:
> > > In message <20101013232503.E70B05B1A60 at drugs.dv.isc.org>, Mark Andrews wr
> =
> > ites:
> > >> In message <AANLkTiknLC+oXF9QLTBGp=3DXrxGSgPRG8Rg-SJq-8MpSs at mail.gmail.c
> =
> > om>, Wi
> > >> > Preparing and maintaining the configuration for one 6rd prefix is easy
> > >> > enough. Two is not so bad. But a hundred? I wouldn't want to be the
> > >> > guy stuck with debugging that morass.
> > >
> > > ISP's allocate address blocks to 1000's of commercial clients.
> > > Finding a new 6rd prefix for a new IPv4 allocation is no harder
> > > that finding a address block for a commercial client. =A0In fact it
> > > is easier as you can (but it would not be desirable) create multiple
> > > prefixes if you find there is not a existing block that is big
> > > enough.
> > >
> > > If ISP's can support 1000's of commercial client address blockss
> > > they can support 100's of 6rd prefixes.
> > 
> > Go build me a distribution protocol so I can configure the 6rd
> > translations in just one place (like I do for routes) and expect them
> > to dynamically propagate to all of my v6/v4 borders. Then we'll talk
> > about equivalence of effort.
> > 
> > Regards,
> > Bill Herrin
> 
> I could design it in about 10 minutes as could just about anyone
> on this list.
> 
> telnet 6rd-prefix-server 6rd-prefix-port | import-6rd-table
> 
> Prefix count <4 octets>.
> 6rdPrefix (16 octets) | IPv4MaskLen (1 octet) | 6rdPrefixLen (1 octet)
> ...

Woops it needs one more field.

6rdPrefix (16 octets) | IPv4 Prefix (4 octets) | IPv4MaskLen (1 octet) | 6rdPrefixLen (1 octet)

No need to make these variable length fields though they could be.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From bill at herrin.us  Wed Oct 13 20:48:27 2010
From: bill at herrin.us (William Herrin)
Date: Wed, 13 Oct 2010 20:48:27 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <20101014003118.06CAA5B2714@drugs.dv.isc.org>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<20101013211843.93D1F5B0367@drugs.dv.isc.org>
	<AANLkTiknLC+oXF9QLTBGp=XrxGSgPRG8Rg-SJq-8MpSs@mail.gmail.com>
	<20101013232503.E70B05B1A60@drugs.dv.isc.org>
	<20101013234756.505B95B1B3C@drugs.dv.isc.org>
	<AANLkTi=obst=A-mt35+gKTvpgRgLfCxjWm1izBbOihXc@mail.gmail.com>
	<20101014003118.06CAA5B2714@drugs.dv.isc.org>
Message-ID: <AANLkTim5cKtxyu211p2st0gC+E94DxukXG4FusqDLe21@mail.gmail.com>

On Wed, Oct 13, 2010 at 8:31 PM, Mark Andrews <marka at isc.org> wrote:
> In message <AANLkTi=obst=A-mt35+gKTvpgRgLfCxjWm1izBbOihXc at mail.gmail.com>, Will
> iam Herrin writes:
>> Go build me a distribution protocol so I can configure the 6rd
>> translations in just one place (like I do for routes) and expect them
>> to dynamically propagate to all of my v6/v4 borders. Then we'll talk
>> about equivalence of effort.
>
> I could design it in about 10 minutes as could just about anyone
> on this list.
>
> telnet 6rd-prefix-server 6rd-prefix-port | import-6rd-table
>
> Prefix count <4 octets>.
> 6rdPrefix (16 octets) | IPv4MaskLen (1 octet) | 6rdPrefixLen (1 octet)

Mark,

Telnet? Seriously? I had planned to respond to the set-up with "ssh to
the cli is a very bad distribution protocol," but telnet? I see you're
from ISC so you must be a smart guy, but what rock have you been
living under?

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  Wed Oct 13 20:45:17 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 13 Oct 2010 17:45:17 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <20101014002014.GA34976@ussenterprise.ufp.org>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<20101013165959.GB3056@ussenterprise.ufp.org>
	<CF727814-54AF-439B-83E6-541E2F32D92A@delong.com>
	<20101013220758.GA27979@ussenterprise.ufp.org>
	<40A9E942-9F0D-4B50-AC82-DE9E2F3D567C@delong.com>
	<20101014002014.GA34976@ussenterprise.ufp.org>
Message-ID: <8C640354-D408-4172-8DA1-6272068308F5@delong.com>


On Oct 13, 2010, at 5:20 PM, Leo Bicknell wrote:

> In a message written on Wed, Oct 13, 2010 at 03:51:51PM -0700, Owen DeLong wrote:
>> This applies to DSL and FTTH. It also applies to some of the CMTS
>> systems that are still running on DOCSIS 2.
> 
> I want to take a technology diversion here, because I think it's
> critical to the magnitude of the problem we are talking about.
> 
> If you're a DOCSIS 2 cable provider, you can:
> 
>   a. Deploy a DOCSIS 3 head end, which is widely available,
>      and deploy new DOCSIS 3 CPE, which is widely available.
>      The head end upgrade also gives you increased capabilities in
>      other areas.
>   b. Deploy a 6rd "head end" system in your core network, and
>      deploy new CPE, either a new modem that speaks DOCSIS 2/3 + 6rd,
>      or worse an additional box behind the current modem.
> 
> I'm having a hard time why anyone would ever pick b.  Similar
> level of effort for less capabilities going forward.
> 
It is actually slightly less effort, and, it depends on who you buy your
CMTS from. If you have some form of vendor lockin, a couple of
the vendors aren't quite there yet with DOCSIS 3.

TTBOMK, the ones doing b are deploying CPE that is DOCSIS2/3+6rd.

> I can't speak to FTTH in detail, don't know enough about it.  My
> limited understanding was the head ends were native v6 capable
> today, the issue was all CPE, and that much of the current CPE
> worked in briding mode.  Of course that's not the preferred deployment
> model, they usually deploy in router mode, but it's still an all
> CPE problem.  Again, if it's new CPE that does native, vrs new CPE that
> does 6rd, why would 6rd even be considered?
> 
That depends.. Some of them have native IPv6, but, in forms that
are apparently not the way ISPs want to deploy it. I don't understand
all the details completely either, but, the ISPs actually deploying it
that came up to talk to me convinced me they had a real problem.

> You would think DSL providers would be in a similar situation to the
> DOCSIS 2 cable providers above, but they are not, due to two fundamental
> differences.
> 
>  1. IPv6 standards came late to DSL.  My understanding is the first
>     standards based DSL gear was demonstrated in the field at the end
>     of 2009, years after cable.  What's more, not all DSL vendors have
>     IPv6 across their product line yet, so if you have particular
>     chassis you may not be able to buy the gear at all.  I even believe
>     there are some chassis that cannot be upgraded, so it is a
>     forklift.

In fact, no DSL vendor has IPv6 on their product line in a manner that
matches the IPOE deployments that providers are going to.

>  2. DSL has a one-to-one port mapping.  Unlike cable where upgrading
>     a single head end CMTS might enable hundreds or thousands of users
>     in DSL each line upgraded must be upgraded on both the head end and
>     customer end.  Thus there is an order of magnitude more head end
>     ports to upgrade, and with the gear not yet, or just now becoming
>     available even if they wanted to deploy it manpower and
>     maufacturing capacity are real issues.
> 
Yes and no... You can upgrade the DSLAM independent of the CPE
attached to it, but, you need to also upgrade the CPE to get benefit.

This is also true of CMTS.

> If I have any of this wrong, I'd love more details from folks in the
> know.  It goes directly to two important issues, the order of magnitude
> of how many folks will request space under this plan, and also how
> temporary the space will be used.  If it really is that much cheaper to
> deploy 6rd than upgrading a DOCSIS 2 cable plant to DOCSIS 3 that tells
> me this is going to stick around for a very long time for cost reasons.
> 
I figure plan on about 3,000 ISPs overall.

>> I can't advocate the ultra small subnets. That punishes the end users
>> for the mistakes of the provider's vendors. I can't advocate huge fees,
>> either since that also would unfairly penalize the end-user for mistakes
>> well outside of their control.
> 
> If the customers had no choice I would go with the word punish.
> I'm going to assume most customers have alternatives (and yes, I
> realize most there is a percentage even I have trouble calling
> most), and thus it gives them an incentive to find real connectivity.
> We're likely not to agree on this point though...
> 
Yep.. In fact, we thoroughly disagree. For example, the choice
in much of California, indeed, MOST of San Jose, the 3rd
largest population center in California boils down to a choice
between CMTS (admittedly DOCSIS 3) and ADSL2+ or less.
If you for any reason don't want to do business with Comcast,
or want a static IP address, then, your only choice is DSL.
If you want more than about 2Mbps, then, for most of San Jose,
your only choice is Comcast.

It's a lot bleaker in terms of consumer choice out there, even
for MOST consumers than you would like to think.

>> While that's true, I think we have to provide the bail-out. Penalizing
>> the end-user for the mistakes made primarily by their provider's
>> vendors is bad policy in my opinion. I'd love to see a way to
>> penalize the vendors in question, and, if you have one, I'm all
>> ears.
> 
> This probably won't fly as policy, but, let me give it a shot. :)
> 
>   Any address space provided by ARIN for 6rd will not be issued
>   until the recipient delivers one engineer and one executive from
>   the provider of the majority of their non-IPv6 capable equipment
>   to an ARIN public policy meeting to receive a public flogging.
>   The recipient must provide baseball bats for all policy meeting
>   attendees.
> 
I like it, but, I suspect you are right that it wouldn't fly as policy.

Owen

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

From marka at isc.org  Wed Oct 13 21:16:14 2010
From: marka at isc.org (Mark Andrews)
Date: Thu, 14 Oct 2010 12:16:14 +1100
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: Your message of "Wed, 13 Oct 2010 20:48:27 EDT."
	<AANLkTim5cKtxyu211p2st0gC+E94DxukXG4FusqDLe21@mail.gmail.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<20101013211843.93D1F5B0367@drugs.dv.isc.org>
	<AANLkTiknLC+oXF9QLTBGp=XrxGSgPRG8Rg-SJq-8MpSs@mail.gmail.com>
	<20101013232503.E70B05B1A60@drugs.dv.isc.org>
	<20101013234756.505B95B1B3C@drugs.dv.isc.org>
	<AANLkTi=obst=A-mt35+gKTvpgRgLfCxjWm1izBbOihXc@mail.gmail.com>
	<20101014003118.06CAA5B2714@drugs.dv.isc.org>
	<AANLkTim5cKtxyu211p2st0gC+E94DxukXG4FusqDLe21@mail.gmail.com>
Message-ID: <20101014011615.0AC0C5B2D98@drugs.dv.isc.org>


In message <AANLkTim5cKtxyu211p2st0gC+E94DxukXG4FusqDLe21 at mail.gmail.com>, Will
iam Herrin writes:
> On Wed, Oct 13, 2010 at 8:31 PM, Mark Andrews <marka at isc.org> wrote:
> > In message <AANLkTi=3Dobst=3DA-mt35+gKTvpgRgLfCxjWm1izBbOihXc at mail.gmail.=
> com>, Will
> > iam Herrin writes:
> >> Go build me a distribution protocol so I can configure the 6rd
> >> translations in just one place (like I do for routes) and expect them
> >> to dynamically propagate to all of my v6/v4 borders. Then we'll talk
> >> about equivalence of effort.
> >
> > I could design it in about 10 minutes as could just about anyone
> > on this list.
> >
> > telnet 6rd-prefix-server 6rd-prefix-port | import-6rd-table
> >
> > Prefix count <4 octets>.
> > 6rdPrefix (16 octets) | IPv4MaskLen (1 octet) | 6rdPrefixLen (1 octet)
> 
> Mark,
> 
> Telnet? Seriously? I had planned to respond to the set-up with "ssh to
> the cli is a very bad distribution protocol," but telnet? I see you're
> from ISC so you must be a smart guy, but what rock have you been
> living under?

Conceptually telnet is all that is needed.  There are lots of ways
to secure this.  If you need me to specify one then a client cert
and ssl would work.  Or you could use HMACMD5 with a shared key or
...  Ask your 6rd border vendor which method they would prefer.

You have the data payload and I'm quite sure that one could support
half a dozen different security wrappers on the distribution server.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From christopher.morrow at gmail.com  Thu Oct 14 00:01:06 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Thu, 14 Oct 2010 00:01:06 -0400
Subject: [arin-ppml] Draft Policy 2010-12: IPv6 Subsequent Allocation -
 Last Call (text revised)
In-Reply-To: <F28A2A7A-9452-49E4-BCF0-BBDB9C8F4556@delong.com>
References: <4CB5F5FD.7090806@arin.net>
	<F28A2A7A-9452-49E4-BCF0-BBDB9C8F4556@delong.com>
Message-ID: <AANLkTinjL06+NeEqX0MMxgNeZG7guDF+uWLS7baPjWy+@mail.gmail.com>

On Wed, Oct 13, 2010 at 5:54 PM, Owen DeLong <owen at delong.com> wrote:
> To clarify, the /24 maximum and the designated block apply ONLY
> to subsequent allocations for transitional purposes. Subsequent allocations
> for native IPv6 deployment are not restricted or encumbered in any way
> other than the standards set forth in existing policy.

That was the intent Dan and I had at the table in the meeting, and at
the AC meeting afterwards.

-chris
(adding agreement only)
> On Oct 13, 2010, at 11:10 AM, ARIN wrote:
>
>> The ARIN Advisory Council (AC) met on 8 October 2010 and decided to
>> send the following draft policy to last call:
>>
>> ? Draft Policy 2010-12: IPv6 Subsequent Allocation
>>
>> The AC made the following revisions to the text:
>> ?- /24 was added as the maximum prefix size.
>> ?- Allocations will be from a designated block.
>> ?- Requests for transition space will not be exempt from returns.
>>
>> Feedback is encouraged during the last call period. All comments should
>> be provided to the Public Policy Mailing List. Last call for 2010-12
>> will expire on 27 October 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,
>>
>> Communications and Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> ## * ##
>>
>>
>> Draft Policy 2010-12
>> IPv6 Subsequent Allocation
>>
>> Version/Date: 13 October 2010
>>
>> Policy statement:
>>
>> Modify 6.5.2.1 Subsequent allocation criteria. Add the following:
>>
>> Subsequent allocations will also be considered for deployments that
>> cannot be accommodated by, nor were accounted for, under the initial
>> allocation. Justification for the subsequent subnet size will be based
>> on the plan and technology provided with a /24 being the maximum allowed
>> for a transition technology. Justification for these allocations will be
>> reviewed every 3 years and reclaimed if it is not in use. All such
>> allocations for transitional technology will be made from a block
>> designated for this purpose.
>>
>> Rationale:
>>
>> Current organizations cannot get an allocation for a IPv6 transitional
>> technology if they have already received their initial allocation of
>> IPv6. The reason they cannot get an additional IPV6 allocation is
>> because they don't meet the HD ratio for a subsequent allocation and
>> they don't want to use their initial assignment because it is
>> insufficient, mapped out for other long term plans, or already has
>> portions in use.
>>
>> An alternative proposal to permit more allocations was submitted that
>> supported 6rd but since then community members have come forward with
>> concern that this should support not just one particular technology but
>> any that enable v6 deployment.
>>
>> Justification Example: Below is an example of how the details for a
>> technology and its subnet requirements could be provided as
>> justification. This example is based of 6rd.
>>
>> 6rd is intended to be an incremental method for deploying IPv6 and
>> bridge the gap for End Users to the IPv6 Internet. The method provides a
>> native dual-stack service to a subscriber site by leveraging existing
>> infrastructure. If an entity already has a /32 of IPv6 they can not use
>> the same /32 for native IPv6 as they do for the 6rd routing and a
>> separate minimum size of a /32 is required while a larger subnet like a
>> /28 may be needed based on a non-contiguous IPv4 addressing plan.
>>
>> The 6rd prefix is an RIR delegated IPv6 prefix. It must encapsulate an
>> IPv4 address and must be short enough so that a /56 or /60 can be given
>> to subscribers. This example shows how the 6rd prefix is created based
>> on a /32 IPv6 prefix using RFC1918 address space from 10.0.0.0/8:
>>
>> SP IPv6 prefix: 2001:0DB8::/32 v4suffix-length: 24 (from 10/8, first
>> octet (10) is excluded from the encoding) 6rd CE router IPv4 address:
>> 10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56
>>
>> This example shows how the 6rd prefix is created based on a /28 IPv6
>> prefix using one of several non-contiguous global address ranges:
>>
>> SP IPv6 prefix: 2001:0DB0::/28 v4suffix-length: 32 (unable to exclude
>> common bits due to non-contiguous IPv4 allocations) 6rd CE router IPv4
>> address: 192.0.2.1 6rd site IPv6 prefix: 2001:0DBC:0000:2010::/60
>>
>> Timetable for implementation: Immediate
>>
>>
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>


From christopher.morrow at gmail.com  Thu Oct 14 00:04:40 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Thu, 14 Oct 2010 00:04:40 -0400
Subject: [arin-ppml] Draft Policy 2010-12: IPv6 Subsequent Allocation -
 Last Call (text revised)
In-Reply-To: <AANLkTinGWK4nnxdcOKf=bmGdLG4dRYjncYcv9Wuh5dGB@mail.gmail.com>
References: <4CB5F5FD.7090806@arin.net>
	<F28A2A7A-9452-49E4-BCF0-BBDB9C8F4556@delong.com>
	<AANLkTinGWK4nnxdcOKf=bmGdLG4dRYjncYcv9Wuh5dGB@mail.gmail.com>
Message-ID: <AANLkTin99B472MsL1K7gu0yxHbggfpXcLCy66z=qm9yO@mail.gmail.com>

On Wed, Oct 13, 2010 at 6:19 PM, William Herrin <bill at herrin.us> wrote:
> On Wed, Oct 13, 2010 at 5:54 PM, Owen DeLong <owen at delong.com> wrote:
>> To clarify, the /24 maximum and the designated block apply ONLY
>> to subsequent allocations for transitional purposes. Subsequent allocations
>> for native IPv6 deployment are not restricted or encumbered in any way
>> other than the standards set forth in existing policy.
>
> Ah. In that case, I OPPOSE draft policy 2010-12 as written.
>
> I would support a revised version that applies the /24 limit to any
> subsequent allocation _for which the prior efficient utilization
> requirements have been waived_, regardless of whether its for
> transitional technologies.

hrm, I don't think the prior efficient utilization requirements were
waved. Just the need to show either:
o need to use a transition tech (and then get a block from a separate
set-aside block marked for this)
o need to show that the new deployment was somehow outside of the
original planned deployment(s).

the second part there is really for 'hey, we have to deploy this whole
new network over here, with v6... oops, our current /32 is
dedicated/allocated/appointed-for-use on our existing deployment...
which is just starting to roll out so we can't show 75% of the /48's
assigned, doh!'  sort of problems. (which I've seen in more than one
instance in the last 2 years... fyi).

-chris

>
> 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
> _______________________________________________
> 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 Oct 14 05:14:57 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 14 Oct 2010 10:14:57 +0100
Subject: [arin-ppml] Controlling the IPv6 address consumption rate
In-Reply-To: <7B65164A-EC15-44EF-809E-90DAE80FC100@delong.com>
References: <AANLkTik+5zsTzepnf40faZVgOxNF2OOeMt-3o4p2wLEw@mail.gmail.com>
	<2B6D8499-377A-40FF-8263-79C6A3BFD3AE@delong.com>
	<AANLkTikQqyg8508hSUbxM5gMp=_BSuf41jaRByztaGuh@mail.gmail.com>
	<7B65164A-EC15-44EF-809E-90DAE80FC100@delong.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423938133C97@EMV01-UKBR.domain1.systemhost.net>

> Conserving 4095/4096ths of the address space, well, that's getting
> ridiculous on its face. Especially in light of the need for ridiculous
> wastes of IPv6 like 6rd in order to get IPv6 deployed because the
> vendors of last mile technology managed to get caught with their pants
> down by an event that they had more than a decade of warning was
> coming.

Let's not forget that all of the 6RD allocations are intended to be
temporary so it is not really waste. In fact, it is a buffer pool of
addresses that is being conserved for future use after 6RD fades into
black and native IPv6 is everywhere. 


> served would get a /20 or in extreme cases, maybe a /16.

Maybe *A* /16. Look at the IPv4 world where the slash notation
refers to the same fraction of the total number space. A large
ISP would get many / 16 allocations every year.

> This would mean that we consume a total of 3.5 /16s to number the
> entire existing internet according to my suggested way of numbering
> things.

It would be nice to see this kind of analysis displayed in a graphic
way. I continually see people having difficulty grasping what large numbers
mean, both on their own and as the denominator of a fraction. But I
think that a graphical portrayal would go a long way to helping
everybody understand what we are really working with in IPv6.

> I'm willing to set aside a few other /16s for 6rd to be deployed
> temporarily (~5-10 years, hopefully), so long as they are done in such
> a way that a community decision to deprecate them and reclaim them is
> enforceable. (specific prefixes which can be filtered without harming
> native deployments).

Yes.

> Since we've already given each RIR a /12 to start off with and we still
> have 506 /12s left in the /3 from which we are allocating, I think
> we're OK.

And yes again.


--Michael Dillon



From michael.dillon at bt.com  Thu Oct 14 05:23:00 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 14 Oct 2010 10:23:00 +0100
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CB5E076.7000701@townsley.net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>

> If you don't like /56, wait until you have tasted /64. That is what is
> coming to North America if ISPs in the ARIN region are forced to deploy
> within a /32 here. 

ISPs in the ARIN region have never been forced to deploy within a /32.
In fact, the original ARIN IPv6 allocation policy was identical to the
IPv6 policy in every other region. None of the ARIN changes have ever 
restricted ISPs to a /32 allocation. That is merely the MINIMUM 
allocation to an ISP.

> On one hand, you accept that some ISPs are stuck and need 6rd to deploy
> IPv6 now, but on the other hand you are saying that the community
> (i.e.,
> the ISP's competitors) have the power to rip their IPv6 deployment out
> from under them at any time. 

I would hope that the ARIN Board of Trustees would never accept language
that allows the allocation to be ripped from under an ISP on short
notice.

Personally I would like to see the temporary 6RD policy have a fixed
term which would be the minimum number of years followed by a regular
review term (perhaps every two years) and then a notice period of
two years to return the allocation. And all ISPs would get notice
at the same time.

> If ARIN really wanted to take a step forward towards helping the
> quality
> of IPv6 deployment on the Internet via deprecation of IPv6 space, it
> would start efforts to see 2002::/16 deprecated. First things first.

It is none of ARIN's business. That particular allocation was made by
the IETF/IANA and is outside of ARIN's control.

--Michael Dillon



From mark at townsley.net  Thu Oct 14 08:35:53 2010
From: mark at townsley.net (Mark Townsley)
Date: Thu, 14 Oct 2010 14:35:53 +0200
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
Message-ID: <4CB6F929.3080207@townsley.net>


On 10/14/10 11:23 AM, michael.dillon at bt.com wrote:
>> If ARIN really wanted to take a step forward towards helping the
>> quality
>> of IPv6 deployment on the Internet via deprecation of IPv6 space, it
>> would start efforts to see 2002::/16 deprecated. First things first.
> It is none of ARIN's business. That particular allocation was made by
> the IETF/IANA and is outside of ARIN's control.
My comment above was in response to the suggestion that ARIN "should
make strong efforts to communicate and preserve the notion that
[RFC5969] is a transitional and therefore temporary solution".
Certainly, if ARIN should "communicate" that RFC 5969 is bad, it should
do the same for RFC 3056 and 3068.

On 10/13/10 11:33 PM, Owen DeLong wrote:
> I don't think we should deprecate 6to4 any faster than we should
> deprecate 6rd. In reality, they share pretty much the same level of
> problems and ugliness.
That's not what observable data suggests. Broken 6to4 has a measurable
impact on a broken IPv6 connectivity, and one of the reasons some
content providers are very hesitant to offer AAAAs 6to4 hosts. That's
not the case with 6rd. The technology is similar, but how it is deployed
and operated is very different.

See:

http://tools.ietf.org/html/draft-vandevelde-v6ops-harmful-tunnels-01

- Mark






From mark at townsley.net  Thu Oct 14 08:41:02 2010
From: mark at townsley.net (Mark Townsley)
Date: Thu, 14 Oct 2010 14:41:02 +0200
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <8C640354-D408-4172-8DA1-6272068308F5@delong.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>	<4CB5E076.7000701@townsley.net>	<20101013165959.GB3056@ussenterprise.ufp.org>	<CF727814-54AF-439B-83E6-541E2F32D92A@delong.com>	<20101013220758.GA27979@ussenterprise.ufp.org>	<40A9E942-9F0D-4B50-AC82-DE9E2F3D567C@delong.com>	<20101014002014.GA34976@ussenterprise.ufp.org>
	<8C640354-D408-4172-8DA1-6272068308F5@delong.com>
Message-ID: <4CB6FA5E.7020208@townsley.net>

 On 10/14/10 2:45 AM, Owen DeLong wrote:
>
> On Oct 13, 2010, at 5:20 PM, Leo Bicknell wrote:
>
>>
>> This probably won't fly as policy, but, let me give it a shot. :)
>>
>>   Any address space provided by ARIN for 6rd will not be issued
>>   until the recipient delivers one engineer and one executive from
>>   the provider of the majority of their non-IPv6 capable equipment
>>   to an ARIN public policy meeting to receive a public flogging.
>>   The recipient must provide baseball bats for all policy meeting
>>   attendees.
>>
> I like it, but, I suspect you are right that it wouldn't fly as policy.

When free.fr gave a presentation on their 6rd deployment at a RIPE
meeting last year, they received not one but two standing ovations for
providing a production-quality, supported, IPv6 service option to all of
their subscribers.

This contrast is nothing short of remarkable to me.

- Mark


From michael.dillon at bt.com  Thu Oct 14 08:52:24 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 14 Oct 2010 13:52:24 +0100
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CB6F929.3080207@townsley.net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>

> >> If ARIN really wanted to take a step forward towards helping the
> >> quality
> >> of IPv6 deployment on the Internet via deprecation of IPv6 space, it
> >> would start efforts to see 2002::/16 deprecated. First things first.
> > It is none of ARIN's business. That particular allocation was made by
> > the IETF/IANA and is outside of ARIN's control.

> My comment above was in response to the suggestion that ARIN "should
> make strong efforts to communicate and preserve the notion that
> [RFC5969] is a transitional and therefore temporary solution".
> Certainly, if ARIN should "communicate" that RFC 5969 is bad, it should
> do the same for RFC 3056 and 3068.

Who says 6RD is bad? 6RD and RFC 5969 which documents it, are both GOOD
things because they will accelerate the switch to IPv6. The discussions
are about ARIN policies which SUPPORT and FACILITATE 6RD. But the fact is
that 6RD is a temporary stopgap measure. That is not bad, that is just the
facts. And we should be clear that we are only supporting and facilitating
6RD as a means to an end, namely native IPv6.

> That's not what observable data suggests. Broken 6to4 has a measurable
> impact on a broken IPv6 connectivity, and one of the reasons some
> content providers are very hesitant to offer AAAAs 6to4 hosts. That's
> not the case with 6rd. The technology is similar, but how it is
> deployed
> and operated is very different.

This is not really an ARIN problem. Network operators have to pick and choose
their technology based on their needs and understanding. In any case, ARIN is
not involved with 6to4, but ARIN can play a role in facilitating 6RD.

ARIN is not the Architectural Regulator of Internet Networks. It is the 
American Registry of Internet Numbers. ARIN does not run the Internet, not even
in the USA. ARIN does not specify the Internet's architecture and design.

--Michael Dillon




From michael.dillon at bt.com  Thu Oct 14 08:56:29 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 14 Oct 2010 13:56:29 +0100
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CB6FA5E.7020208@townsley.net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<20101013165959.GB3056@ussenterprise.ufp.org>
	<CF727814-54AF-439B-83E6-541E2F32D92A@delong.com>
	<20101013220758.GA27979@ussenterprise.ufp.org>
	<40A9E942-9F0D-4B50-AC82-DE9E2F3D567C@delong.com>
	<20101014002014.GA34976@ussenterprise.ufp.org>
	<8C640354-D408-4172-8DA1-6272068308F5@delong.com>
	<4CB6FA5E.7020208@townsley.net>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423938133E87@EMV01-UKBR.domain1.systemhost.net>


> When free.fr gave a presentation on their 6rd deployment at a RIPE
> meeting last year, they received not one but two standing ovations for
> providing a production-quality, supported, IPv6 service option to all
> of
> their subscribers.
> 
> This contrast is nothing short of remarkable to me.

Possibly this is because free.fr is the CREATOR of 6RD, and not just
a deployer.

In any case, I think the violent Americans who want to wield baseball
bats are misdirecting their venom. They have forgotten that a large part
of the problem lies with the vendors of DSL equipment and the DSL Forum
which took so long to get IPv6 into their official spec. Many network
operators had no choice but to delay IPv6 testing because there was not
enough stuff to test.

Of course the cleverest network operators found a way around these vendor
problems but these workarounds could not provide general IPv6 broadband
services to large numbers of customers.

--Michael Dillon



From mark at townsley.net  Thu Oct 14 09:39:03 2010
From: mark at townsley.net (Mark Townsley)
Date: Thu, 14 Oct 2010 15:39:03 +0200
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>	<4CB5E076.7000701@townsley.net>	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
Message-ID: <4CB707F7.9020506@townsley.net>

An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101014/dbe5c694/attachment.htm>

From mark at townsley.net  Thu Oct 14 10:00:39 2010
From: mark at townsley.net (Mark Townsley)
Date: Thu, 14 Oct 2010 16:00:39 +0200
Subject: [arin-ppml] 6rd Policies 2010-9 and 2010-12 (was: Opposed to...)
In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B423938133E87@EMV01-UKBR.domain1.systemhost.net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>	<4CB5E076.7000701@townsley.net>	<20101013165959.GB3056@ussenterprise.ufp.org>	<CF727814-54AF-439B-83E6-541E2F32D92A@delong.com>	<20101013220758.GA27979@ussenterprise.ufp.org>	<40A9E942-9F0D-4B50-AC82-DE9E2F3D567C@delong.com>	<20101014002014.GA34976@ussenterprise.ufp.org>	<8C640354-D408-4172-8DA1-6272068308F5@delong.com>	<4CB6FA5E.7020208@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E87@EMV01-UKBR.domain1.systemhost.net>
Message-ID: <4CB70D06.6060404@townsley.net>

 On 10/14/10 2:56 PM, michael.dillon at bt.com wrote:
>> When free.fr gave a presentation on their 6rd deployment at a RIPE
>> meeting last year, they received not one but two standing ovations for
>> providing a production-quality, supported, IPv6 service option to all
>> of
>> their subscribers.
>>
>> This contrast is nothing short of remarkable to me.
> Possibly this is because free.fr is the CREATOR of 6RD, and not just
> a deployer.
Oui, les deux.
> In any case, I think the violent Americans who want to wield baseball
> bats are misdirecting their venom. They have forgotten that a large part
> of the problem lies with the vendors of DSL equipment and the DSL Forum
> which took so long to get IPv6 into their official spec.
s/took/are taking - it's still not finished for the predominant non-PPP
DSL (and FTTH) model.

- Mark

>  Many network
> operators had no choice but to delay IPv6 testing because there was not
> enough stuff to test.
>
> Of course the cleverest network operators found a way around these vendor
> problems but these workarounds could not provide general IPv6 broadband
> services to large numbers of customers
> --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 Oct 14 10:45:02 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 14 Oct 2010 07:45:02 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CB6F929.3080207@townsley.net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
Message-ID: <577846A2-C43A-4AA7-80EE-1A9A60A96C56@delong.com>


On Oct 14, 2010, at 5:35 AM, Mark Townsley wrote:

> 
> On 10/14/10 11:23 AM, michael.dillon at bt.com wrote:
>>> If ARIN really wanted to take a step forward towards helping the
>>> quality
>>> of IPv6 deployment on the Internet via deprecation of IPv6 space, it
>>> would start efforts to see 2002::/16 deprecated. First things first.
>> It is none of ARIN's business. That particular allocation was made by
>> the IETF/IANA and is outside of ARIN's control.
> My comment above was in response to the suggestion that ARIN "should
> make strong efforts to communicate and preserve the notion that
> [RFC5969] is a transitional and therefore temporary solution".
> Certainly, if ARIN should "communicate" that RFC 5969 is bad, it should
> do the same for RFC 3056 and 3068.
> 
I think that ARIN has communicated that 6to4 is a temporary transitional
technology and I would not oppose such communication.

> On 10/13/10 11:33 PM, Owen DeLong wrote:
>> I don't think we should deprecate 6to4 any faster than we should
>> deprecate 6rd. In reality, they share pretty much the same level of
>> problems and ugliness.
> That's not what observable data suggests. Broken 6to4 has a measurable
> impact on a broken IPv6 connectivity, and one of the reasons some
> content providers are very hesitant to offer AAAAs 6to4 hosts. That's
> not the case with 6rd. The technology is similar, but how it is deployed
> and operated is very different.
> 
The only difference between the two that is causing that observation
is that clients do not "automatically" engage in 6rd and it is not built
on anycast. In fact, if we were to deploy working 6to4 gateways more
widely, the broken 6to4 issue would pretty much evaporate.

> See:
> 
> http://tools.ietf.org/html/draft-vandevelde-v6ops-harmful-tunnels-01
> 

However, wider deployment of 6to4 (as noted by Comcast) is actually
a better solution to that problem than deprecation of 6to4.

Owen



From bill at herrin.us  Thu Oct 14 10:50:22 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 14 Oct 2010 10:50:22 -0400
Subject: [arin-ppml] Draft Policy 2010-12: IPv6 Subsequent Allocation -
 Last Call (text revised)
In-Reply-To: <AANLkTin99B472MsL1K7gu0yxHbggfpXcLCy66z=qm9yO@mail.gmail.com>
References: <4CB5F5FD.7090806@arin.net>
	<F28A2A7A-9452-49E4-BCF0-BBDB9C8F4556@delong.com>
	<AANLkTinGWK4nnxdcOKf=bmGdLG4dRYjncYcv9Wuh5dGB@mail.gmail.com>
	<AANLkTin99B472MsL1K7gu0yxHbggfpXcLCy66z=qm9yO@mail.gmail.com>
Message-ID: <AANLkTi=nB4pPQ8LCvJ6zS4gCS=qog+MjKCtOcgPg=L5n@mail.gmail.com>

On Thu, Oct 14, 2010 at 12:04 AM, Christopher Morrow
<christopher.morrow at gmail.com> wrote:
> On Wed, Oct 13, 2010 at 6:19 PM, William Herrin <bill at herrin.us> wrote:
>> On Wed, Oct 13, 2010 at 5:54 PM, Owen DeLong <owen at delong.com> wrote:
>>> To clarify, the /24 maximum and the designated block apply ONLY
>>> to subsequent allocations for transitional purposes. Subsequent allocations
>>> for native IPv6 deployment are not restricted or encumbered in any way
>>> other than the standards set forth in existing policy.
>>
>> Ah. In that case, I OPPOSE draft policy 2010-12 as written.
>>
>> I would support a revised version that applies the /24 limit to any
>> subsequent allocation _for which the prior efficient utilization
>> requirements have been waived_, regardless of whether its for
>> transitional technologies.
>
> hrm, I don't think the prior efficient utilization requirements were
> waved.

You had two longstanding rules for additional allocations:
demonstrated need and efficient utilization. With the proposal you
have only one: demonstrated need. Spin it however you want, this
proposal waives the efficient utilization requirements for additional
IPv6 allocations.

I said it at the mic to some applause and I'll say it again here:
These early phase IPv6 allocations *should* be weighed heavily on
demonstrated need and lightly if at all on competent prior use. We
need more operational experience before we truly understand what our
IPv6 addressing needs are.

But let's be honest about it. We're talking about temporarily waiving
the efficient use rule. With good reason.


In that context, it's just as obvious that we need some hard limits so
that in our inexperience we don't go hog wild and waste resources left
and right. As expressed in the current draft of 2010-12, the upper
bound on allocations is a fraud. It appears to exist but a close
reading shows that it's toothless, easily circumvented, a bald faced
lie.

I'm willing to see a rule waived with such obviously good cause, but
not when you try to lie to me about it. So please: fix the lie in the
current draft of 2010-12 before you ask the board to ratify 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 owen at delong.com  Thu Oct 14 11:02:55 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 14 Oct 2010 08:02:55 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CB707F7.9020506@townsley.net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>	<4CB5E076.7000701@townsley.net>	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
Message-ID: <D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>

> 
> Classifying 6rd as a means to an end for native IPv6 is an architectural statement, though one that is at least consistent with the 6rd RFC. Limiting the space which 6rd can run, however, presupposes how the transition from 6rd to native is to be done.
> 
> From RFC 5969:
> 
>    The SP can choose to provision a separate IPv6 address block for
>    native service, or reuse the 6rd prefix block itself.  
> 
> An ARIN policy that requires moving to a different block is, by the letter, an IETF standards-track RFC violation. 
> 
However, this is not the first time the IETF has made the mistake of stepping over the line from Architectureal
design to address policy. ARIN sets address policy for the ARIN service region, the IETF does not.

Another example of ARIN policy correcting this error on the part of IETF would be 2005-1, prior to which
there was no facility for Provider Independent End User assignments in ANY region. Today there is
policy to support those assignments in all 5 regions.

> I'm calling this out only to underscore that there are serious operational considerations with respect to allowing native and 6rd to coexist within the same prefix while moving to native. Considerations that could actually discourage movement to native by ISPs. We want it to be as easy as possible for ISPs to move to native IPv6 from 6rd. This is why this sentence exists in the RFC.
> 
Yes... Those operational considerations are hazardous to address policy and would prevent any ability to
ensure the eventual deprecation of this "transitional" technology at the expense of vast amounts of address
space which would have been distributed in an excessively (even by IPv6 standards) wasteful manner.

I'm all for 6rd as a temporary fix, but, as a permanent institution, it is pretty awful. Even if we ignore the
issue of deprecation and assume that providers would switch to native without additional motivation,
allowing them to have their native and 6rd deployments to co-exist in the same space would result
in sparse allocation of their native blocks across the oversized prefix granted for 6rd which would
prevent future reclamation of that oversized prefix.

By requiring the native deployments to go in a separate prefix which is more appropriately sized for
the ISPs native deployment, we ensure the ability to eventually reclaim and re-use these oversized
blocks for other purposes.

> Putting 6rd into a segregated block, in particular with the threat of that block expiring, only adds to deployment hurdles. Today, it would be one more thing that the poor person at the ISP that actually wants to see IPv6 deployed before the CGNs take over has to convince his or her management is not a future risk factor. Tomorrow, it could be one more hurdle for the ISP to renumber their IPv6 customer when moving to native. 
> 
There is no threat of that block expiring. The intent is to allow for a mechanism by which to signal the following:

1.	Native deployments should go in a separate appropriately sized block.
2.	6rd is temporary and transitional in nature. It is not to be considered permanent.
	Temporary in this case may well span a decade, but, there should eventually be an end date.
3.	The sooner you migrate your customers from 6rd to native, the better. There is value in pressuring
	your vendors to make this possible.

The CGN FUD really is overplayed here. Even with this limitation, CGN remains far less attractive to
any provider. Even a provider which doesn't see this, I am pretty sure that their customers will see it
in short order.

> I'm all for facilitation. Let's focus on that rather than assuming we know how the operator is going to migrate from 6rd to native and encoding that in the ARIN policy.
> 
The point of this aspect of the policy is not that we are assuming the operator will migrate. We are
requiring that they eventually do. Allowing them to hang on to these oversized 6rd blocks beyond
the point where a switch to native is practicable is not good stewardship of the address space.

If you can get 6rd to fit in  single /16, then, perhaps we could consider allowing it to be permanent.

However, if ~3,000 ARIN members deploy 6rd /24s, then, you're talking about the vast majority
of an entire /12 just in the ARIN region. Since most of them could deploy native and give their
customers much larger (256x) assignments and fit within 1/16th of the proposed address space
for 6rd, (IOW, a 4096x gain in addressing efficiency), I believe that the ARIN community has
a valid interest in ensuring that this is a temporary use of address resources.

Owen

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

From mark at townsley.net  Thu Oct 14 12:56:04 2010
From: mark at townsley.net (Mark Townsley)
Date: Thu, 14 Oct 2010 18:56:04 +0200
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>	<4CB5E076.7000701@townsley.net>	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
Message-ID: <4CB73624.1000309@townsley.net>

An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101014/b7687e44/attachment.htm>

From bjohnson at drtel.com  Thu Oct 14 13:10:26 2010
From: bjohnson at drtel.com (Brian Johnson)
Date: Thu, 14 Oct 2010 12:10:26 -0500
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTimduTRGc1uYBgZ6UcfzaX6f2xftn10Z7nh7YOYn@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com><29A54911243620478FF59F00EBB12F47021D8C8E@ex01.drtel.lan><10093.1286906540@marajade.sandelman.ca><4CB4AEEC.6020701@ipinc.net>
	<20732.1286911333@marajade.sandelman.ca>
	<AANLkTimduTRGc1uYBgZ6UcfzaX6f2xftn10Z7nh7YOYn@mail.gmail.com>
Message-ID: <29A54911243620478FF59F00EBB12F47021D8D4D@ex01.drtel.lan>

>-----Original Message-----
>From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>Behalf Of William Herrin
>Sent: Tuesday, October 12, 2010 2:38 PM
>To: Michael Richardson
>Cc: arin-ppml at arin.net
>Subject: Re: [arin-ppml] Preemptive IPv6 assignment
>
>On Tue, Oct 12, 2010 at 3:22 PM, Michael Richardson <mcr at sandelman.ca>
>wrote:
>> $1250 is not very much, but it is enough that it prevents
organizations
>> from getting it because of authorization levels required.
>
>Folks, we can easily get lost in whether or not this observation is
>reasonable. Reasonable or not, it's reality. The question for the rest
>of us, then, is this:
>
>Do we want to sit around and wait for these guys while maintaining our
>costly dual stacks? Or should we remove the issue from the equation so
>that it no longer stands in the way of any IPv6 deployments?
>

So now we are going to put people on some kind of "guilt trip" because
of our decisions. If I do something that costs me money, then everyone
else should share my pain?

>Preemptive assignment is no magic bullet. Some of these folks will
>just find the next reason for delay. But why allow ARIN to be the
>reason they haven't deployed yet?
>

For me, the one-click option is the way to go. Make it easy to get the
space but do not "force" the space on anyone. I doubt anything that is
said going forward will change my mind on this, but go ahead and give me
a reason to make somebody else do something that they don't want to
without implementing some kind of global governance over the operators,
or acting like the in clique in junior high. :-)

- Brian J.

()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments

* Please note that all list members and archive readers may consider
themselves Recipients of this message, in reference to the appended
disclaimer.  (I don't add it myself and can't control it, sorry.)


 CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the
intended recipient(s) and may contain confidential and privileged information. Any unauthorized review,
copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original message. Thank you.


From marty at akamai.com  Thu Oct 14 14:20:17 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Thu, 14 Oct 2010 14:20:17 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - October 2010
In-Reply-To: <AANLkTi=9xrNk9SdZ=iy61eak4jPR_+Mc+7JuUzSd4COv@mail.gmail.com>
Message-ID: <C8DCC221.134A0%marty@akamai.com>




On 10/13/10 5:34 PM, "Scott Leibrand" <scottleibrand at gmail.com> wrote:

> On Wed, Oct 13, 2010 at 5:26 PM, Hannigan, Martin <marty at akamai.com> wrote:
>> 
>> I do believe that the two reasons presented for the tabling of one of the
>> proposals on the AC docket are weak to say the least. That is the only issue
>> at hand and worthy of discussion. Otherwise, we're going in circles and we
>> may as well not bother.
> 
> Would you care to address the question of whether we should wait until each
> RIR has had a chance to discuss the proposal at a public meeting before we
> send it on to last call and then to the board?


What are the reasons to wait? If clarity edits are required the current
global PDP has an accommodation for that. Major edits, especially after
consensus in this region or review in others requires resubmission to all
forums regardless. Pausing might save time with respect to the
round-the-world requirements, but seems like it only saves anything
significant and worthwhile if all RIR's had a pause, something that would
probably need to be codified in the ICANN <> RIR MoU. Opening that can of
worms is undesirable since one or the other may be at a significant
[dis]advantage point than when the agreement was previously negotiated.
Changing terms of agreements with RIR's at this stage of v4 depletion is
probably unwise, but I trust that John Curran has a handle on.

This is the second time that the ARIN AC has introduced instability into the
global pdp. That's not a defect of the current process IMHO, it's a failure
to follow the guidelines and an exploit of the process with the regional
PDP. From my perspective, ARIN region global policy handling is broken.

 
> I support this proposal, but I think it has a better chance of success if we
> work to accept input from the other regions.?

 
I disagree, and I continue to be concerned that this action wasn't very well
thought out and that has and continues to be my point with respect to policy
handling [never mind this proposal with respect to that].

I hope that is helpful to your internal AC discussions with regards to
proposal handling and the PDP.



Best,

-M<




From bill at herrin.us  Thu Oct 14 15:05:36 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 14 Oct 2010 15:05:36 -0400
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <29A54911243620478FF59F00EBB12F47021D8D4D@ex01.drtel.lan>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47021D8C8E@ex01.drtel.lan>
	<10093.1286906540@marajade.sandelman.ca>
	<4CB4AEEC.6020701@ipinc.net> <20732.1286911333@marajade.sandelman.ca>
	<AANLkTimduTRGc1uYBgZ6UcfzaX6f2xftn10Z7nh7YOYn@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47021D8D4D@ex01.drtel.lan>
Message-ID: <AANLkTimfMPR=GQX_bm4xUNhcTDVZx+D1gcsXPiNKS18X@mail.gmail.com>

On Thu, Oct 14, 2010 at 1:10 PM, Brian Johnson <bjohnson at drtel.com> wrote:
>>Do we want to sit around and wait for these guys while maintaining our
>>costly dual stacks? Or should we remove the issue from the equation so
>>that it no longer stands in the way of any IPv6 deployments?
>
> So now we are going to put people on some kind of "guilt trip" because
> of our decisions.

Brian,

Guilt trip? Heck, I don't care if the latecomers harm themselves with
their deployment choices. I do care if they harm me. I hope you care
if they harm you.

If you have to bend over backwards to continue talking to them on
IPv4, it seems to me like that harms you. You don't agree?


>>Preemptive assignment is no magic bullet. Some of these folks will
>>just find the next reason for delay. But why allow ARIN to be the
>>reason they haven't deployed yet?
>
> For me, the one-click option is the way to go. Make it easy to get the
> space but do not "force" the space on anyone.

I would support a 1-click IPv6 initial assignment/allocation process.
Would you care to draft a policy proposal?

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  Thu Oct 14 15:05:42 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 14 Oct 2010 12:05:42 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CB73624.1000309@townsley.net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>	<4CB5E076.7000701@townsley.net>	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
	<4CB73624.1000309@townsley.net>
Message-ID: <1FFCDC31-4914-4F7A-9BB3-4B739A84E681@delong.com>


On Oct 14, 2010, at 9:56 AM, Mark Townsley wrote:

> On 10/14/10 5:02 PM, Owen DeLong wrote:
>> 
>>> 
>>> Classifying 6rd as a means to an end for native IPv6 is an architectural statement, though one that is at least consistent with the 6rd RFC. Limiting the space which 6rd can run, however, presupposes how the transition from 6rd to native is to be done.
>>> 
>>> From RFC 5969:
>>> 
>>>    The SP can choose to provision a separate IPv6 address block for
>>>    native service, or reuse the 6rd prefix block itself.  
>>> 
>>> An ARIN policy that requires moving to a different block is, by the letter, an IETF standards-track RFC violation. 
>>> 
>> However, this is not the first time the IETF has made the mistake of stepping over the line from Architectureal
>> design to address policy. ARIN sets address policy for the ARIN service region, the IETF does not.
>> 
>> Another example of ARIN policy correcting this error on the part of IETF would be 2005-1, prior to which
>> there was no facility for Provider Independent End User assignments in ANY region. Today there is
>> policy to support those assignments in all 5 regions.
>> 
>>> I'm calling this out only to underscore that there are serious operational considerations with respect to allowing native and 6rd to coexist within the same prefix while moving to native. Considerations that could actually discourage movement to native by ISPs. We want it to be as easy as possible for ISPs to move to native IPv6 from 6rd. This is why this sentence exists in the RFC.
>>> 
>> Yes... Those operational considerations are hazardous to address policy and would prevent any ability to
>> ensure the eventual deprecation of this "transitional" technology at the expense of vast amounts of address
>> space which would have been distributed in an excessively (even by IPv6 standards) wasteful manner.
>> 
>> I'm all for 6rd as a temporary fix, but, as a permanent institution, it is pretty awful. Even if we ignore the
>> issue of deprecation and assume that providers would switch to native without additional motivation,
>> allowing them to have their native and 6rd deployments to co-exist in the same space would result
>> in sparse allocation of their native blocks across the oversized prefix granted for 6rd which would
>> prevent future reclamation of that oversized prefix.
>> 
>> By requiring the native deployments to go in a separate prefix which is more appropriately sized for
>> the ISPs native deployment, we ensure the ability to eventually reclaim and re-use these oversized
>> blocks for other purposes.
> 6rd is just getting deployed now, so precisely how to transition it to native is still speculative. But, I know that technically it is quite possible (with equipment that will be available in 2011, if not today) to allow 6rd and native exist alongside one another in a very transparent manner to the end-user. Native can be brought up (or back down if there is a problem) one CPE, one head-end or one DSLAM at a time in whatever order the network operations folks want without having to alert the customer-care folks that have to deal with IPv6 being renumbered within the house, nor dealing with the well-known issues of multihoming towards two disparate address blocks. Once, say, a region of the network has transitioned appropriately (something that may only happen after the last end-user goes out and buys the right CPE, or the operator deploys enough native gear), a move to a more aggregated space and disabling of 6rd within the region can be scheduled appropriately. Policy should not disallow nor even discourage such an approach.
> 

Nothing in what I have proposed prevents that. The operator can use the 6rd space to do the transition
and then renumber after the transition is done if they want. The key is not to believe that the 6rd
space is in any way permanent.

The policy sent to last call by the AC merely requires that the 6rd allocations be done from a specific
prefix for that purpose and conveys that the 6rd allocations are transitional and temporary in nature.
It doesn't do anything to interfere with the approach you describe, so long as the provider does
eventually get to that renumber point.

> Again, I'm trying to make it *easier* for the operator to move to native. I want the operator to have tools available to make that as easy as possible, with the fewest moving parts. The incentive to have native v6 customers within an aggregated space will still be there, even if native and 6rd interfaces are allowed to exist at the same time, but that move can be staged and scheduled with appropriate advance notice and care independent of getting the user on native as soon as physically possible.
> 
We're in agreement there to a certain extent. However, it has to be done with responsible address management in mind as well. Making the 6rd prefixes permanent would be irresponsible.

> We agree that 6rd should be temporary. I think we even agree that it might take 10 years to move completely from 6rd to native. I'm even be OK with asking the provider to give back the block when they are done with it if we are demonstrably on track towards some new global IPv6 address exhaustion problem. We aren't far away from one another here.

Agreed.

>> 
>>> Putting 6rd into a segregated block, in particular with the threat of that block expiring, only adds to deployment hurdles. Today, it would be one more thing that the poor person at the ISP that actually wants to see IPv6 deployed before the CGNs take over has to convince his or her management is not a future risk factor. Tomorrow, it could be one more hurdle for the ISP to renumber their IPv6 customer when moving to native. 
>>> 
>> There is no threat of that block expiring. The intent is to allow for a mechanism by which to signal the following:
>> 
>> 1. Native deployments should go in a separate appropriately sized block.
>> 2. 6rd is temporary and transitional in nature. It is not to be considered permanent.
>>  Temporary in this case may well span a decade, but, there should eventually be an end date.
>> 3. The sooner you migrate your customers from 6rd to native, the better. There is value in pressuring
>>  your vendors to make this possible.
> I think #2 and #3 are reasonable, and you don't need #1 to make that clear. 

No, but, you do need #1 to make it possible to enforce #2 and #3 later.

>> 
>> The CGN FUD really is overplayed here. Even with this limitation, CGN remains far less attractive to
>> any provider.
> Then why are so many looking to buy them? Why the policy proposals for a shared-SP space? 

There are no policy proposals for shared-SP space. There is an IETF draft. The IETF draft in
question is generally opposed in the address policy community, to the best of my knowledge.
Most of the discussions I've been involved in where it was a subject were about the number
of different ways in which said draft was a bad idea.

Frankly, I'm betting that the providers that buy CGNs will be very dissatisfied with them in
relatively short order. I also think that they will be encouraging their customers to switch
to other providers.

>> Even a provider which doesn't see this, I am pretty sure that their customers will see it
>> in short order.
> I heard the same argument 10 years ago about the NAT the customers now claim they NEED. Perhaps your view is tainted by being so close to the IPv6-enabled world. From my vantage, we are still very much in a battle.

I tend to doubt it. NAT was pretty bad, but, CGN/LSN/whatever you want to call it is far
less attractive from the SP and the customer perspective than NAT was. It's all the problems
of NAT amplified many many times over with some additional new unique problems.

I think that the odds of CGN/LSN making it to wide-scale deployment are near zero.
Notice that nobody has even tested CGN/LSN on real end users yet.

>> 
>>> I'm all for facilitation. Let's focus on that rather than assuming we know how the operator is going to migrate from 6rd to native and encoding that in the ARIN policy.
>>> 
>> The point of this aspect of the policy is not that we are assuming the operator will migrate. We are
>> requiring that they eventually do. Allowing them to hang on to these oversized 6rd blocks beyond
>> the point where a switch to native is practicable is not good stewardship of the address space.
>> 
>> If you can get 6rd to fit in  single /16, then, perhaps we could consider allowing it to be permanent.
>> 
>> However, if ~3,000 ARIN members deploy 6rd /24s, then, you're talking about the vast majority
>> of an entire /12 just in the ARIN region. Since most of them could deploy native and give their
> "most of them could deploy native"?? Wishing this to be true will not make it happen. The problem is that they evaluated deploying native and realized the could not and only then did we come along with 6rd and turn things around. That's where we are, like it or not. But I think you agree with this as your report on which technologies work and which do not on this thread was quite accurate. 
> 
You misunderstand me... I wasn't saying they can deploy native now. I was saying that once
native is a possibility, the required address size for native is several orders of magnitude
smaller while providing a couple of orders of magnitude more address space to their
customers.

Please take this paragraph only in the context of measuring the relative address consumption/
unit of customer space and not as a statement of current abilities.

Owen

> - Mark
>> customers much larger (256x) assignments and fit within 1/16th of the proposed address space
>> for 6rd, (IOW, a 4096x gain in addressing efficiency), I believe that the ARIN community has
>> a valid interest in ensuring that this is a temporary use of address resources.
> 
> 
> 
> 
>> 
>> Owen
>> 
> 

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

From farmer at umn.edu  Thu Oct 14 15:19:03 2010
From: farmer at umn.edu (David Farmer)
Date: Thu, 14 Oct 2010 14:19:03 -0500
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CB707F7.9020506@townsley.net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>	<4CB5E076.7000701@townsley.net>	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>	<4CB6F929.3080207@townsley.net>	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
Message-ID: <4CB757A7.1000903@umn.edu>

On 10/14/10 08:39 CDT, Mark Townsley wrote:
>   On 10/14/10 2:52 PM, michael.dillon at bt.com wrote:
>
>>  Who says 6RD is bad? 6RD and RFC 5969 which documents it, are both
>>  GOOD things because they will accelerate the switch to IPv6. The
>>  discussions are about ARIN policies which SUPPORT and FACILITATE 6RD.
>>  But the fact is that 6RD is a temporary stopgap measure. That is not
>>  bad, that is just the facts. And we should be clear that we are only
>>  supporting and facilitating 6RD as a means to an end, namely native
>>  IPv6.
>
>>  In any case, ARIN is not involved with 6to4, but ARIN can play a role
>>  in facilitating 6RD.
>
> I am very glad to see such a healthy attitude of facilitation. We need
> it, as we still have quite a bit of hill to push the IPv6 rock up.
>
>>  ARIN is not the Architectural Regulator of Internet Networks. It is
>>  the American Registry of Internet Numbers. ARIN does not run the
>>  Internet, not even in the USA. ARIN does not specify the Internet's
>>  architecture and design.
>
> Classifying 6rd as a means to an end for native IPv6 is an architectural
> statement, though one that is at least consistent with the 6rd RFC.
> Limiting the space which 6rd can run, however, presupposes how the
> transition from 6rd to native is to be done.
>
>  From RFC 5969:
>
> The SP can choose to provision a separate IPv6 address block for
> native service, or reuse the 6rd prefix block itself.
>
> An ARIN policy that requires moving to a different block is, by the
> letter, an IETF standards-track RFC violation.

Lets be clear here nothing in the policy says you have to do 6rd from 
one of the transition blocks, or that you can't do 6rd from another 
block.  I believe the policy is saying that, if you want a very large 
block to do 6rd, one big enough to do 32+56, that you may not have 
justify otherwise, you can have one out of a special transition range, 
but you may be required to return it in the future.

However, If you have enough customers to justify a /24 under normal 
policy you can get a normal block and use it for 6rd and not have to 
return it ever.  Also, you could do 6rd in a normal block and not encode 
the full 32 bits of IPv4 in the IPv6 address.

The policy allow ISPs that may not have otherwise justified a /24 it get 
one to do 6rd.

> I'm calling this out only to underscore that there are serious
> operational considerations with respect to allowing native and 6rd to
> coexist within the same prefix while moving to native. Considerations
> that could actually discourage movement to native by ISPs. We want it to
> be as easy as possible for ISPs to move to native IPv6 from 6rd. This is
> why this sentence exists in the RFC.

Also, nothing is the RFC says that all ISPs should be able to get a /24 
regardless of how many customers they have and then keep it forever.  I 
believe allowing more ISPs to get /24s but out of a transition block 
that may be deprecated in the future is a reasonable compromise.

Realize in order to justify a /24 and giving /56s to customers you need 
more than 591,580,804 customers, remember that you are getting 4B /56s. 
  If you are planing for /48s per customer then you would need 
3,223,061 customers.  But then if you are going to give customers a /48 
after you are done with 6rd, you will still probably need to renumber 
most of your customers.  Because they are packed into a bunch of /56 
near each other.

> Putting 6rd into a segregated block, in particular with the threat of
> that block expiring, only adds to deployment hurdles. Today, it would be
> one more thing that the poor person at the ISP that actually wants to
> see IPv6 deployed before the CGNs take over has to convince his or her
> management is not a future risk factor. Tomorrow, it could be one more
> hurdle for the ISP to renumber their IPv6 customer when moving to native.

Yes, ISP are going to have to make a choice do 6rd probably in a block 
smaller than /24 for most ISPs, but not have to renumber.  Or, to do 6rd 
in a /24, but probably have to renumber their customers, if/when the 
community decides it is time to deprecate the transition block.  And, 
realistically they are going to have to renumber anyway if they ever 
need/want more than a /56.

Are you suggestion that all ISPs should just be able to get a /24 and 
never have to return it?

> I'm all for facilitation. Let's focus on that rather than assuming we
> know how the operator is going to migrate from 6rd to native and
> encoding that in the ARIN policy.
>
> - Mark

The more we talk about this the more I think we should split this into 
two parts a new IPv6 transition policy (like maybe in 6.12) allowing a 
/24 allocation to ISPs out of a transition pool.  Then a separate policy 
allowing subsequent allocations for new projects or other expansion of 
business that were not anticipated when an initial allocation was made. 
  We need to enable a lot of people to get bigger than /32 some of them 
may use this for 6rd, but as long as they justify it with there customer 
base then why not.  Remember the "don't penalize the pioneers" comment 
from the floor last week.

-- 
===============================================
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 lorenzo at google.com  Thu Oct 14 16:51:41 2010
From: lorenzo at google.com (Lorenzo Colitti)
Date: Thu, 14 Oct 2010 13:51:41 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
Message-ID: <AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>

On Thu, Oct 14, 2010 at 8:02 AM, Owen DeLong <owen at delong.com> wrote:

> If you can get 6rd to fit in  single /16, then, perhaps we could consider
> allowing it to be permanent.
>
> However, if ~3,000 ARIN members deploy 6rd /24s, then, you're talking about
> the vast majority of an entire /12 just in the ARIN region.
>

Why not we make it a /28, and thus give the customer a /60? The customer
still gets 16 subnets for his house, and when 6rd goes away (since, as you
point out there are other disadvantages beyond address space use compared to
native IPv6), then the subnet will be /56 (since, following your reasoning,
that is what competitors with native IPv6 access will be providing).

I would point out that the only ISP I am aware of that is conducting
residential trials of IPv6 seems to be talking about giving only a /64 to
the home by default due to CPE issues. To me, that is a much greater problem
than having a /60 instead of a /56, because with a /64 you can't do any
subnetting at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101014/db60bee0/attachment.htm>

From owen at delong.com  Thu Oct 14 17:06:51 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 14 Oct 2010 14:06:51 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
Message-ID: <6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com>


On Oct 14, 2010, at 1:51 PM, Lorenzo Colitti wrote:

> On Thu, Oct 14, 2010 at 8:02 AM, Owen DeLong <owen at delong.com> wrote:
> If you can get 6rd to fit in  single /16, then, perhaps we could consider allowing it to be permanent.
> 
> However, if ~3,000 ARIN members deploy 6rd /24s, then, you're talking about the vast majority of an entire /12 just in the ARIN region.
> 
> Why not we make it a /28, and thus give the customer a /60? The customer still gets 16 subnets for his house, and when 6rd goes away (since, as you point out there are other disadvantages beyond address space use compared to native IPv6), then the subnet will be /56 (since, following your reasoning, that is what competitors with native IPv6 access will be providing).
> 
/60s are horrible... They completely stifle any ability for the customer to do PD-based topology
within the site.

> I would point out that the only ISP I am aware of that is conducting residential trials of IPv6 seems to be talking about giving only a /64 to the home by default due to CPE issues. To me, that is a much greater problem than having a /60 instead of a /56, because with a /64 you can't do any subnetting at all.

True... /64 should be even more discouraged than /60, but, the reality is that we should look at
/56 as a temporary expedient due to inefficiencies in 6rd and consider /48 the norm.

Owen

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

From mark at townsley.net  Thu Oct 14 17:36:59 2010
From: mark at townsley.net (Mark Townsley)
Date: Thu, 14 Oct 2010 23:36:59 +0200
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
	<6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com>
Message-ID: <4CB777FB.20102@townsley.net>

An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101014/8e467cc2/attachment.htm>

From owen at delong.com  Thu Oct 14 17:48:47 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 14 Oct 2010 14:48:47 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CB777FB.20102@townsley.net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
	<6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com>
	<4CB777FB.20102@townsley.net>
Message-ID: <5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com>


On Oct 14, 2010, at 2:36 PM, Mark Townsley wrote:

> On 10/14/10 11:06 PM, Owen DeLong wrote:
>> 
>> 
>> On Oct 14, 2010, at 1:51 PM, Lorenzo Colitti wrote:
>> 
>>> On Thu, Oct 14, 2010 at 8:02 AM, Owen DeLong <owen at delong.com> wrote:
>>> If you can get 6rd to fit in  single /16, then, perhaps we could consider allowing it to be permanent.
>>> 
>>> However, if ~3,000 ARIN members deploy 6rd /24s, then, you're talking about the vast majority of an entire /12 just in the ARIN region.
>>> 
>>> Why not we make it a /28, and thus give the customer a /60? The customer still gets 16 subnets for his house, and when 6rd goes away (since, as you point out there are other disadvantages beyond address space use compared to               native IPv6), then the subnet will be /56 (since, following your reasoning, that is what competitors with native IPv6 access will be providing).
>>> 
>> /60s are horrible... They completely stifle any ability for the customer to do PD-based topology
>> within the site.
> I think you are assuming what the PD-based topology mechanisms are going to be. They haven't really been designed, and certainly haven't been coded and shipped yet. All we are doing at this point is providing a playing field. Within that field:
> 
> /60 is an *enormous* improvement over /64. Night and day.
> 
> /56 is certainly better than /60, but not night and day as with /64 and /60. 
> 
> The point here is that if we design home routing and PD for 2^4 subnets, it's not hard to take that and extend it for 2^8 or 2^16. Not so if you are starting with 2^1.
> 
With all due respect, I must strongly disagree here. Whatever we decide here will likely impact and set the standards by which home gateways are designed going forward.

We agree that /64 is a non-starter.

I strongly believe that the target should be /48. That 6rd has such terrible deficiencies in its use of address space that we cannot afford /48 and therefore must compromise to /56.

Further compromising to /60 runs the risk of that becoming a de facto industry standard which will potentially be very difficult to overcome.

You asked me to tell you if you are contradicting someone from your organization... You are contradicting Tony
Hain here, or, at least my understanding of what Tony has been saying.

> Consumer products will be designed to operate within the lowest common denominator of the above. If we can make that /60 vs. /64, that's a big win and we might see some potential for upsell into /56 for "bigger home networks". But, if we have to do a ton of work to make networks work within a single /64 anyway, once we have done that, it's hard to argue for supporting multiple subnets as well. I'm trying to avoid having to do the work at all for /64, but that can only happen if I know the minimum number of subnets in the home is greater than 1. 
> 
That is, indeed, the source of my concern. If consumer products are developed only to the lowest common denominator,
we risk establishing /60 as that point. /56 is bad enough. As I have said, we should strongly encourage /48 as the
standard around which development occurs while recognizing /56 as a necessary limitation of 6rd.

I don't think we are disagreeing here, and I don't think anyone is advocating /64s. The AC has approved and forwarded
to last call policy which enables /56s for 6rd, but, encourages treating those as temporary and transitional in nature.
I think this is the best compromise.

Owen

> - Mark
> 
>> 
>>> I would point out that the only ISP I am aware of that is conducting residential trials of IPv6 seems to be talking about giving only a /64 to the home by default due to CPE issues. To me, that is a much greater problem than having a /60 instead of a /56, because with a /64 you can't do any subnetting at all.
>> 
>> True... /64 should be even more discouraged than /60, but, the reality is that we should look at
>> /56 as a temporary expedient due to inefficiencies in 6rd and consider /48 the norm.
>> 
>> Owen
>> 
> 

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

From mark at townsley.net  Thu Oct 14 18:18:40 2010
From: mark at townsley.net (Mark Townsley)
Date: Fri, 15 Oct 2010 00:18:40 +0200
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
	<6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com>
	<4CB777FB.20102@townsley.net>
	<5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com>
Message-ID: <4CB781C0.1020507@townsley.net>

An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101015/30996cf9/attachment.htm>

From fred at cisco.com  Thu Oct 14 19:22:05 2010
From: fred at cisco.com (Fred Baker)
Date: Thu, 14 Oct 2010 16:22:05 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CB781C0.1020507@townsley.net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
	<6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com>
	<4CB777FB.20102@townsley.net>
	<5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com>
	<4CB781C0.1020507@townsley.net>
Message-ID: <71B9FB76-4718-48B1-8185-B06CAD4705C6@cisco.com>


On Oct 14, 2010, at 3:18 PM, Mark Townsley wrote:

>> You asked me to tell you if you are contradicting someone from your organization... You are contradicting Tony Hain here, or, at least my understanding of what Tony has been saying.
> 
> Thanks for the heads up.

From my perspective, in the equipment, the question is "do I assume that the ISP will give me a prefix that allows for multiple subnets, or do I assume that the ISP will give me a /64". Once you say "more than one", "how many" is a configuration issue, not an algorithmic one. If the allocation only allows for one LAN, I start worrying about proxy neighbor discovery and how best to handle a residential network that isn't actually tree-structured - the wired LAN, the wireless LAN, the separate LAN for A/V equipment, his office, her office, and so on, and noting that the wireless goes places the wired doesn't in weird and wonderful ways. If in the general case we make it simple for a residential/SOHO router to handle those issues (which a /60 would do in the vast majority of cases), I think we have done the world a favor - we have simplified the router, we have given users lots of options, the technology is predictable within that domain, the ISP can aggregate lotsa teeny subnets within its /32-or-whatever, and the net result is a good thing.

News flash: I'm going to go on record as disagreeing with Tony here. Tony, if I can paraphrase him, would like to see every ISP customer get 2^16 subnets because that "might be useful in the future". He has argued in the past that a mobile phone connected to a cell tower should get a /48 because it might have a LAN behind it. He points to IEEE 802.15.4 deployment in the Home Area Network, which is generally a mesh network technology. To turn it into a traditional network, it will need a lot of subnets. But it will need a lot more than that. Zigbee SEP 2.0 isn't a traditional IP network, and a 3GPP or LTE mobile phone with a LAN behind it isn't a gateway into anything that requires O(2^16) subnets to describe it. 

What I, were I an ISP, would want to do is provide my customers with a set of addressing capabilities at different price points. I certainly get that with respect to bandwidths and other service offerings. I would like to avoid deployment of residential/SOHO /64's, and I would like to avoid residential deployment of stateful NAT as we have done with IPv4 - address amplification is not needed in IPv6 and NAT technology has closed a lot of markets it's in the ISP's interest to open. I don't see any problem with my ISP giving me options at /60, /56, /52, and /48 as part of various connection packages at various price points. And if I am a truly low end user and don't have a router in my home - I am deploying an Ethernet switch or wireless on the ISP access LAN - I don't see any reason why my devices couldn't be endpoints in that access subnet if the ISP wanted to see it that way.

If I were ARIN, I would tell my members that they should presume that their customers would appreciate a range of service offerings such as I described, and that the measure of how well they have used their IPv6 prefix will take into account the mechanisms they use to allocate it. Example, if one is looking for a new prefix, one has an old prefix that has been divided into /48, /52, /56, and /60 components, and the issue is that the /60 component is close to being used up, ARIN isn't going to force the ISP to renumber its customers before it can get the next chunk. 

I *would* recommend to ARIN that when it allocate a /32 to a member, it internally allocate a shorter prefix, so that the next allocation can turn the prefix into a /31 or whatever. And I *would* recommend that the initial allocation be sized based on the size of the member's existing IPv4 allocation - if the member can't describe their existing IPv4 network using the initial IPv6 allocation, the result is ARIN's fault, not the member's. But those points are probably not relevant to this discussion.

From owen at delong.com  Thu Oct 14 19:24:49 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 14 Oct 2010 16:24:49 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CB781C0.1020507@townsley.net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
	<6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com>
	<4CB777FB.20102@townsley.net>
	<5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com>
	<4CB781C0.1020507@townsley.net>
Message-ID: <276CEBB5-9A12-4973-80FD-43BDFCE0435C@delong.com>


On Oct 14, 2010, at 3:18 PM, Mark Townsley wrote:

> On 10/14/10 11:48 PM, Owen DeLong wrote:
>> 
>> 
>> On Oct 14, 2010, at 2:36 PM, Mark Townsley wrote:
>> 
>>> On 10/14/10 11:06 PM, Owen DeLong wrote:
>>>> 
>>>> 
>>>> On Oct 14, 2010, at 1:51 PM, Lorenzo Colitti wrote:
>>>> 
>>>>> On Thu, Oct 14, 2010 at 8:02 AM, Owen DeLong <owen at delong.com> wrote:
>>>>> If you can get 6rd to fit in  single /16, then, perhaps we could consider allowing it to be permanent.
>>>>> 
>>>>> However, if ~3,000 ARIN members deploy 6rd /24s, then, you're talking about the vast majority of an entire /12 just in the ARIN region.
>>>>> 
>>>>> Why not we make it a /28, and thus give the customer a /60? The customer still gets 16 subnets for his house, and when 6rd goes away (since, as you point out there are other disadvantages beyond address space use compared to native IPv6), then the subnet will be /56 (since, following your reasoning, that is what competitors with native IPv6 access will be providing).
>>>>> 
>>>> /60s are horrible... They completely stifle any ability for the customer to do PD-based topology
>>>> within the site.
>>> I think you are assuming what the PD-based topology mechanisms are going to be. They haven't really been designed, and certainly haven't been coded and shipped yet. All we are doing at this point is providing a playing field. Within that field:
>>> 
>>> /60 is an *enormous* improvement over /64. Night and day.
>>> 
>>> /56 is certainly better than /60, but not night and day as with /64 and /60. 
>>> 
>>> The point here is that if we design home routing and PD for 2^4 subnets, it's not hard to take that and extend it for 2^8 or 2^16. Not so if you are starting with 2^1.
>>> 
>> With all due respect, I must strongly disagree here. Whatever we decide here will likely impact and set the standards by which home gateways are designed going forward.
>> 
>> We agree that /64 is a non-starter.
>> 
>> I strongly believe that the target should be /48.
> Aren't ARIN's own guidelines:
> 
> "/56 for small sites, those expected to need only a few subnets over the next 5 years."
> 
Yes. That's a guideline that was passed early on. In fact, it's one I supported at the time.

We all make mistakes as we learn. 

> But I suppose you will explain to me why that text doesn't say what I think it says.
> 
Nope... It says what you think it says. However, note also that the IETF recommendation
is /48 and that ARIN does allow for /48 to all end sites regardless of size.

> In any case, based even on what I am hearing from folks with large-scale native plans in place, I wouldn't hold my breadth that your target will be reached. 
> 
Well... I think the largest end-user base on IPv6 today (outside of some private cable networks in Japan) is giving any customer that requests one a /48.

It's at least a start.

You really should have a conversation with Tony Hain about the reasons he thinks /56 is a bad idea.
He makes a pretty compelling case.

>> That 6rd has such terrible deficiencies in its use of address space that we cannot afford /48 and therefore must compromise to /56.
>> 
>> Further compromising to /60 runs the risk of that becoming a de facto industry standard which will potentially be very difficult to overcome.
> You are worried about /60 when the real worry is /64. 

I'm worried about both /60 and /64.

>> 
>> You asked me to tell you if you are contradicting someone from your organization... You are contradicting Tony
>> Hain here, or, at least my understanding of what Tony has been saying.
> Thanks for the heads up.
> 
>>> Consumer products will be designed to operate within the lowest common denominator of the above. If we can make that /60 vs. /64, that's a big win and we might see some potential for upsell into /56 for "bigger home networks". But, if we have to do a ton of work to make networks work within a single /64 anyway, once we have done that, it's hard to argue for supporting multiple subnets as well. I'm trying to avoid having to do the work at all for /64, but that can only happen if I know the minimum number of subnets in the home is greater than 1. 
>>> 
>> That is, indeed, the source of my concern. If consumer products are developed only to the lowest common denominator,
>> we risk establishing /60 as that point. /56 is bad enough. As I have said, we should strongly encourage /48 as the
>> standard around which development occurs while recognizing /56 as a necessary limitation of 6rd.
> /60 could at least have the same type of design as /56 and operate within both with different scaling levels. Supporting /64, even for the simple day one task of a guest and local SSID, is so radically different that this couldn't happen. 
> 
I have never supported /64. I'm not sure why you keep coming back to that.

For some time, now, I have advocated /48. In this conversation I've accepted the reality that /48s are not feasible
with 6rd due to the incredible waste in 6rd addressing. As such, I think /56 is the best available compromise for
6rd.

> There is step function of complexity at /64. 
> 
No argument. I've NEVER supported the idea of /64 for end sites.

>> 
>> I don't think we are disagreeing here, and I don't think anyone is advocating /64s. The AC has approved and forwarded
>> to last call policy which enables /56s for 6rd, but, encourages treating those as temporary and transitional in nature.
>> I think this is the best compromise.
> I'm not going to stand in the way of /24 for 6rd, but if it comes with a ton of strings attached, I'd rather see a less encumbered /28. 
> 
I won't support any size prefix less encumbered than the current draft policy sent to last call by the AC.
The encumbrances stated are due to the nature of 6rd and not the prefix size.

Owen

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

From alh-ietf at tndh.net  Thu Oct 14 20:11:00 2010
From: alh-ietf at tndh.net (Tony Hain)
Date: Thu, 14 Oct 2010 17:11:00 -0700
Subject: [arin-ppml] Controlling the IPv6 address consumption rate
In-Reply-To: <AANLkTikQqyg8508hSUbxM5gMp=_BSuf41jaRByztaGuh@mail.gmail.com>
References: <AANLkTik+5zsTzepnf40faZVgOxNF2OOeMt-3o4p2wLEw@mail.gmail.com>	<2B6D8499-377A-40FF-8263-79C6A3BFD3AE@delong.com>
	<AANLkTikQqyg8508hSUbxM5gMp=_BSuf41jaRByztaGuh@mail.gmail.com>
Message-ID: <015001cb6bfd$92ebb590$b8c320b0$@net>

William Herrin wrote:
> ...
> We badly underestimated at the start of IPv4.

You know, it would really be a good idea to understand history before
spouting inaccuracies on the list.

Believe it or not, there were serious concerns about the size of the routing
table way back when. From the perspective of current technology and policy
it might appear that people underestimated, but I challenge you to be honest
about making a different decision when faced with the constraints of that
time period. I was one of the people doing technical reviews for address
requests, and impact on the routing system was often a bigger concern than
then actual number of end systems in hand, let alone growth projections.

> I'd be more comfortable starting with a more
> conservative number (like 12 or 16) and then working down to 8 bits of
> conservation after we gain a decade or two of experience.
> 
> On the other hand, if the current address consumption rate holds at
> what eyeballs to me vaguely like 0.6(n^2), 8 bits of conservation
> should buy us around 115 years. If Geoff is lurking, I'm sure he can
> provide better information assuming completion of the IPv6 transition
> with IPv6 consumption at 1/256th of IPv4's current consumption and the
> same consumption growth rate exhibited over the last 15 years in IPv4.

There is no reasonable way to compare the IPv4 host based consumption
against the IPv6 lan based consumption. At best you could try to correlate
an IPv4 customer unit at /32 with an IPv6 customer unit at /48, but given
that almost every provider explicitly disassociates the number of IPv4 /32's
from the number of customers, that is an impossible task.

> 
> Anyway, let's run with 8 bits and see what it implies.
> 
> 8 bits means that the maximum allocation we can allow a single
> organization to seek both initially and due to prior consumption is
> /20. The largest holding we can allow an affiliated set of
> organizations (including merged and acquired ISPs) totals /16. The
> 4-bit difference comes from that hold-against-development set I talked
> about. Larger allocations than this, regardless of cause, are likely
> to see us deplete the IPv6 free pool faster than the 8-bits
> conservation target we've set.

And exactly where are those very large providers going to find customers to
consume that space? Seriously, equating anything about IPv4 growth rate,
which has a hard tie to end devices, with an IPv6 prefix per customer unit
is a waste of time. 

> 
> 8 bits also means you have only 14 bits left for the nice-to-haves. If
> you spend 12 of those bits bringing the downstream end-user assignment
> from the austere /60 to your preferred /48, you'll have only 2 bits
> left. That doesn't give you much flexibility with your routing. Are
> you sure you wouldn't rather put 4 of your bits to bring the
> assignment up to /56 and use the remaining 10 to do smarter things
> with your routing hierarchies? 256 LANs is a lot of LANs for all but
> the largest customers.

You assume that the end user has a network manager that is trained in
network design. Figure out how to do a plug-n-play model with a sparse
matrix of maybe 16 live subnets, but you can't constrain the topology that a
random end user might build. Then figure out the set of simple rules that
will allow every cpe vendor to ship a self-configuring device that plays in
that sparse matrix without a network manager or a support call. Stop
assuming that every environment has the constraints of an IPv4 enterprise
and/or isp with conservation being top priority. 

Tony







From alh-ietf at tndh.net  Thu Oct 14 20:11:00 2010
From: alh-ietf at tndh.net (Tony Hain)
Date: Thu, 14 Oct 2010 17:11:00 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>	<4CB5E076.7000701@townsley.net>	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>	<4CB6F929.3080207@townsley.net>	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>	<4CB707F7.9020506@townsley.net>	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>	<6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com>	<4CB777FB.20102@townsley.net>
	<5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com>
Message-ID: <015201cb6bfd$97e9a200$c7bce600$@net>

This entire thread is basically hot air swirling after more hot air......
While more traffic is good, this noise is a waste of everyone's time.

 

1)            The 6rd policy needs to be really simple and easy to get NOW.

2)            Assuring it goes away at some point requires appropriate
feedback to drive people away from it as soon as they can move.

 

Satisfying both of those should be easy. Establish a policy that says anyone
with IPv4 can get an IPv6 prefix between /16 & /24 as they see fit, then set
a  proportional fee schedule with a *substantial* escalation factor over
time.  

 

You don't need sunset clauses in the policy, and you don't need to
complicate things by obsessing about 'waste'. What you do need is a policy
that enables deployment TODAY. For those that need 6rd because they didn't
get their act together to enable a dual-stack infrastructure, there is a
cost to that delay, and the cost continues to grow until they get past their
legacy equipment. 

 

The hardest part of that approach is that the fee for a provider that is
offering dual-stack /48 to each customer should be substantially less than a
6rd deployment offering /60. It is not ARIN's role to define end  product
offerings, so differentiating the fee schedule for 2 ISPs requesting a /28
based on how they plan to use it is probably out of the question. That said,
financial backpressure will be much more effective than any proscriptive
language that makes it past ppml. We just need to make sure that there are
no unintended consequences related to consumer network innovation due to big
players opting for blocks that are too small.

 

Tony

 

 

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Owen DeLong
Sent: Thursday, October 14, 2010 2:49 PM
To: Mark Townsley
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Opposed to 2010-9 and 2010-12

 

 

On Oct 14, 2010, at 2:36 PM, Mark Townsley wrote:

 

On 10/14/10 11:06 PM, Owen DeLong wrote: 

 

On Oct 14, 2010, at 1:51 PM, Lorenzo Colitti wrote:

 

On Thu, Oct 14, 2010 at 8:02 AM, Owen DeLong <owen at delong.com> wrote:

If you can get 6rd to fit in  single /16, then, perhaps we could consider
allowing it to be permanent.

 

However, if ~3,000 ARIN members deploy 6rd /24s, then, you're talking about
the vast majority of an entire /12 just in the ARIN region.

 

Why not we make it a /28, and thus give the customer a /60? The customer
still gets 16 subnets for his house, and when 6rd goes away (since, as you
point out there are other disadvantages beyond address space use compared to
native IPv6), then the subnet will be /56 (since, following your reasoning,
that is what competitors with native IPv6 access will be providing).

 

/60s are horrible... They completely stifle any ability for the customer to
do PD-based topology

within the site.

I think you are assuming what the PD-based topology mechanisms are going to
be. They haven't really been designed, and certainly haven't been coded and
shipped yet. All we are doing at this point is providing a playing field.
Within that field:

/60 is an *enormous* improvement over /64. Night and day.

/56 is certainly better than /60, but not night and day as with /64 and /60.


The point here is that if we design home routing and PD for 2^4 subnets,
it's not hard to take that and extend it for 2^8 or 2^16. Not so if you are
starting with 2^1.

With all due respect, I must strongly disagree here. Whatever we decide here
will likely impact and set the standards by which home gateways are designed
going forward.

 

We agree that /64 is a non-starter.

 

I strongly believe that the target should be /48. That 6rd has such terrible
deficiencies in its use of address space that we cannot afford /48 and
therefore must compromise to /56.

 

Further compromising to /60 runs the risk of that becoming a de facto
industry standard which will potentially be very difficult to overcome.

 

You asked me to tell you if you are contradicting someone from your
organization... You are contradicting Tony

Hain here, or, at least my understanding of what Tony has been saying.

 

Consumer products will be designed to operate within the lowest common
denominator of the above. If we can make that /60 vs. /64, that's a big win
and we might see some potential for upsell into /56 for "bigger home
networks". But, if we have to do a ton of work to make networks work within
a single /64 anyway, once we have done that, it's hard to argue for
supporting multiple subnets as well. I'm trying to avoid having to do the
work at all for /64, but that can only happen if I know the minimum number
of subnets in the home is greater than 1. 

That is, indeed, the source of my concern. If consumer products are
developed only to the lowest common denominator,

we risk establishing /60 as that point. /56 is bad enough. As I have said,
we should strongly encourage /48 as the

standard around which development occurs while recognizing /56 as a
necessary limitation of 6rd.

 

I don't think we are disagreeing here, and I don't think anyone is
advocating /64s. The AC has approved and forwarded

to last call policy which enables /56s for 6rd, but, encourages treating
those as temporary and transitional in nature.

I think this is the best compromise.

 

Owen

 

- Mark



 

I would point out that the only ISP I am aware of that is conducting
residential trials of IPv6 seems to be talking about giving only a /64 to
the home by default due to CPE issues. To me, that is a much greater problem
than having a /60 instead of a /56, because with a /64 you can't do any
subnetting at all.

 

True... /64 should be even more discouraged than /60, but, the reality is
that we should look at

/56 as a temporary expedient due to inefficiencies in 6rd and consider /48
the norm.

 

Owen

 

 

 

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

From alh-ietf at tndh.net  Thu Oct 14 20:11:00 2010
From: alh-ietf at tndh.net (Tony Hain)
Date: Thu, 14 Oct 2010 17:11:00 -0700
Subject: [arin-ppml] Controlling the IPv6 address consumption rate
In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B4239378EABD9@EMV01-UKBR.domain1.systemhost.net>
References: <AANLkTik+5zsTzepnf40faZVgOxNF2OOeMt-3o4p2wLEw@mail.gmail.com>	<2B6D8499-377A-40FF-8263-79C6A3BFD3AE@delong.com>	<AANLkTikQqyg8508hSUbxM5gMp=_BSuf41jaRByztaGuh@mail.gmail.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B4239378EABD9@EMV01-UKBR.domain1.systemhost.net>
Message-ID: <014f01cb6bfd$90c74ef0$b255ecd0$@net>

michael.dillon wrote:
> ...
> It is the /56 prefix that is non-standard and this appeared in policy
> because cable companies have to address every house that they pass,
> not just the ones that they connect. 

Well we can debate this, but it is less about the number of houses passed,
and more about the insane interpretation that every ISP in the ARIN region
should have a /32. The MSO design could easily have shown homes passed @ /48
=> /18, but people's heads are still too stuck in the IPv4 stewardship ==
strangulation mindset to allow sane IPv6 allocations.

Tony


> The /56 was introduced as an
> OPTIONAL standard assignment for residential users.
> 
> Of course people can shoot themselves in the foot with even longer
> prefixed is they want to, but that should not be part of this kind of
> analysis.
> 
> Quite frankly, after seeing your statement above, I didn't read the
> rest of your analysis nor did I even bother to check whether your
> analysis is meaningful in any way.
> 
> --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 alh-ietf at tndh.net  Thu Oct 14 20:11:00 2010
From: alh-ietf at tndh.net (Tony Hain)
Date: Thu, 14 Oct 2010 17:11:00 -0700
Subject: [arin-ppml] Controlling the IPv6 address consumption rate
In-Reply-To: <AANLkTik+5zsTzepnf40faZVgOxNF2OOeMt-3o4p2wLEw@mail.gmail.com>
References: <AANLkTik+5zsTzepnf40faZVgOxNF2OOeMt-3o4p2wLEw@mail.gmail.com>
Message-ID: <015101cb6bfd$961668a0$c24339e0$@net>

William Herrin wrote:
>...
> First, IPv6's protocol design robs us of 64 bits. 

BS !!!!!!!!  it is time you actually looked at the history and realized that
there is no satisfying the routing side of this problem space. The original
design was 64 bits in total, but the routing world couldn't find enough room
for themselves if they allowed any space for those pesky end users, so the
design was revised to give the entire 64 bits to routing. We argued for
quite awhile about how many more bits to add for hosts, and after picking 64
to align with emerging cpu widths found it was possible to allow simplified
addressing using slaac. 

Fast forward, and at every turn the routing community whines about 'waste',
yet they are not able to actually deal with 18,446,744,073,709,551,616 entry
RIB's, so giving them more bits is the real path to waste. Get over it...

Tony



From farmer at umn.edu  Thu Oct 14 20:49:03 2010
From: farmer at umn.edu (David Farmer)
Date: Thu, 14 Oct 2010 19:49:03 -0500
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <71B9FB76-4718-48B1-8185-B06CAD4705C6@cisco.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>	<4CB5E076.7000701@townsley.net>	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>	<4CB6F929.3080207@townsley.net>	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>	<4CB707F7.9020506@townsley.net>	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>	<6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com>	<4CB777FB.20102@townsley.net>	<5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com>	<4CB781C0.1020507@townsley.net>
	<71B9FB76-4718-48B1-8185-B06CAD4705C6@cisco.com>
Message-ID: <4CB7A4FF.8050509@umn.edu>

On 10/14/10 18:22 CDT, Fred Baker wrote:
>
> On Oct 14, 2010, at 3:18 PM, Mark Townsley wrote:
>
>>> You asked me to tell you if you are contradicting someone from your organization... You are contradicting Tony Hain here, or, at least my understanding of what Tony has been saying.
>>
>> Thanks for the heads up.
>
>> From my perspective, in the equipment, the question is "do I assume that the ISP will give me a prefix that allows for multiple subnets, or do I assume that the ISP will give me a /64". Once you say "more than one", "how many" is a configuration issue, not an algorithmic one. If the allocation only allows for one LAN, I start worrying about proxy neighbor discovery and how best to handle a residential network that isn't actually tree-structured - the wired LAN, the wireless LAN, the separate LAN for A/V equipment, his office, her office, and so on, and noting that the wireless goes places the wired doesn't in weird and wonderful ways. If in the general case we make it simple for a residential/SOHO router to handle those issues (which a /60 would do in the vast majority of cases), I think we have done the world a favor - we have simplified the router, we have given users lots of options, the technology is predictable within that domain, the ISP can aggregate lotsa teeny sub
ne
>   ts within its /32-or-whatever, and the net result is a good thing.
>
> News flash: I'm going to go on record as disagreeing with Tony here. Tony, if I can paraphrase him, would like to see every ISP customer get 2^16 subnets because that "might be useful in the future". He has argued in the past that a mobile phone connected to a cell tower should get a /48 because it might have a LAN behind it. He points to IEEE 802.15.4 deployment in the Home Area Network, which is generally a mesh network technology. To turn it into a traditional network, it will need a lot of subnets. But it will need a lot more than that. Zigbee SEP 2.0 isn't a traditional IP network, and a 3GPP or LTE mobile phone with a LAN behind it isn't a gateway into anything that requires O(2^16) subnets to describe it.
>
> What I, were I an ISP, would want to do is provide my customers with a set of addressing capabilities at different price points. I certainly get that with respect to bandwidths and other service offerings. I would like to avoid deployment of residential/SOHO /64's, and I would like to avoid residential deployment of stateful NAT as we have done with IPv4 - address amplification is not needed in IPv6 and NAT technology has closed a lot of markets it's in the ISP's interest to open. I don't see any problem with my ISP giving me options at /60, /56, /52, and /48 as part of various connection packages at various price points. And if I am a truly low end user and don't have a router in my home - I am deploying an Ethernet switch or wireless on the ISP access LAN - I don't see any reason why my devices couldn't be endpoints in that access subnet if the ISP wanted to see it that way.

So from an ARIN policy perspective, without making a massively 
complicated policy that accounts for all of those different sizes, we 
need to assume an ISP's customers could all have /48s.  Right?  Beyond 
that, multi-site customers in theory could have a /48 per site in their 
network.

I don't want ARIN policy dictating /48s per site to the ISPs, but it 
needs to allow for it.  Also, I think it is best if we can avoid 
embedding technology specifics limits into ARIN policy, like mobile ISPs 
can only have a /60 per customer.   However, we can't realistically do 
that for 6rd.  This is especially true, if ISPs wants to encode the full 
32 bit IPv4 address in the IPv6 address.  A /56 is about the most that 
can reasonably be allowed for with 6rd with the full 32 bit IPv4 
address, which comes out to a /24.

More generally, if you have any good ideas how we can make policy for 
ARIN that doesn't essentially set the upper bounds for what ISPs can do, 
I love to hear them.

> If I were ARIN, I would tell my members that they should presume that their customers would appreciate a range of service offerings such as I described, and that the measure of how well they have used their IPv6 prefix will take into account the mechanisms they use to allocate it. Example, if one is looking for a new prefix, one has an old prefix that has been divided into /48, /52, /56, and /60 components, and the issue is that the /60 component is close to being used up, ARIN isn't going to force the ISP to renumber its customers before it can get the next chunk.
>
> I *would* recommend to ARIN that when it allocate a /32 to a member, it internally allocate a shorter prefix, so that the next allocation can turn the prefix into a /31 or whatever. And I *would* recommend that the initial allocation be sized based on the size of the member's existing IPv4 allocation - if the member can't describe their existing IPv4 network using the initial IPv6 allocation, the result is ARIN's fault, not the member's. But those points are probably not relevant to this discussion.

Essentially that is the current policy, but that doesn't work for 6rd, 
at least the way most ISPs want to deploy it, with the full 32 bit IPv4 
address encoded in the IPv6 address.   So if you provider customers 
/60s, ISPs need /28s, or /56s for customers, ISPs need /24.   After that 
I start getting week in the knees. :)

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


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


From lorenzo at google.com  Thu Oct 14 20:49:30 2010
From: lorenzo at google.com (Lorenzo Colitti)
Date: Thu, 14 Oct 2010 17:49:30 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <276CEBB5-9A12-4973-80FD-43BDFCE0435C@delong.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
	<6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com>
	<4CB777FB.20102@townsley.net>
	<5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com>
	<4CB781C0.1020507@townsley.net>
	<276CEBB5-9A12-4973-80FD-43BDFCE0435C@delong.com>
Message-ID: <AANLkTikOMdVo3mXw=4qhHO_upi7U4NUwtA000yS48Opa@mail.gmail.com>

On Thu, Oct 14, 2010 at 4:24 PM, Owen DeLong <owen at delong.com> wrote:

> Well... I think the largest end-user base on IPv6 today (outside of some
> private cable networks in Japan) is giving any customer that requests one a
> /48.
>

No, the largest end-user base on IPv6 today is in France, uses 6rd, and
gives its users a /60.

The perfect is the enemy of the good.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101014/d38a4eec/attachment.htm>

From wireless at starbeam.com  Thu Oct 14 21:07:30 2010
From: wireless at starbeam.com (Jerry Bacon)
Date: Thu, 14 Oct 2010 18:07:30 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org><2376C0DA-2491-40D4-B509-8C643C507A61@delong.com><4CB5E076.7000701@townsley.net><0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net><4CB6F929.3080207@townsley.net><0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net><4CB707F7.9020506@townsley.net><D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com><AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com><6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com><4CB777FB.20102@townsley.net><5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com><4CB781C0.1020507@townsley.net><276CEBB5-9A12-4973-80FD-43BDFCE0435C@delong.com>
	<AANLkTikOMdVo3mXw=4qhHO_upi7U4NUwtA000yS48Opa@mail.gmail.com>
Message-ID: <7111F963B7D04CA1B104451167822F80@user6006cfcba1>

I know that most of you are going to think this is absolute heresy, but I don't really think that most consumers will care one iota whether they get a /64 or anything larger. If they plug in their devices  and they are able to do whatever they want to on the Internet (both IPv4 and IPv6) they could care less about the technical details and how it could be "better".

-- 
Jerry Bacon
StarTouch, Inc.
Ferndale WA

  ----- Original Message ----- 


  On Thu, Oct 14, 2010 at 4:24 PM, Owen DeLong <owen at delong.com> wrote:

    Well... I think the largest end-user base on IPv6 today (outside of some private cable networks in Japan) is giving any customer that requests one a /48.

  No, the largest end-user base on IPv6 today is in France, uses 6rd, and gives its users a /60.


  The perfect is the enemy of the good.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101014/37a9d883/attachment.htm>

From bill at herrin.us  Thu Oct 14 21:24:37 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 14 Oct 2010 21:24:37 -0400
Subject: [arin-ppml] Controlling the IPv6 address consumption rate
In-Reply-To: <015001cb6bfd$92ebb590$b8c320b0$@net>
References: <AANLkTik+5zsTzepnf40faZVgOxNF2OOeMt-3o4p2wLEw@mail.gmail.com>
	<2B6D8499-377A-40FF-8263-79C6A3BFD3AE@delong.com>
	<AANLkTikQqyg8508hSUbxM5gMp=_BSuf41jaRByztaGuh@mail.gmail.com>
	<015001cb6bfd$92ebb590$b8c320b0$@net>
Message-ID: <AANLkTinQo81_U0jRvGi98=epVX7m=JPjqCCHNyrmR6cG@mail.gmail.com>

On Thu, Oct 14, 2010 at 8:11 PM, Tony Hain <alh-ietf at tndh.net> wrote:
> William Herrin wrote:
>> First, IPv6's protocol design robs us of 64 bits.
>
> BS !!!!!!!!

Tony,

64 bits of IPv6's address space aren't dedicated to the LAN before
routing begins?

> The original
> design was 64 bits in total, but the routing world couldn't find enough room
> for themselves if they allowed any space for those pesky end users, so the
> design was revised to give the entire 64 bits to routing.

Hokay. Sure. Did it offend you that I described that I described the
local LAN as robbing from routing? Would you prefer something along
the lines of, "From the routing perspective, IPv6 is only 64 bits
large, not 128?" I humbly apologize for my choice of words.

> it is time you actually looked at the history and realized that
> there is no satisfying the routing side of this problem space.

Precisely. So if we don't want to burn through the space in 20 years,
we'd best recognize that nagging little problem and exercise some
caution, yes?


>> 8 bits also means you have only 14 bits left for the nice-to-haves. If
>> you spend 12 of those bits bringing the downstream end-user assignment
>> from the austere /60 to your preferred /48, you'll have only 2 bits
>> left. That doesn't give you much flexibility with your routing. Are
>> you sure you wouldn't rather put 4 of your bits to bring the
>> assignment up to /56 and use the remaining 10 to do smarter things
>> with your routing hierarchies? 256 LANs is a lot of LANs for all but
>> the largest customers.
>
> You assume that the end user has a network manager that is trained in
> network design.

I do? As near as I can figure, my assumptions about the end user's use
are that an assignment offering fewer addresses than a /60 won't work
out well and that over the lifespan of IPv6 each person on the planet
will consume at least one assignment. If you've read something more
about end users in my statement, you might not be tracking with what I
actually wrote.

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 joelja at bogus.com  Thu Oct 14 21:32:40 2010
From: joelja at bogus.com (Joel Jaeggli)
Date: Thu, 14 Oct 2010 18:32:40 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <7111F963B7D04CA1B104451167822F80@user6006cfcba1>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org><2376C0DA-2491-40D4-B509-8C643C507A61@delong.com><4CB5E076.7000701@townsley.net><0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net><4CB6F929.3080207@townsley.net><0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net><4CB707F7.9020506@townsley.net><D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com><AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com><6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com><4CB777FB.20102@townsley.net><5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com><4CB781C0.1020507@townsley.net><276CEBB5-9A12-4973-80FD-43BDFCE0435C@delong.com>	<AANLkTikOMdVo3mXw=4qhHO_upi7U4NUwtA000yS48Opa@mail.gmail.com>
	<7111F963B7D04CA1B104451167822F80@user6006cfcba1>
Message-ID: <4CB7AF38.8010108@bogus.com>

On 10/14/10 6:07 PM, Jerry Bacon wrote:
> I know that most of you are going to think this is absolute heresy, but
> I don't really think that most consumers will care one iota whether they
> get a /64 or anything larger. If they plug in their devices  and they
> are able to do whatever they want to on the Internet (both IPv4 and
> IPv6) they could care less about the technical details and how it could
> be "better".

Uh, yeah, and that's why you need automatic prefix delegation and a big
enough prefix to work with becuase the alternative is a stack of event
horizons which are a pain in the ass to work around just as in ipv4.
subnetting does not have to require human intervention, just ask all the
people who have stacked more than one wireless "router" in their home in
the ipv4 case....

joel

> -- 
> Jerry Bacon
> StarTouch, Inc.
> Ferndale WA
> 
>     ----- Original Message -----
> 
>     On Thu, Oct 14, 2010 at 4:24 PM, Owen DeLong <owen at delong.com
>     <mailto:owen at delong.com>> wrote:
> 
>         Well... I think the largest end-user base on IPv6 today (outside
>         of some private cable networks in Japan) is giving any customer
>         that requests one a /48.
> 
>      
>     No, the largest end-user base on IPv6 today is in France, uses 6rd,
>     and gives its users a /60.
> 
>     The perfect is the enemy of the good.
>      
> 
> 
> 
> _______________________________________________
> 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 marka at isc.org  Thu Oct 14 22:13:29 2010
From: marka at isc.org (Mark Andrews)
Date: Fri, 15 Oct 2010 13:13:29 +1100
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: Your message of "Thu, 14 Oct 2010 17:11:00 PDT."
	<015201cb6bfd$97e9a200$c7bce600$@net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
	<6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com>
	<4CB777FB.20102@townsley.net>
	<5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com>
	<015201cb6bfd$97e9a200$c7bce600$@net>
Message-ID: <20101015021329.A0BD55B5B43@drugs.dv.isc.org>


In message <015201cb6bfd$97e9a200$c7bce600$@net>, "Tony Hain" writes:
> This entire thread is basically hot air swirling after more hot air......
> While more traffic is good, this noise is a waste of everyone's time.
> 
>  
> 
> 1)            The 6rd policy needs to be really simple and easy to get NOW.
> 
> 2)            Assuring it goes away at some point requires appropriate
> feedback to drive people away from it as soon as they can move.
> 
>  
> 
> Satisfying both of those should be easy. Establish a policy that says anyone
> with IPv4 can get an IPv6 prefix between /16 & /24 as they see fit, then set
> a  proportional fee schedule with a *substantial* escalation factor over
> time.  
> 
>  
> 
> You don't need sunset clauses in the policy, and you don't need to
> complicate things by obsessing about 'waste'. What you do need is a policy
> that enables deployment TODAY. For those that need 6rd because they didn't
> get their act together to enable a dual-stack infrastructure, there is a
> cost to that delay, and the cost continues to grow until they get past their
> legacy equipment. 
> 
>  
> 
> The hardest part of that approach is that the fee for a provider that is
> offering dual-stack /48 to each customer should be substantially less than a
> 6rd deployment offering /60. It is not ARIN's role to define end  product
> offerings, so differentiating the fee schedule for 2 ISPs requesting a /28
> based on how they plan to use it is probably out of the question. That said,
> financial backpressure will be much more effective than any proscriptive
> language that makes it past ppml. We just need to make sure that there are
> no unintended consequences related to consumer network innovation due to big
> players opting for blocks that are too small.
> 
>  
> 
> Tony

I would suggest that ARIN allocate space per IPv4 /8 that address
space has been allocated from.  That's a /32 per /8 that contains
allocation instead of a /24.  For manual configuration you would
look at the first octet of your IPv4 address and pick the associated
6rd prefix.  This is still very wasteful but no where near as
wasteful as handing out /24's.

For CMCS (Comcast Cable Communications) they would the have 10 blocks
of space and 10 6rd prefixes.  Do you think Comcast's network
engineers can cope with 10 6rd prefixes?  I sure do.

Mark

(NET-24-0-0-0-1)        24.0.0.0 - 24.15.255.255
(NET-24-16-0-0-1)       24.16.0.0 - 24.23.255.255
(NET-24-189-152-0-1)    24.189.152.0 - 24.189.155.255
(NET-24-228-96-0-1)     24.228.96.0 - 24.228.127.255

(NET-67-160-0-0-1)      67.160.0.0 - 67.191.255.255
(NET-67-85-60-0-1)      67.85.60.0 - 67.85.63.255

(NET-68-32-0-0-1)       68.32.0.0 - 68.63.255.255
(NET-68-80-0-0-1)       68.80.0.0 - 68.87.255.255

(NET-69-136-0-0-1)      69.136.0.0 - 69.143.255.255
(NET-69-240-0-0-1)      69.240.0.0 - 69.255.255.255

(NET-71-192-0-0-1)      71.192.0.0 - 71.207.255.255
(NET-71-224-0-0-1)      71.224.0.0 - 71.239.255.255

(NET-74-88-112-0-1)     74.88.112.0 - 74.88.115.255
(NET-74-88-96-0-1)      74.88.96.0 - 74.88.99.255

(NET-76-16-0-0-1)       76.16.0.0 - 76.31.255.255
(NET-76-96-0-0-1)       76.96.0.0 - 76.127.255.255

(NET-98-192-0-0-1)      98.192.0.0 - 98.255.255.255

(NET-107-0-0-0-1)       107.0.0.0 - 107.5.255.255

(NET-174-48-0-0-1)      174.48.0.0 - 174.63.255.255

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From lorenzo at google.com  Thu Oct 14 23:35:37 2010
From: lorenzo at google.com (Lorenzo Colitti)
Date: Thu, 14 Oct 2010 20:35:37 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <20101015021329.A0BD55B5B43@drugs.dv.isc.org>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
	<6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com>
	<4CB777FB.20102@townsley.net>
	<5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com>
	<015201cb6bfd$97e9a200$c7bce600$@net>
	<20101015021329.A0BD55B5B43@drugs.dv.isc.org>
Message-ID: <AANLkTi=9pkqS+T8L75tmHtb04UMexfj9+cM5Az+Tr8pi@mail.gmail.com>

On Thu, Oct 14, 2010 at 7:13 PM, Mark Andrews <marka at isc.org> wrote:

> I would suggest that ARIN allocate space per IPv4 /8 that address
> space has been allocated from.  That's a /32 per /8 that contains
> allocation instead of a /24.  For manual configuration you would
> look at the first octet of your IPv4 address and pick the associated
> 6rd prefix.  This is still very wasteful but no where near as
> wasteful as handing out /24's.
>
> For CMCS (Comcast Cable Communications) they would the have 10 blocks
> of space and 10 6rd prefixes.  Do you think Comcast's network
> engineers can cope with 10 6rd prefixes?  I sure do.
>

And in the future, when people are scrambling for bits and pieces of IPv4
space and ISPs end up with hundreds of small IPv4 prefixes from a dozen
different /8s? You can either give the customer IPv4 or 6rd but not both.
Guess which one you're going to choose.

Yes, it's possible to use multiple 6rd realms to support more users with
less address space, but it's not particularly pretty.

Assume you hand out a /56s to users and you have an IPv6 /32. You have 24
bits to play with. That's not enough bits for the whole IPv4 address, so if
you want to support more than one IPv4 prefix, you need multiple 6rd
realms. Each realm corresponds to an IPv4 prefix you have. So you need to
allocate X bits to number the realm (i.e., the IPv4 prefix) and Y bits to
the host in the prefix. X + Y = 24.

X must be big enough to represent all your prefixes. If you have 100
prefixes, X = 7.
Y must be big enough to represent the number of hosts in the largest prefix.
If your largest prefix is a /16, you have one bit left.

However, if in the future you want to do CGN and assign 10/8 to your
customers, you're out of luck, because for a /8, Y = 24.

You might be able to make it even more complex by using variable-length
realm IDs, but at that point your operators' heads start hurting and you
start to worry about whether your gear and your customers' CPEs support it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101014/067f6940/attachment.htm>

From fred at cisco.com  Fri Oct 15 00:52:00 2010
From: fred at cisco.com (Fred Baker)
Date: Thu, 14 Oct 2010 21:52:00 -0700
Subject: [arin-ppml] Controlling the IPv6 address consumption rate
In-Reply-To: <AANLkTinQo81_U0jRvGi98=epVX7m=JPjqCCHNyrmR6cG@mail.gmail.com>
References: <AANLkTik+5zsTzepnf40faZVgOxNF2OOeMt-3o4p2wLEw@mail.gmail.com>
	<2B6D8499-377A-40FF-8263-79C6A3BFD3AE@delong.com>
	<AANLkTikQqyg8508hSUbxM5gMp=_BSuf41jaRByztaGuh@mail.gmail.com>
	<015001cb6bfd$92ebb590$b8c320b0$@net>
	<AANLkTinQo81_U0jRvGi98=epVX7m=JPjqCCHNyrmR6cG@mail.gmail.com>
Message-ID: <7E753F8B-5518-4967-A73C-BA1E5E77FF78@cisco.com>


On Oct 14, 2010, at 6:24 PM, William Herrin wrote:

> Hokay. Sure. Did it offend you that I described that I described the
> local LAN as robbing from routing? Would you prefer something along
> the lines of, "From the routing perspective, IPv6 is only 64 bits
> large, not 128?" I humbly apologize for my choice of words.

I think there is a question of requirements. Hopefully I can say this without people throwing bricks.

The requirements IPv6 was developed against include but are not limited to 

http://www.ietf.org/rfc/rfc1726.txt
1726 Technical Criteria for Choosing IP The Next Generation (IPng). C.
     Partridge, F. Kastenholz. December 1994. (Format: TXT=74109 bytes)
     (Status: INFORMATIONAL)

That RFC states:

   CRITERION
      The IPng Protocol must scale to allow the identification and
      addressing of at least 10**12 end systems (and preferably much
      more).  The IPng Protocol, and its associated routing protocols
      and architecture must allow for at least 10**9 individual networks
      (and preferably more).  The routing schemes must scale at a rate
      that is less than the square root of the number of constituent
      networks [10].

      We note that one of the white papers solicited for the IPng
      process [5] indicates that 10**12 end nodes is a reasonable
      estimate based on the expected number of homes in the world and
      adding two orders of magnitude for "safety".  However, this white
      paper treats each home in the world as an end-node of a world-wide
      Internet.  We believe that each home in the world will in fact be
      a network of the world-wide Internet.  Therefore, if we take [5]'s
      derivation of 10**12 as accurate, and change their assumption that
      a home will be an end-node to a home being a network, we may
      expect that there will be the need to support at least 10**12
      networks, with the possibility of supporting up to 10**15 end-
      nodes.

      First and foremost, the routing architecture must scale to support
      a very large Internet.  Current expectations are for an Internet
      of about 10**9 to 10**12 networks.  The routing architecture must
      be able to deal with networks of this size.  Furthermore, the
      routing architecture must be able to deal with this size without
      requiring massive, global databases and algorithms.  Such
      databases or algorithms would, in effect, be single points of
      failure in the architecture (which is not robust), and because of
      the nature of Internet administration (cooperative anarchy), it
      would be impossible to maintain the needed consistency.

There are several numbers in there - 10^9, 10^12, and 10^15 figure prominently.

pulling out my trusty gonkulator, aka 'bc':

10^9
1000000000
10^12
1000000000000
10^15
1000000000000000
obase=16
10^9
3B9ACA00
10^12
E8D4A51000
10^15
38D7EA4C68000

so, 10^9 is a 30 bit number, 10^12 is a 40 bit number, and 10^15 is a 50 bit number. IPv6's original design basically was IPv4 with 64 bit addresses, and I think anybody looking at that would have agreed that, if addresses are handled the way they are handled in IPv4, it met the requirement. It allowed you to represent 10^9 or 10^12 networks (LANs) in the global Internet, and it allowed you to handle 10^12 or 10^15 systems in the global Internet.

What we wound up with separates the LAN identifier - the prefix by any other name - into one place, and puts the host identifier in another. You not only can represent at least 10^12 identifiable LANs (40 bits fits in 64), but allows you to fit at least 10^15 hosts (50 bits fits in 64) on each LAN.

Now, you can argue that the requirements were incorrect. If so, please advise: how many LANs in the world do you need to be able to individually enumerate, and what are your aggregation requirements? How many hosts per LAN? In the Smart Grid, we actually do have things that map to IP subnets that want to have O(10^5) hosts in them...

If you can't justify changing the requirement - if you can't show how 64 bits for the prefix just isn't enough, or 64 bits for the host identifier just isn't enough, or that the only way the address can be organized is the way it was done in IPv4, I have to say that your engineering requirements have been met. That happens to be what I personally believe. I'm sorry you don't like the way it was done. You weren't shortchanged.

From owen at delong.com  Fri Oct 15 02:12:49 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 14 Oct 2010 23:12:49 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <AANLkTikOMdVo3mXw=4qhHO_upi7U4NUwtA000yS48Opa@mail.gmail.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
	<6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com>
	<4CB777FB.20102@townsley.net>
	<5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com>
	<4CB781C0.1020507@townsley.net>
	<276CEBB5-9A12-4973-80FD-43BDFCE0435C@delong.com>
	<AANLkTikOMdVo3mXw=4qhHO_upi7U4NUwtA000yS48Opa@mail.gmail.com>
Message-ID: <DB92E04A-0CEE-442A-86D7-35E5B2AF9F71@delong.com>


On Oct 14, 2010, at 5:49 PM, Lorenzo Colitti wrote:

> On Thu, Oct 14, 2010 at 4:24 PM, Owen DeLong <owen at delong.com> wrote:
> Well... I think the largest end-user base on IPv6 today (outside of some private cable networks in Japan) is giving any customer that requests one a /48.
>  
> No, the largest end-user base on IPv6 today is in France, uses 6rd, and gives its users a /60.
> 
> The perfect is the enemy of the good.

With all due respect, I believe we actually have more tunnel users world-wide than Free.FR.

Owen

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

From lorenzo at google.com  Fri Oct 15 02:25:10 2010
From: lorenzo at google.com (Lorenzo Colitti)
Date: Thu, 14 Oct 2010 23:25:10 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <DB92E04A-0CEE-442A-86D7-35E5B2AF9F71@delong.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
	<6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com>
	<4CB777FB.20102@townsley.net>
	<5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com>
	<4CB781C0.1020507@townsley.net>
	<276CEBB5-9A12-4973-80FD-43BDFCE0435C@delong.com>
	<AANLkTikOMdVo3mXw=4qhHO_upi7U4NUwtA000yS48Opa@mail.gmail.com>
	<DB92E04A-0CEE-442A-86D7-35E5B2AF9F71@delong.com>
Message-ID: <AANLkTimvE6c+rf7SYxYM2QGnJsbDZhv6h3H95=q51TGv@mail.gmail.com>

On Thu, Oct 14, 2010 at 11:12 PM, Owen DeLong <owen at delong.com> wrote:

> With all due respect, I believe we actually have more tunnel users
> world-wide than Free.FR.
>

No, I don't think so.

http://tunnelbroker.net/usage/accounts_by_month.php says 120k accounts
http://tunnelbroker.net/usage/tunnels_by_tserv.php adds up to ~40k active
tunnels.

free.fr has 4M users with a /60 each. About 400k of these have opted in to
IPv6 Internet access (by default only free's internal applications use
IPv6).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101014/7da25d07/attachment.htm>

From marka at isc.org  Fri Oct 15 03:08:48 2010
From: marka at isc.org (Mark Andrews)
Date: Fri, 15 Oct 2010 18:08:48 +1100
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: Your message of "Thu, 14 Oct 2010 20:35:37 PDT."
	<AANLkTi=9pkqS+T8L75tmHtb04UMexfj9+cM5Az+Tr8pi@mail.gmail.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
	<6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com>
	<4CB777FB.20102@townsley.net>
	<5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com>
	<015201cb6bfd$97e9a200$c7bce600$@net>
	<20101015021329.A0BD55B5B43@drugs.dv.isc.org>
	<AANLkTi=9pkqS+T8L75tmHtb04UMexfj9+cM5Az+Tr8pi@mail.gmail.com>
Message-ID: <20101015070848.6A93A5B86A0@drugs.dv.isc.org>


In message <AANLkTi=9pkqS+T8L75tmHtb04UMexfj9+cM5Az+Tr8pi at mail.gmail.com>, Lore
nzo Colitti writes:
> --000e0cd47f1c54172104929f8666
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On Thu, Oct 14, 2010 at 7:13 PM, Mark Andrews <marka at isc.org> wrote:
> 
> > I would suggest that ARIN allocate space per IPv4 /8 that address
> > space has been allocated from.  That's a /32 per /8 that contains
> > allocation instead of a /24.  For manual configuration you would
> > look at the first octet of your IPv4 address and pick the associated
> > 6rd prefix.  This is still very wasteful but no where near as
> > wasteful as handing out /24's.
> >
> > For CMCS (Comcast Cable Communications) they would the have 10 blocks
> > of space and 10 6rd prefixes.  Do you think Comcast's network
> > engineers can cope with 10 6rd prefixes?  I sure do.
> 
> And in the future, when people are scrambling for bits and pieces of IPv4
> space and ISPs end up with hundreds of small IPv4 prefixes from a dozen
> different /8s?

You have dozens of 6rd prefixes.  The space to support a dozen 6rd prefixes
is still less than that required to encode all of IPv4 address space into
one 6rd prefix.

> You can either give the customer IPv4 or 6rd but not both.
> Guess which one you're going to choose.

Guess what.  All you customers can't get a public IPv4 address as
there are not enough to go around.  You will need to start giving
them to those that REQUIRE them and share the rest (NAT444 and
eventually DS-lite or start with DS-lite over 6rd so there is only
a single NAT translation in the IPv4 path).  Yes this is a paradigm
shift.

That doesn't mean that they can't all use 6rd while waiting for all
the of the required equipement to be upgraded to support 6rd natively.

The 6rd parameters for 10.0.0.0/8 and 193.0.0.0/8 are identical.  You
can just pack more customers into the 6rd prefix for 10.0.0.0/8 than
you can in 193.0.0.0/8 because you have all of 10.0.0.0/8.

> Yes, it's possible to use multiple 6rd realms to support more users with
> less address space, but it's not particularly pretty.

This proposal is not particularly messy.

> Assume you hand out a /56s to users and you have an IPv6 /32. You have 24
> bits to play with. That's not enough bits for the whole IPv4 address,

But it is big enough for all your customers that live in one /8.

> so if
> you want to support more than one IPv4 prefix, you need multiple 6rd
> realms. Each realm corresponds to an IPv4 prefix you have. So you need to
> allocate X bits to number the realm (i.e., the IPv4 prefix) and Y bits to
> the host in the prefix. X + Y = 24.
> 
> X must be big enough to represent all your prefixes. If you have 100
> prefixes, X = 7.
> Y must be big enough to represent the number of hosts in the largest prefix.
> If your largest prefix is a /16, you have one bit left.
> 
> However, if in the future you want to do CGN and assign 10/8 to your
> customers, you're out of luck, because for a /8, Y = 24.

You get a IPv6 /32 per IPv4 /8 that you have address space allocated in.
Add in a /32 for 10.0.0.0/8 which would be allocated under the existing
allocation policies.

> You might be able to make it even more complex by using variable-length
> realm IDs, but at that point your operators' heads start hurting and you
> start to worry about whether your gear and your customers' CPEs support it.

Your customers CPE gear will support it.  All the complicated parts are
on the ISP's end.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From michael.dillon at bt.com  Fri Oct 15 05:00:05 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 15 Oct 2010 10:00:05 +0100
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <1FFCDC31-4914-4F7A-9BB3-4B739A84E681@delong.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
	<4CB73624.1000309@townsley.net>
	<1FFCDC31-4914-4F7A-9BB3-4B739A84E681@delong.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B42393813423C@EMV01-UKBR.domain1.systemhost.net>

Would you two please stop this!!!
Either get an email client that supports proper quoting of messages or reformat
the lines with > characters manually. It is all but impossible to follow what
you two are saying in your fractured messages.

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Owen DeLong
> Sent: Thursday, October 14, 2010 8:06 PM
> To: Mark Townsley
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Opposed to 2010-9 and 2010-12
> 
> 
> On Oct 14, 2010, at 9:56 AM, Mark Townsley wrote:
> 
> 
> 	On 10/14/10 5:02 PM, Owen DeLong wrote:
> 
> 
> 			Classifying 6rd as a means to an end for native IPv6
> is an architectural statement, though one that is at least consistent
> with the 6rd RFC. Limiting the space which 6rd can run, however,
> presupposes how the transition from 6rd to native is to be done.
> 
> 
> 			From RFC 5969:
> 
> 			   The SP can choose to provision a separate IPv6
> address block for
> 			   native service, or reuse the 6rd prefix block
> itself.
> 
> 
> 
> 			An ARIN policy that requires moving to a different
> block is, by the letter, an IETF standards-track RFC violation.
> 
> 
> 
> 		However, this is not the first time the IETF has made the
> mistake of stepping over the line from Architectureal
> 		design to address policy. ARIN sets address policy for the
> ARIN service region, the IETF does not.
> 
> 		Another example of ARIN policy correcting this error on the
> part of IETF would be 2005-1, prior to which
> 		there was no facility for Provider Independent End User
> assignments in ANY region. Today there is
> 		policy to support those assignments in all 5 regions.
> 
> 
> 			I'm calling this out only to underscore that there
> are serious operational considerations with respect to allowing native
> and 6rd to coexist within the same prefix while moving to native.
> Considerations that could actually discourage movement to native by
> ISPs. We want it to be as easy as possible for ISPs to move to native
> IPv6 from 6rd. This is why this sentence exists in the RFC.
> 
> 
> 
> 		Yes... Those operational considerations are hazardous to
> address policy and would prevent any ability to
> 		ensure the eventual deprecation of this "transitional"
> technology at the expense of vast amounts of address
> 		space which would have been distributed in an excessively
> (even by IPv6 standards) wasteful manner.
> 
> 		I'm all for 6rd as a temporary fix, but, as a permanent
> institution, it is pretty awful. Even if we ignore the
> 		issue of deprecation and assume that providers would switch
> to native without additional motivation,
> 		allowing them to have their native and 6rd deployments to
> co-exist in the same space would result
> 		in sparse allocation of their native blocks across the
> oversized prefix granted for 6rd which would
> 		prevent future reclamation of that oversized prefix.
> 
> 
> 		By requiring the native deployments to go in a separate
> prefix which is more appropriately sized for
> 		the ISPs native deployment, we ensure the ability to
> eventually reclaim and re-use these oversized
> 		blocks for other purposes.
> 
> 	6rd is just getting deployed now, so precisely how to transition
> it to native is still speculative. But, I know that technically it is
> quite possible (with equipment that will be available in 2011, if not
> today) to allow 6rd and native exist alongside one another in a very
> transparent manner to the end-user. Native can be brought up (or back
> down if there is a problem) one CPE, one head-end or one DSLAM at a
> time in whatever order the network operations folks want without having
> to alert the customer-care folks that have to deal with IPv6 being
> renumbered within the house, nor dealing with the well-known issues of
> multihoming towards two disparate address blocks. Once, say, a region
> of the network has transitioned appropriately (something that may only
> happen after the last end-user goes out and buys the right CPE, or the
> operator deploys enough native gear), a move to a more aggregated space
> and disabling of 6rd within the region can be scheduled appropriately.
> Policy should not disallow nor even discourage such an approach.
> 
> 
> 
> Nothing in what I have proposed prevents that. The operator can use the
> 6rd space to do the transition and then renumber after the transition
> is done if they want. The key is not to believe that the 6rd space is
> in any way permanent.
> 
> The policy sent to last call by the AC merely requires that the 6rd
> allocations be done from a specific prefix for that purpose and conveys
> that the 6rd allocations are transitional and temporary in nature.
> It doesn't do anything to interfere with the approach you describe, so
> long as the provider does eventually get to that renumber point.
> 
> 
> 	Again, I'm trying to make it *easier* for the operator to move to
> native. I want the operator to have tools available to make that as
> easy as possible, with the fewest moving parts. The incentive to have
> native v6 customers within an aggregated space will still be there,
> even if native and 6rd interfaces are allowed to exist at the same
> time, but that move can be staged and scheduled with appropriate
> advance notice and care independent of getting the user on native as
> soon as physically possible.
> 
> 
> 
> We're in agreement there to a certain extent. However, it has to be
> done with responsible address management in mind as well. Making the
> 6rd prefixes permanent would be irresponsible.
> 
> 
> 	We agree that 6rd should be temporary. I think we even agree that
> it might take 10 years to move completely from 6rd to native. I'm even
> be OK with asking the provider to give back the block when they are
> done with it if we are demonstrably on track towards some new global
> IPv6 address exhaustion problem. We aren't far away from one another
> here.
> 
> 
> 
> Agreed.
> 
> 
> 
> 			Putting 6rd into a segregated block, in particular
> with the threat of that block expiring, only adds to deployment
> hurdles. Today, it would be one more thing that the poor person at the
> ISP that actually wants to see IPv6 deployed before the CGNs take over
> has to convince his or her management is not a future risk factor.
> Tomorrow, it could be one more hurdle for the ISP to renumber their
> IPv6 customer when moving to native.
> 
> 
> 
> 		There is no threat of that block expiring. The intent is to
> allow for a mechanism by which to signal the following:
> 
> 		1. Native deployments should go in a separate appropriately
> sized block.
> 		2. 6rd is temporary and transitional in nature. It is not
> to be considered permanent.
> 		Temporary in this case may well span a decade, but, there
> should eventually be an end date.
> 		3. The sooner you migrate your customers from 6rd to
> native, the better. There is value in pressuring
> 		your vendors to make this possible.
> 
> 	I think #2 and #3 are reasonable, and you don't need #1 to make
> that clear.
> 
> 
> 
> No, but, you do need #1 to make it possible to enforce #2 and #3 later.
> 
> 
> 
> 		The CGN FUD really is overplayed here. Even with this
> limitation, CGN remains far less attractive to
> 		any provider.
> 
> 	Then why are so many looking to buy them? Why the policy
> proposals for a shared-SP space?
> 
> 
> 
> There are no policy proposals for shared-SP space. There is an IETF
> draft. The IETF draft in question is generally opposed in the address
> policy community, to the best of my knowledge.
> Most of the discussions I've been involved in where it was a subject
> were about the number of different ways in which said draft was a bad
> idea.
> 
> Frankly, I'm betting that the providers that buy CGNs will be very
> dissatisfied with them in relatively short order. I also think that
> they will be encouraging their customers to switch to other providers.
> 
> 
> 		Even a provider which doesn't see this, I am pretty sure
> that their customers will see it
> 		in short order.
> 
> 
> 	I heard the same argument 10 years ago about the NAT the
> customers now claim they NEED. Perhaps your view is tainted by being so
> close to the IPv6-enabled world. From my vantage, we are still very
> much in a battle.
> 
> 
> 
> I tend to doubt it. NAT was pretty bad, but, CGN/LSN/whatever you want
> to call it is far less attractive from the SP and the customer
> perspective than NAT was. It's all the problems of NAT amplified many
> many times over with some additional new unique problems.
> 
> I think that the odds of CGN/LSN making it to wide-scale deployment are
> near zero.
> Notice that nobody has even tested CGN/LSN on real end users yet.
> 
> 
> 
> 			I'm all for facilitation. Let's focus on that rather
> than assuming we know how the operator is going to migrate from 6rd to
> native and encoding that in the ARIN policy.
> 
> 
> 
> 		The point of this aspect of the policy is not that we are
> assuming the operator will migrate. We are
> 		requiring that they eventually do. Allowing them to hang on
> to these oversized 6rd blocks beyond
> 		the point where a switch to native is practicable is not
> good stewardship of the address space.
> 
> 		If you can get 6rd to fit in  single /16, then, perhaps we
> could consider allowing it to be permanent.
> 
> 		However, if ~3,000 ARIN members deploy 6rd /24s, then,
> you're talking about the vast majority
> 		of an entire /12 just in the ARIN region. Since most of
> them could deploy native and give their
> 
> 	"most of them could deploy native"?? Wishing this to be true will
> not make it happen. The problem is that they evaluated deploying native
> and realized the could not and only then did we come along with 6rd and
> turn things around. That's where we are, like it or not. But I think
> you agree with this as your report on which technologies work and which
> do not on this thread was quite accurate.
> 
> 
> 
> You misunderstand me... I wasn't saying they can deploy native now. I
> was saying that once native is a possibility, the required address size
> for native is several orders of magnitude smaller while providing a
> couple of orders of magnitude more address space to their customers.
> 
> Please take this paragraph only in the context of measuring the
> relative address consumption/ unit of customer space and not as a
> statement of current abilities.
> 
> Owen
> 
> 
> 	- Mark
> 
> 
> 		customers much larger (256x) assignments and fit within
> 1/16th of the proposed address space
> 		for 6rd, (IOW, a 4096x gain in addressing efficiency), I
> believe that the ARIN community has
> 		a valid interest in ensuring that this is a temporary use
> of address resources.
> 
> 
> 
> 
> 
> 
> 		Owen
> 
> 
> 



From michael.dillon at bt.com  Fri Oct 15 05:08:28 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 15 Oct 2010 10:08:28 +0100
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423938134250@EMV01-UKBR.domain1.systemhost.net>


> Why not we make it a /28, and thus give the customer a /60? The
> customer still gets 16 subnets for his house, and when 6rd goes away
> (since, as you point out there are other disadvantages beyond address
> space use compared to native IPv6), then the subnet will be /56 (since,
> following your reasoning, that is what competitors with native IPv6
> access will be providing).

Because these allocations are intended to be returned to ARIN within
about 10 years and there is not even the shadow of a suspicion that
there will be any kind of IPv6 address shortage within ten years.

We should not encourage bad engineering practices solely because 
some people have a phobia caused by past events with IPv4.

> I would point out that the only ISP I am aware of that is conducting
> residential trials of IPv6 seems to be talking about giving only a /64
> to the home by default due to CPE issues. To me, that is a much greater
> problem than having a /60 instead of a /56, because with a /64 you
> can't do any subnetting at all.

Some ISPs will make dumb engineering decisions but that is not really ARIN's
problem. The marketplace will sort that out once customers realise that they
are being shortchanged and can't get their new InternetHDTV home theater system
working because it expects to have its own /64 assignment.

--Michael Dillon



From michael.dillon at bt.com  Fri Oct 15 05:19:23 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 15 Oct 2010 10:19:23 +0100
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CB781C0.1020507@townsley.net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
	<6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com>
	<4CB777FB.20102@townsley.net>
	<5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com>
	<4CB781C0.1020507@townsley.net>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423938134282@EMV01-UKBR.domain1.systemhost.net>

> Aren't ARIN's own guidelines:
> 
> "/56 for small sites, those expected to need only a few subnets over
> the next 5 years."

Actually, no they are not. ARIN's guidelines are:

    "The following guidelines may be useful (but they are only 
  guidelines):"

Followed by some additional text including that statement. But ARIN policy
is not and engineering manual. The IPv6 addressing architecture from
IETF is a /48 for all end sites unless there is some reason why an end
site cannot ever grow beyond a single LAN segment.

The ARIN policy text was reworked to include mention of /56 because the
cable TV industry had a need to allocate smaller than a /48 and wanted
that to be formally recognized in policy. They have to address every
home that the cable passes and many of those homes will never ever be
connected to that cable. This blows out their HD ratio from day 1 and 
ensures that they can never get another ARIN allocation, unless ARIN
changed the policy to allow for /56 endsites. Which we did do.

That however was a policy decision, not an engineering one. The /48 per
end site rule of thumb still stands.

> But I suppose you will explain to me why that text doesn't say what I
> think it says.

Because you are not a real lawyer. Real lawyers understand that context
is important and do not try to interpret words outside of context.

--Michael Dillon



From michael.dillon at bt.com  Fri Oct 15 05:37:26 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 15 Oct 2010 10:37:26 +0100
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <71B9FB76-4718-48B1-8185-B06CAD4705C6@cisco.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
	<6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com>
	<4CB777FB.20102@townsley.net>
	<5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com>
	<4CB781C0.1020507@townsley.net>
	<71B9FB76-4718-48B1-8185-B06CAD4705C6@cisco.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B4239381342B2@EMV01-UKBR.domain1.systemhost.net>

> He has
> argued in the past that a mobile phone connected to a cell tower should
> get a /48 because it might have a LAN behind it. 

The mobile phone industry has virtually disappeared. Nowadays people carry
pocket computers with always-on wireless Internet access. Whether or not
those pocket computers are used for voice conversations is irrelevant.

> What I, were I an ISP, would want to do is provide my customers with a
> set of addressing capabilities at different price points.

ARIN generally does not support such things. IP addresses are not sold
and there is not cost per address associated with them. Like with QOS,
ISPs can create artificial shortages to charge higher fees in order
to solve the problem that they created. But this costs the ISP more 
to do and the guy down the street can easily undercut the price points.

> I *would* recommend to ARIN that when it allocate a /32 to a member, it
> internally allocate a shorter prefix, so that the next allocation can
> turn the prefix into a /31 or whatever. 

That is current practice of all RIRs.

-- Michael Dillon


From mark at townsley.net  Fri Oct 15 06:56:27 2010
From: mark at townsley.net (Mark Townsley)
Date: Fri, 15 Oct 2010 12:56:27 +0200
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B423938134250@EMV01-UKBR.domain1.systemhost.net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>	<4CB5E076.7000701@townsley.net>	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>	<4CB6F929.3080207@townsley.net>	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>	<4CB707F7.9020506@townsley.net>	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938134250@EMV01-UKBR.domain1.systemhost.net>
Message-ID: <4CB8335B.70805@townsley.net>

On 10/15/10 11:08 AM, michael.dillon at bt.com wrote:

> 
>> Why not we make it a /28, and thus give the customer a /60? The
>> customer still gets 16 subnets for his house, and when 6rd goes away
>> (since, as you point out there are other disadvantages beyond address
>> space use compared to native IPv6), then the subnet will be /56 (since,
>> following your reasoning, that is what competitors with native IPv6
>> access will be providing).
> 
> Because these allocations are intended to be returned to ARIN within
> about 10 years and there is not even the shadow of a suspicion that
> there will be any kind of IPv6 address shortage within ten years.
> 
> We should not encourage bad engineering practices solely because 
> some people have a phobia caused by past events with IPv4.
> 
>> I would point out that the only ISP I am aware of that is conducting
>> residential trials of IPv6 seems to be talking about giving only a /64
>> to the home by default due to CPE issues. To me, that is a much greater
>> problem than having a /60 instead of a /56, because with a /64 you
>> can't do any subnetting at all.
> 
> Some ISPs will make dumb engineering decisions but that is not really ARIN's
> problem. The marketplace will sort that out once customers realise that they
> are being shortchanged and can't get their new InternetHDTV home theater system
> working because it expects to have its own /64 assignment.


Or, the CPE vendors could figure out how to manage with a single /64 if
that's the least common denominator offered. It won't work as well as it
could have, will cause more problems, cost more overall, etc. than if
routing were available, but if it works just well enough to mask the
feedback loop to the Marketplace that you are counting on here, then the
battle is lost. Never underestimate the power of local optimization.

- Mark

> 
> --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 wireless at starbeam.com  Fri Oct 15 08:03:58 2010
From: wireless at starbeam.com (Jerry Bacon)
Date: Fri, 15 Oct 2010 05:03:58 -0700
Subject: [arin-ppml] [Spam] Re:  Opposed to 2010-9 and 2010-12
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org><2376C0DA-2491-40D4-B509-8C643C507A61@delong.com><4CB5E076.7000701@townsley.net><0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net><4CB6F929.3080207@townsley.net><0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net><4CB707F7.9020506@townsley.net><D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com><AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938134250@EMV01-UKBR.domain1.systemhost.net>
Message-ID: <7DE7A905FBF74B6D8C55EC679DF66C3E@user6006cfcba1>

----- Original Message ----- 
From: <michael.dillon at bt.com>
>
> Some ISPs will make dumb engineering decisions but that is not really 
> ARIN's
> problem. The marketplace will sort that out once customers realise that 
> they
> are being shortchanged and can't get their new InternetHDTV home theater 
> system
> working because it expects to have its own /64 assignment.

Why in the world would a single device require a /64?

-- 
Jerry Bacon
StarTouch, Inc.
Ferndale WA



From wireless at starbeam.com  Fri Oct 15 08:09:58 2010
From: wireless at starbeam.com (Jerry Bacon)
Date: Fri, 15 Oct 2010 05:09:58 -0700
Subject: [arin-ppml] [Spam] Re:  Opposed to 2010-9 and 2010-12
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org><2376C0DA-2491-40D4-B509-8C643C507A61@delong.com><4CB5E076.7000701@townsley.net><0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net><4CB6F929.3080207@townsley.net><0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net><4CB707F7.9020506@townsley.net><D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com><AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com><6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com><4CB777FB.20102@townsley.net><5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com><4CB781C0.1020507@townsley.net><276CEBB5-9A12-4973-80FD-43BDFCE0435C@delong.com>	<AANLkTikOMdVo3mXw=4qhHO_upi7U4NUwtA000yS48Opa@mail.gmail.com>
	<7111F963B7D04CA1B104451167822F80@user6006cfcba1>
	<4CB7AF38.8010108@bogus.com>
Message-ID: <23A3F7A2B52042A9B358DDB4A71436B2@user6006cfcba1>

----- Original Message ----- 
From: "Joel Jaeggli" <joelja at bogus.com>
>
> Uh, yeah, and that's why you need automatic prefix delegation and a big
> enough prefix to work with becuase the alternative is a stack of event
> horizons which are a pain in the ass to work around just as in ipv4.
> subnetting does not have to require human intervention, just ask all the
> people who have stacked more than one wireless "router" in their home in
> the ipv4 case....

The point I'm trying to make is that most end users will have a single 
Internet connection through one router and have one network behind it. All 
of that will work just fine with a /64 and they will never know the 
difference. I think a simpler scheme that accomplishes that now is much 
better than a more complex one that gives them a /56 or /48 way down the 
road.

-- 
Jerry B.



From michael.dillon at bt.com  Fri Oct 15 08:13:27 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 15 Oct 2010 13:13:27 +0100
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CB8335B.70805@townsley.net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938134250@EMV01-UKBR.domain1.systemhost.net>
	<4CB8335B.70805@townsley.net>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B4239381343EE@EMV01-UKBR.domain1.systemhost.net>

> Or, the CPE vendors could figure out how to manage with a single /64 if
> that's the least common denominator offered. It won't work as well as
> it
> could have, will cause more problems, cost more overall, etc. than if
> routing were available, but if it works just well enough to mask the
> feedback loop to the Marketplace that you are counting on here, then
> the
> battle is lost. Never underestimate the power of local optimization.

Do you have any evidence that DOCSIS 3.0 or the Broadband Forum equivalent
design, actually do treat /64 as some kind of lowest common denominator?

In fact, I just pulled up TR-187 from the Broadband Forum and it says:

the Broadband Forum suggests a size for the delegated prefix of least a /60 for home network or SOHO environments with a recommended prefix length of /56. The delegated prefix may be extended to a /48 for larger organizations.

Seems to me that you are just spreading FUD. CPE vendors are going to 
implement according to DOCSIS 3.0 and Broadband Forum specs. They are 
not going to make up their own thing.

--Michael Dillon



From ppml at rs.seastrom.com  Fri Oct 15 08:13:37 2010
From: ppml at rs.seastrom.com (Robert E. Seastrom)
Date: Fri, 15 Oct 2010 08:13:37 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <4CB73624.1000309@townsley.net> (Mark Townsley's message of "Thu,
	14 Oct 2010 18:56:04 +0200")
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
	<4CB73624.1000309@townsley.net>
Message-ID: <86mxqffyby.fsf@seastrom.com>


Mark Townsley <mark at townsley.net> writes:

> 6rd is just getting deployed now, so precisely how to transition it to native
> is still speculative. But, I know that technically it is quite possible (with
> equipment that will be available in 2011, if not today) to allow 6rd and
> native exist alongside one another in a very transparent manner to the
> end-user.

When the AC discussed what the policy ought to be, we did not consider
speculative repairs to the protocol or improvements in the
implementations.  I recall that in response to my suggestion in the
hallway that the real solution was 6rdbis (to include repairs to make
it better than a proof-of-concept hack [*]), you told me in so many
words that the ship had sailed, there would be no improvements, it's
what we've got, and that the protocol with all its warts was committed
to silicon, among other assertions reflecting inflexibility and having
one's mind made up.  We did, however, frame the discussion in terms of
the way in which operators of various levels of skill are likely to
configure the equipment in actual field use cases.  I'll defer to the
official statement for more.

-r

[*] which, in response to a comment you made earlier, was fully
deserving of the standing ovation it got at RIPE.  Rightful applause
and kudos for taking the initiative in a nationwide all-customers
technology demo, and being ready for prime time, are orthogonal as I
would expect anyone who works for an equipment vendor to grok at a
deeper level than most.



From owen at delong.com  Fri Oct 15 08:15:41 2010
From: owen at delong.com (Owen DeLong)
Date: Fri, 15 Oct 2010 05:15:41 -0700
Subject: [arin-ppml] [Spam] Re:  Opposed to 2010-9 and 2010-12
In-Reply-To: <7DE7A905FBF74B6D8C55EC679DF66C3E@user6006cfcba1>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org><2376C0DA-2491-40D4-B509-8C643C507A61@delong.com><4CB5E076.7000701@townsley.net><0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net><4CB6F929.3080207@townsley.net><0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net><4CB707F7.9020506@townsley.net><D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com><AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938134250@EMV01-UKBR.domain1.systemhost.net>
	<7DE7A905FBF74B6D8C55EC679DF66C3E@user6006cfcba1>
Message-ID: <5FF09B05-9ACF-4B43-AF75-B4B493F4996F@delong.com>


On Oct 15, 2010, at 5:03 AM, Jerry Bacon wrote:

> ----- Original Message ----- From: <michael.dillon at bt.com>
>> 
>> Some ISPs will make dumb engineering decisions but that is not really ARIN's
>> problem. The marketplace will sort that out once customers realise that they
>> are being shortchanged and can't get their new InternetHDTV home theater system
>> working because it expects to have its own /64 assignment.
> 
> Why in the world would a single device require a /64?

The system wouldn't be a single device. It would be an amp, some form of tuner,
likely one or more media players (BluRay, etc.), probably some form of DVR,
and a display device, at minimum. It's not unlikely that the speakers could be
ethernet or WiFi devices also expecting their own IPv6 addresses.

Owen



From michael.dillon at bt.com  Fri Oct 15 08:22:54 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 15 Oct 2010 13:22:54 +0100
Subject: [arin-ppml] [Spam] Re:  Opposed to 2010-9 and 2010-12
In-Reply-To: <7DE7A905FBF74B6D8C55EC679DF66C3E@user6006cfcba1>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org><2376C0DA-2491-40D4-B509-8C643C507A61@delong.com><4CB5E076.7000701@townsley.net><0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net><4CB6F929.3080207@townsley.net><0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net><4CB707F7.9020506@townsley.net><D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com><AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938134250@EMV01-UKBR.domain1.systemhost.net>
	<7DE7A905FBF74B6D8C55EC679DF66C3E@user6006cfcba1>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423938134404@EMV01-UKBR.domain1.systemhost.net>

> > Some ISPs will make dumb engineering decisions but that is not 
> > really ARIN's problem. The marketplace will sort that out once 
> > customers realise
> that
> > they
> > are being shortchanged and can't get their new InternetHDTV home
> theater
> > system
> > working because it expects to have its own /64 assignment.
> 
> Why in the world would a single device require a /64?

What single device? The *SYSTEM* is composed of an Internet connected receiver that prefers to be connected by wire to the Internet gateway router, a distribution box which streams over a non-wifi wireless system to a master screen, an audio system, and up to two satellite screen/audio combos, as well as an optional wireline to the master screen and master audio system. The distribution box can stream up to three distinct streams and will connect to a network storage device over GigE. It also supports wifi connectivity (which is routed) to the normal home network devices to allow viewing of any other media that you happen to have at home.

All the home theater system devices communicate on their own /64.
They also route that address to the wifi to allow you to manage the system remotely.

All hypothetical of course expect that I know that some people in research labs are thinking this same way and, in particular, home theater manufacturers are thinking along these lines.

--Michael Dillon



From mark at townsley.net  Fri Oct 15 08:58:30 2010
From: mark at townsley.net (Mark Townsley)
Date: Fri, 15 Oct 2010 14:58:30 +0200
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <868w1ziuds.fsf@seastrom.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>	<4CB5E076.7000701@townsley.net>	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>	<4CB6F929.3080207@townsley.net>	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>	<4CB707F7.9020506@townsley.net>	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>	<4CB73624.1000309@townsley.net>
	<868w1ziuds.fsf@seastrom.com>
Message-ID: <4CB84FF6.3050100@townsley.net>

On 10/15/10 1:10 PM, Robert E. Seastrom wrote:

> 
> Mark Townsley <mark at townsley.net> writes:
> 
>> 6rd is just getting deployed now, so precisely how to transition it to native
>> is still speculative. But, I know that technically it is quite possible (with
>> equipment that will be available in 2011, if not today) to allow 6rd and
>> native exist alongside one another in a very transparent manner to the
>> end-user.
> 
> When the AC discussed what the policy ought to be, we did not consider
> speculative repairs to the protocol or improvements in the
> implementations.  


Good. The scenario I described in this thread requires no changes to the
6rd protocol either. The part I am saying is speculative is largely
operational in nature.

> I recall that in response to my suggestion in the
> hallway that the real solution was 6rdbis (to include repairs to make
> it better than a proof-of-concept hack [*]), you told me in so many
> words that the ship had sailed, there would be no improvements, 


My point was that changing the protocol at this stage, just 2 months
after the standards track RFC is out and vendor equipment on the shelves
for roughly a similar amount of time, would lead to IPv6 deployments in
queue being significantly delayed.

Certainly, protocols can be improved and evolve. In fact, there are a
number of documents being discussed in the softwires WG in the IETF that
do precisely that for 6rd (for example, 6rd operation through an IPv4
NAT device, among others).

- Mark

> it's

> what we've got, and that the protocol with all its warts was committed
> to silicon, among other assertions reflecting inflexibility and having
> one's mind made up.  We did, however, frame the discussion in terms of
> the way in which operators of various levels of skill are likely to
> configure the equipment in actual field use cases.  I'll defer to the
> official statement for more.



> 
> -r
> 
> [*] which, in response to a comment you made earlier, was fully
> deserving of the standing ovation it got at RIPE.  Rightful applause
> and kudos for taking the initiative in a nationwide all-customers
> technology demo, and being ready for prime time, are orthogonal as I
> would expect anyone who works for an equipment vendor to grok at a
> deeper level than most.
> 




From mark at townsley.net  Fri Oct 15 09:12:49 2010
From: mark at townsley.net (Mark Townsley)
Date: Fri, 15 Oct 2010 15:12:49 +0200
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B4239381343EE@EMV01-UKBR.domain1.systemhost.net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>	<4CB5E076.7000701@townsley.net>	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>	<4CB6F929.3080207@townsley.net>	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>	<4CB707F7.9020506@townsley.net>	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>	<0F29D1BA57992E4CAB5AD2C9AE7B423938134250@EMV01-UKBR.domain1.systemhost.net>	<4CB8335B.70805@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B4239381343EE@EMV01-UKBR.domain1.systemhost.net>
Message-ID: <4CB85351.5080908@townsley.net>

On 10/15/10 2:13 PM, michael.dillon at bt.com wrote:

>> Or, the CPE vendors could figure out how to manage with a single /64 if
>> that's the least common denominator offered. It won't work as well as
>> it
>> could have, will cause more problems, cost more overall, etc. than if
>> routing were available, but if it works just well enough to mask the
>> feedback loop to the Marketplace that you are counting on here, then
>> the
>> battle is lost. Never underestimate the power of local optimization.
> 
> Do you have any evidence that DOCSIS 3.0 or the Broadband Forum equivalent
> design, actually do treat /64 as some kind of lowest common denominator?


I'm saying that *if* that's what ISPs provide, that's what they will
have to do whether they like it or not. I hope they do not have to.

- Mark

> 
> In fact, I just pulled up TR-187 from the Broadband Forum and it says:
> 
> the Broadband Forum suggests a size for the delegated prefix of least a /60 for home network or SOHO environments with a recommended prefix length of /56. The delegated prefix may be extended to a /48 for larger organizations.
> 
> Seems to me that you are just spreading FUD. CPE vendors are going to 
> implement according to DOCSIS 3.0 and Broadband Forum specs. They are 
> not going to make up their own thing.


> 
> --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 bjohnson at drtel.com  Fri Oct 15 09:51:44 2010
From: bjohnson at drtel.com (Brian Johnson)
Date: Fri, 15 Oct 2010 08:51:44 -0500
Subject: [arin-ppml] Preemptive IPv6 assignment
In-Reply-To: <AANLkTimfMPR=GQX_bm4xUNhcTDVZx+D1gcsXPiNKS18X@mail.gmail.com>
References: <AANLkTi=F8qZ_PG9ku9QUCwQef72ES2EyFChRV0=e0yM1@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47021D8C8E@ex01.drtel.lan>
	<10093.1286906540@marajade.sandelman.ca>
	<4CB4AEEC.6020701@ipinc.net>
	<20732.1286911333@marajade.sandelman.ca>
	<AANLkTimduTRGc1uYBgZ6UcfzaX6f2xftn10Z7nh7YOYn@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47021D8D4D@ex01.drtel.lan>
	<AANLkTimfMPR=GQX_bm4xUNhcTDVZx+D1gcsXPiNKS18X@mail.gmail.com>
Message-ID: <29A54911243620478FF59F00EBB12F47021D8D89@ex01.drtel.lan>



<SNIP>
>>
>> So now we are going to put people on some kind of "guilt trip"
because
>> of our decisions.
>
>Brian,
>
>Guilt trip? Heck, I don't care if the latecomers harm themselves with
>their deployment choices. I do care if they harm me. I hope you care
>if they harm you.
>
>If you have to bend over backwards to continue talking to them on
>IPv4, it seems to me like that harms you. You don't agree?
>

No. I will not have to bend over backwards to continue providing the
same services that we have done for over a decade. :-)

I simply don't see any real harm, only an implied harm with no fact to
back it up, at least not for me and I suspect some others as well. I
also oppose assigning a resource without the recipient asking for it.

- Brian J.

()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments

* Please note that all list members and archive readers may consider
themselves Recipients of this message, in reference to the appended
disclaimer.  (I don't add it myself and can't control it, sorry.)


 CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the
intended recipient(s) and may contain confidential and privileged information. Any unauthorized review,
copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original message. Thank you.


From kkargel at polartel.com  Fri Oct 15 11:23:54 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Fri, 15 Oct 2010 10:23:54 -0500
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <7111F963B7D04CA1B104451167822F80@user6006cfcba1>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org><2376C0DA-2491-40D4-B509-8C643C507A61@delong.com><4CB5E076.7000701@townsley.net><0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net><4CB6F929.3080207@townsley.net><0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net><4CB707F7.9020506@townsley.net><D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com><AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com><6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com><4CB777FB.20102@townsley.net><5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com><4CB781C0.1020507@townsley.net><276CEBB5-9A12-4973-80FD-43BDFCE0435C@delong.com>
	<AANLkTikOMdVo3mXw=4qhHO_upi7U4NUwtA000yS48Opa@mail.gmail.com>
	<7111F963B7D04CA1B104451167822F80@user6006cfcba1>
Message-ID: <8695009A81378E48879980039EEDAD288C049D73@MAIL1.polartel.local>

>I know that most of you are going to think this is absolute heresy, but I >don't really think that most consumers will care one iota whether they get >a /64 or anything larger. If they plug in their devices? and they are able >to do whatever they want to on the Internet (both IPv4 and IPv6) they could >care less about the technical details and how it could be "better".
?
>-- 
>Jerry Bacon
>StarTouch, Inc.
>Ferndale WA

That's not heresy at all.  As admin for an ISP with many residential customers, I can state that most residential end users be perfectly happy with a /124 if their few devices worked and routed when plugged in.  Heck, a great many customers would be perfectly happy with a /128 with a host route that routed their one device.

I realize that these examples would in reality cause problems, but it doesn't change the premise.

Kevin?


From alh-ietf at tndh.net  Fri Oct 15 11:56:54 2010
From: alh-ietf at tndh.net (Tony Hain)
Date: Fri, 15 Oct 2010 08:56:54 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <276CEBB5-9A12-4973-80FD-43BDFCE0435C@delong.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>	<4CB5E076.7000701@townsley.net>	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>	<4CB6F929.3080207@townsley.net>	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>	<4CB707F7.9020506@townsley.net>	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>	<6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com>	<4CB777FB.20102@townsley.net>	<5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com>	<4CB781C0.1020507@townsley.net>
	<276CEBB5-9A12-4973-80FD-43BDFCE0435C@delong.com>
Message-ID: <025b01cb6c81$ab404cd0$01c0e670$@net>

Owen DeLong wrote:
> ...
>
> If you can get 6rd to fit in  single /16, then, perhaps we 
> could consider allowing it to be permanent.

That is called 6to4... ;)   Seriously, if every ISP would just operate a
6to4 relay announcing 2002:????::/24-40 matching their IPv4 prefix length on
the IPv6 side, we wouldn't need 6rd (yes this violates the stupid one-liner
in the RFC). The number of prefixes in the IPv6 routing table would be no
different than if 6rd is put into a special block intended to be turned off
years from now. The real 'value' of 6rd over 6to4 is that an ISP can have a
single prefix covering both their 6rd and dual-stack customers, and the
outside world doesn't need to know. The downside is that each RIR gets to
stand in the way of 6rd deployments with an enormous wall of FUD about
burning through 4B instances the size of the IPv4 Internet in less than 20
years. 

Warning simple math --->  ~ 2/3 of the population of the planet could run
their own 6rd /32 and there would still be addresses in the pool ... 

> However, if ~3,000 ARIN members deploy 6rd /24s, then, you're 
> talking about the vast majority of an entire /12 just in the 
> ARIN region.

And the problem with that is??? There are more /12's to distribute, so if
every RIR dedicates a /12 to 6rd in addition to their existing /12, IANA
still has 502 in the first /3. 

Tony




From lorenzo at google.com  Fri Oct 15 12:16:07 2010
From: lorenzo at google.com (Lorenzo Colitti)
Date: Fri, 15 Oct 2010 09:16:07 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B4239381343EE@EMV01-UKBR.domain1.systemhost.net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938134250@EMV01-UKBR.domain1.systemhost.net>
	<4CB8335B.70805@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B4239381343EE@EMV01-UKBR.domain1.systemhost.net>
Message-ID: <AANLkTikvgOQVav9zub3-zun+0tBooweSjUwoOO_7GF5M@mail.gmail.com>

On Fri, Oct 15, 2010 at 5:13 AM, <michael.dillon at bt.com> wrote:

> Seems to me that you are just spreading FUD. CPE vendors are going to
> implement according to DOCSIS 3.0 and Broadband Forum specs. They are
> not going to make up their own thing.


Please base your statements on facts. I am testing IPv6-capable CPEs right
now and some of them do not support anything other than /64. Fortunately the
ones I know of are either in beta or support automatic updates, so I am
trying to get them fixed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101015/a3d8a045/attachment.htm>

From lorenzo at google.com  Fri Oct 15 12:16:13 2010
From: lorenzo at google.com (Lorenzo Colitti)
Date: Fri, 15 Oct 2010 09:16:13 -0700
Subject: [arin-ppml] [Spam] Re: Opposed to 2010-9 and 2010-12
In-Reply-To: <23A3F7A2B52042A9B358DDB4A71436B2@user6006cfcba1>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
	<6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com>
	<4CB777FB.20102@townsley.net>
	<5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com>
	<4CB781C0.1020507@townsley.net>
	<276CEBB5-9A12-4973-80FD-43BDFCE0435C@delong.com>
	<AANLkTikOMdVo3mXw=4qhHO_upi7U4NUwtA000yS48Opa@mail.gmail.com>
	<7111F963B7D04CA1B104451167822F80@user6006cfcba1>
	<4CB7AF38.8010108@bogus.com>
	<23A3F7A2B52042A9B358DDB4A71436B2@user6006cfcba1>
Message-ID: <AANLkTinKUHk=bTwsEPYEVkBHo2J7XfDHeYycwzb4WDta@mail.gmail.com>

On Fri, Oct 15, 2010 at 5:09 AM, Jerry Bacon <wireless at starbeam.com> wrote:

> The point I'm trying to make is that most end users will have a single
> Internet connection through one router and have one network behind it. All
> of that will work just fine with a /64 and they will never know the
> difference. I think a simpler scheme that accomplishes that now is much
> better than a more complex one that gives them a /56 or /48 way down the
> road.


The IPv6 CPEs on the shelves today support a main network and a wireless
network. You can't do that with a /64 without ungodly hacks and the sort of
horrible layering violations that we're deploying IPv6 to get away from.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101015/7e9f41ce/attachment.htm>

From bill at herrin.us  Fri Oct 15 12:51:47 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 15 Oct 2010 12:51:47 -0400
Subject: [arin-ppml] Controlling the IPv6 address consumption rate
In-Reply-To: <7E753F8B-5518-4967-A73C-BA1E5E77FF78@cisco.com>
References: <AANLkTik+5zsTzepnf40faZVgOxNF2OOeMt-3o4p2wLEw@mail.gmail.com>
	<2B6D8499-377A-40FF-8263-79C6A3BFD3AE@delong.com>
	<AANLkTikQqyg8508hSUbxM5gMp=_BSuf41jaRByztaGuh@mail.gmail.com>
	<015001cb6bfd$92ebb590$b8c320b0$@net>
	<AANLkTinQo81_U0jRvGi98=epVX7m=JPjqCCHNyrmR6cG@mail.gmail.com>
	<7E753F8B-5518-4967-A73C-BA1E5E77FF78@cisco.com>
Message-ID: <AANLkTi=E8CdFWdzpDj9zrX3MBwFyJS8BOaW4LmPyJCQS@mail.gmail.com>

On Fri, Oct 15, 2010 at 12:52 AM, Fred Baker <fred at cisco.com> wrote:
> On Oct 14, 2010, at 6:24 PM, William Herrin wrote:
>> Hokay. Sure. Did it offend you that I described that I described the
>> local LAN as robbing from routing? Would you prefer something along
>> the lines of, "From the routing perspective, IPv6 is only 64 bits
>> large, not 128?" I humbly apologize for my choice of words.
>
> I think there is a question of requirements.
>Hopefully I can say this without people throwing bricks.
>
> The requirements IPv6 was developed against include but are not limited to
> http://www.ietf.org/rfc/rfc1726.txt

Fred,

Respectfully, IPv6's design requirements from the '90's are not at
issue here. IPv6 is built; the protocol is what it is now, not what it
was imagined to become then.

The question I pose now is: with the protocol we have, how do we make it last?

Since 1994, when RFC 1726 was published, it has become commonplace for
households to have an always-on distinct network connected to the
Internet with a router. And its commonplace to carry around a network
on one's cell phone, supplying both the phone and one's laptop
computer. In a small but growing number of cases, that phone supplies
a car or bus full of laptops.

So the better part of two decades after RFC 1726, it takes no great
imagination to foresee that a selecting a top network count an order
of magnitude smaller than world population (10^9 as 1726 suggested
that IPv6 design to) isn't going to last as long as we'd like.


> Now, you can argue that the requirements were incorrect.
>If so, please advise: how many LANs in the world do you
>need to be able to individually enumerate, and what are
>your aggregation requirements? How many hosts per LAN?

I don't know. Any guess I might make will surely prove as laughable as
1726's 10^9.

Fortunately, at an operations level there's a smarter question.

We have decades of experience with how quickly ISPs of various
customer counts consume percentages of the address space. How much
more slowly do we want them to consume percentages of the IPv6 address
space?

Determine that answer, and it's easy math from our IPv4 experience to
set the upper bounds for how much address space an IPv6 ISP may hold.
Whatever bits are left is what's available for the ISP to employ
whatever routing and assignment practices they select.

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  Fri Oct 15 13:12:26 2010
From: owen at delong.com (Owen DeLong)
Date: Fri, 15 Oct 2010 10:12:26 -0700
Subject: [arin-ppml] [Spam] Re:  Opposed to 2010-9 and 2010-12
In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B423938134404@EMV01-UKBR.domain1.systemhost.net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org><2376C0DA-2491-40D4-B509-8C643C507A61@delong.com><4CB5E076.7000701@townsley.net><0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net><4CB6F929.3080207@townsley.net><0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net><4CB707F7.9020506@townsley.net><D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com><AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938134250@EMV01-UKBR.domain1.systemhost.net>
	<7DE7A905FBF74B6D8C55EC679DF66C3E@user6006cfcba1>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938134404@EMV01-UKBR.domain1.systemhost.net>
Message-ID: <310BEE80-110D-4345-8C20-50AB56FE8C55@delong.com>


On Oct 15, 2010, at 5:22 AM, <michael.dillon at bt.com> <michael.dillon at bt.com> wrote:

>>> Some ISPs will make dumb engineering decisions but that is not 
>>> really ARIN's problem. The marketplace will sort that out once 
>>> customers realise
>> that
>>> they
>>> are being shortchanged and can't get their new InternetHDTV home
>> theater
>>> system
>>> working because it expects to have its own /64 assignment.
>> 
>> Why in the world would a single device require a /64?
> 
> What single device? The *SYSTEM* is composed of an Internet connected receiver that prefers to be connected by wire to the Internet gateway router, a distribution box which streams over a non-wifi wireless system to a master screen, an audio system, and up to two satellite screen/audio combos, as well as an optional wireline to the master screen and master audio system. The distribution box can stream up to three distinct streams and will connect to a network storage device over GigE. It also supports wifi connectivity (which is routed) to the normal home network devices to allow viewing of any other media that you happen to have at home.
> 
> All the home theater system devices communicate on their own /64.
> They also route that address to the wifi to allow you to manage the system remotely.
> 
> All hypothetical of course expect that I know that some people in research labs are thinking this same way and, in particular, home theater manufacturers are thinking along these lines.
> 
Not so hypothetical... I have most of that in my house today, x2.

System 1:
Yamaha RXV-3900
Apple TV
TiVO HD XL
PS-3
Wii
LG internet Connected LED TV

System 2:
Yamaha RXV-3900
iMac HDMI
Toshiba Blu-Ray Player
Sharp Aquos with Ethernet

Media Server:
Apple iMac 27" i7 quad core with firewire-800 attached 20TB array

Admittedly, none of these devices support IPv6 (yet) other
than the iMac, but, hopefully the vendors will fix that soon.

Owen



From owen at delong.com  Fri Oct 15 13:30:13 2010
From: owen at delong.com (Owen DeLong)
Date: Fri, 15 Oct 2010 10:30:13 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <025b01cb6c81$ab404cd0$01c0e670$@net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>	<4CB5E076.7000701@townsley.net>	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>	<4CB6F929.3080207@townsley.net>	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>	<4CB707F7.9020506@townsley.net>	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>	<6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com>	<4CB777FB.20102@townsley.net>	<5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com>	<4CB781C0.1020507@townsley.net>
	<276CEBB5-9A12-4973-80FD-43BDFCE0435C@delong.com>
	<025b01cb6c81$ab404cd0$01c0e670$@net>
Message-ID: <50136C79-882B-4081-AB15-3CA632A22AE3@delong.com>


On Oct 15, 2010, at 8:56 AM, Tony Hain wrote:

> Owen DeLong wrote:
>> ...
>> 
>> If you can get 6rd to fit in  single /16, then, perhaps we 
>> could consider allowing it to be permanent.
> 
> That is called 6to4... ;)   Seriously, if every ISP would just operate a
> 6to4 relay announcing 2002:????::/24-40 matching their IPv4 prefix length on
> the IPv6 side, we wouldn't need 6rd (yes this violates the stupid one-liner
> in the RFC). The number of prefixes in the IPv6 routing table would be no
> different than if 6rd is put into a special block intended to be turned off
> years from now. The real 'value' of 6rd over 6to4 is that an ISP can have a
> single prefix covering both their 6rd and dual-stack customers, and the
> outside world doesn't need to know. The downside is that each RIR gets to
> stand in the way of 6rd deployments with an enormous wall of FUD about
> burning through 4B instances the size of the IPv4 Internet in less than 20
> years. 
> 
> Warning simple math --->  ~ 2/3 of the population of the planet could run
> their own 6rd /32 and there would still be addresses in the pool ... 
> 
>> However, if ~3,000 ARIN members deploy 6rd /24s, then, you're 
>> talking about the vast majority of an entire /12 just in the 
>> ARIN region.
> 
> And the problem with that is??? There are more /12's to distribute, so if
> every RIR dedicates a /12 to 6rd in addition to their existing /12, IANA
> still has 502 in the first /3. 
> 
> Tony
> 

No problem at /24. That's what we approved in the AC.

However, the point is that only provides for /56s at the end-user side
of the 6rd equation. If you want /48s, that becomes the majority of a /8
instead of a /12 and I think that's pushing the envelope.

Owen



From heather.skanks at gmail.com  Fri Oct 15 13:51:12 2010
From: heather.skanks at gmail.com (Heather Schiller)
Date: Fri, 15 Oct 2010 13:51:12 -0400
Subject: [arin-ppml] Controlling the IPv6 address consumption rate
In-Reply-To: <AANLkTinCOsaG-c9Yp3GA-FXbO3TOFE418ZpXrB4TXdvt@mail.gmail.com>
References: <AANLkTik+5zsTzepnf40faZVgOxNF2OOeMt-3o4p2wLEw@mail.gmail.com>
	<2B6D8499-377A-40FF-8263-79C6A3BFD3AE@delong.com>
	<AANLkTikQqyg8508hSUbxM5gMp=_BSuf41jaRByztaGuh@mail.gmail.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B4239378EABD9@EMV01-UKBR.domain1.systemhost.net>
	<AANLkTinCOsaG-c9Yp3GA-FXbO3TOFE418ZpXrB4TXdvt@mail.gmail.com>
Message-ID: <AANLkTikuWbvAPUEJb_gp0zjv+fHw9pBwPwHnyP0nEk2h@mail.gmail.com>

On Wed, Oct 13, 2010 at 11:16 AM, William Herrin <bill at herrin.us> wrote:
> On Wed, Oct 13, 2010 at 10:54 AM, ?<michael.dillon at bt.com> wrote:
>>> Responsible management demands that we treat some portion of that 22
>>> bits as a consumption suppressor so that we don't quickly run out of
>>> IPv6 addresses. Whatever is left over, be it 4 bits, 20, or anything
>>> in between, that's the number of bits we can actually afford to use
>>> for nice-to-haves, like a larger standard end-user assignment than /60
>>> (/56 or /48), sparse assignment and so on.
>>
>> Whoaaa there!!!
>> The IETF defined standard end user assignment is /48.
>> That is not a nice-to-have, that is the standard. ARIN policy, and every
>> other RIR policy accepts end user assignments of /48 as standard.
>
> Michael,
>
> At the same time (maybe even in the same RFC), the IETF decided that
> end users would not multihome using BGP with multiple ISPs under IPv6.
> That too is the official standard.
>

Bill,

   I don't believe IETF ever "decided that end users would not
multihome using bgp with multiple ISP's"   It was more like they
repeatedly tried to create an alternate method of multihoming that did
not rely on *deaggregation* (LISP, SHIM6, LIN6, HIP, MAST..) in
combination with IPv6 Auto-Config - so that end users could use PA
space to multihome with minimal impact on the routing table and easily
renumber from their provider (as comparatively to v4).  But then we
passed the end user IPv6 assignment policy and instantly lost the much
of the motivation to complete that work.


> We always listen to what the folks in the IETF have to say, but
> sometimes they don't know what the eff they're talking about.
>

 Maybe rather than just listening to what the folks in IETF have to
say, operators should participate more, in order to develop solutions
that are operationally feasible.  Be a part of the solution.  Much
like the ARIN community and policy development process, there is a
mechanism to participate in the development of IETF standards.


From fred at cisco.com  Fri Oct 15 14:22:01 2010
From: fred at cisco.com (Fred Baker)
Date: Fri, 15 Oct 2010 11:22:01 -0700
Subject: [arin-ppml] Controlling the IPv6 address consumption rate
In-Reply-To: <AANLkTikuWbvAPUEJb_gp0zjv+fHw9pBwPwHnyP0nEk2h@mail.gmail.com>
References: <AANLkTik+5zsTzepnf40faZVgOxNF2OOeMt-3o4p2wLEw@mail.gmail.com>
	<2B6D8499-377A-40FF-8263-79C6A3BFD3AE@delong.com>
	<AANLkTikQqyg8508hSUbxM5gMp=_BSuf41jaRByztaGuh@mail.gmail.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B4239378EABD9@EMV01-UKBR.domain1.systemhost.net>
	<AANLkTinCOsaG-c9Yp3GA-FXbO3TOFE418ZpXrB4TXdvt@mail.gmail.com>
	<AANLkTikuWbvAPUEJb_gp0zjv+fHw9pBwPwHnyP0nEk2h@mail.gmail.com>
Message-ID: <B8404BBF-A3F4-4294-B26F-4A5F7EF8789A@cisco.com>


On Oct 15, 2010, at 10:51 AM, Heather Schiller wrote:

> Maybe rather than just listening to what the folks in IETF have to
> say, operators should participate more, in order to develop solutions
> that are operationally feasible.  Be a part of the solution.  Much
> like the ARIN community and policy development process, there is a
> mechanism to participate in the development of IETF standards.

Speaking as the chair of the IPv6 Operations Working Group, which is chartered specifically to engage with operators and work on the solutions they need, I would welcome operator participation, and those I work with tell me they would as well.

From joelja at bogus.com  Fri Oct 15 14:44:22 2010
From: joelja at bogus.com (Joel Jaeggli)
Date: Fri, 15 Oct 2010 11:44:22 -0700
Subject: [arin-ppml] Controlling the IPv6 address consumption rate
In-Reply-To: <AANLkTikuWbvAPUEJb_gp0zjv+fHw9pBwPwHnyP0nEk2h@mail.gmail.com>
References: <AANLkTik+5zsTzepnf40faZVgOxNF2OOeMt-3o4p2wLEw@mail.gmail.com>	<2B6D8499-377A-40FF-8263-79C6A3BFD3AE@delong.com>	<AANLkTikQqyg8508hSUbxM5gMp=_BSuf41jaRByztaGuh@mail.gmail.com>	<0F29D1BA57992E4CAB5AD2C9AE7B4239378EABD9@EMV01-UKBR.domain1.systemhost.net>	<AANLkTinCOsaG-c9Yp3GA-FXbO3TOFE418ZpXrB4TXdvt@mail.gmail.com>
	<AANLkTikuWbvAPUEJb_gp0zjv+fHw9pBwPwHnyP0nEk2h@mail.gmail.com>
Message-ID: <4CB8A106.5050704@bogus.com>

On 10/15/10 10:51 AM, Heather Schiller wrote:
> On Wed, Oct 13, 2010 at 11:16 AM, William Herrin <bill at herrin.us> wrote:
>> We always listen to what the folks in the IETF have to say, but
>> sometimes they don't know what the eff they're talking about.

I'm not convinced that you do listen, or that if you do listen that you
agree. Disagreeing I see as preferable to not listening. It's pretty
easy to characterize the activities of 15-18 years ago as deluded or
misguided, it seems to be harder for us to accept that what was done was
as good as it could be under the circumstances and that we need to move
on changing what we have in minor ways rather than boiling the baby (who
is now a teenager in any event) in the bathwater.

We have 15 years of groundwork behind us, some of us have had ipv6
assignments, deployed networks and working host implementations for
close to a decade, this stuff doesn't change that easily even if the
vast bulk of the deployment exercise is still in front of us.

FWIW I am both a network operator and one of the v6ops WG chairs.

>  Maybe rather than just listening to what the folks in IETF have to
> say, operators should participate more, in order to develop solutions
> that are operationally feasible. 

Be reminded that as network operator's we don't all speak with one
voice. There's a reason that there's disagreement on this list for
example and you shouldn't expect anything less from any other community
of interest in which you would participate.

> Be a part of the solution.  Much
> like the ARIN community and policy development process, there is a
> mechanism to participate in the development of IETF standards.
> _______________________________________________
> 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 mark at townsley.net  Fri Oct 15 16:08:54 2010
From: mark at townsley.net (Mark Townsley)
Date: Fri, 15 Oct 2010 22:08:54 +0200
Subject: [arin-ppml] Draft Policy 2010-12: IPv6 Subsequent Allocation -
 Last Call (text revised)
In-Reply-To: <4CB5F5FD.7090806@arin.net>
References: <4CB5F5FD.7090806@arin.net>
Message-ID: <4CB8B4D6.60709@townsley.net>


ARIN and all,

This has been an enlightening exchange over the past week or so. I
appreciate all time and attention devoted to this topic, as well as the
lively exchanges by all. For my part, I am now off to enjoy a final
weekend at home before traveling four out of the next five weeks.

For the record, my position on the last call below is:

1. I am very pleased to see a policy for subsequent allocation, and that
ARIN recognizes the need for 6rd at this stage of deployment and has
acted accordingly. I admit that there are no ideal alternatives, all are
tradeoffs at one level or another.

2. One the following two revisions

"- Requests for transition space will not be exempt from returns."
"- Allocations will be from a designated block."

I do not support use of a segregated space for all 6rd allocations, nor
the idea that return of that space could happen in bulk while
individual allocations were still in use by some ISPs. However, I would
support individual review and return of space when individual ISPs are
finished with it. I admit to not fully understanding what the return
process might be though, which could be clouding my judgment. Perhaps a
future date, 7-10 years has been suggested here by some, before any such
return could be considered would be useful for other folks like me to
have less concern.

3. On the following revision:

"- /24 was added as the maximum prefix size."

/24 for 6rd seems generous, /28 would probably suffice, particularly if
it would come with less "strings attached" in terms of possibility of
return before the ISP is ready for the space to be returned.

4. Above all, I do not want to see any delay in implementation of a
policy that allows for SPs to get a subsequent allocation of at least
/28 for 6rd deployment in the ARIN region.

Best Regards,

- Mark




On 10/13/10 8:10 PM, ARIN wrote:

> The ARIN Advisory Council (AC) met on 8 October 2010 and decided to
> send the following draft policy to last call:
> 
>    Draft Policy 2010-12: IPv6 Subsequent Allocation
> 
> The AC made the following revisions to the text:
>   - /24 was added as the maximum prefix size.
>   - Allocations will be from a designated block.
>   - Requests for transition space will not be exempt from returns.
> 
> Feedback is encouraged during the last call period. All comments should
> be provided to the Public Policy Mailing List. Last call for 2010-12
> will expire on 27 October 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,
> 
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Draft Policy 2010-12
> IPv6 Subsequent Allocation
> 
> Version/Date: 13 October 2010
> 
> Policy statement:
> 
> Modify 6.5.2.1 Subsequent allocation criteria. Add the following:
> 
> Subsequent allocations will also be considered for deployments that
> cannot be accommodated by, nor were accounted for, under the initial
> allocation. Justification for the subsequent subnet size will be based
> on the plan and technology provided with a /24 being the maximum allowed
> for a transition technology. Justification for these allocations will be
> reviewed every 3 years and reclaimed if it is not in use. All such
> allocations for transitional technology will be made from a block
> designated for this purpose.
> 
> Rationale:
> 
> Current organizations cannot get an allocation for a IPv6 transitional
> technology if they have already received their initial allocation of
> IPv6. The reason they cannot get an additional IPV6 allocation is
> because they don't meet the HD ratio for a subsequent allocation and
> they don't want to use their initial assignment because it is
> insufficient, mapped out for other long term plans, or already has
> portions in use.
> 
> An alternative proposal to permit more allocations was submitted that
> supported 6rd but since then community members have come forward with
> concern that this should support not just one particular technology but
> any that enable v6 deployment.
> 
> Justification Example: Below is an example of how the details for a
> technology and its subnet requirements could be provided as
> justification. This example is based of 6rd.
> 
> 6rd is intended to be an incremental method for deploying IPv6 and
> bridge the gap for End Users to the IPv6 Internet. The method provides a
> native dual-stack service to a subscriber site by leveraging existing
> infrastructure. If an entity already has a /32 of IPv6 they can not use
> the same /32 for native IPv6 as they do for the 6rd routing and a
> separate minimum size of a /32 is required while a larger subnet like a
> /28 may be needed based on a non-contiguous IPv4 addressing plan.
> 
> The 6rd prefix is an RIR delegated IPv6 prefix. It must encapsulate an
> IPv4 address and must be short enough so that a /56 or /60 can be given
> to subscribers. This example shows how the 6rd prefix is created based
> on a /32 IPv6 prefix using RFC1918 address space from 10.0.0.0/8:
> 
> SP IPv6 prefix: 2001:0DB8::/32 v4suffix-length: 24 (from 10/8, first
> octet (10) is excluded from the encoding) 6rd CE router IPv4 address:
> 10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56
> 
> This example shows how the 6rd prefix is created based on a /28 IPv6
> prefix using one of several non-contiguous global address ranges:
> 
> SP IPv6 prefix: 2001:0DB0::/28 v4suffix-length: 32 (unable to exclude
> common bits due to non-contiguous IPv4 allocations) 6rd CE router IPv4
> address: 192.0.2.1 6rd site IPv6 prefix: 2001:0DBC:0000:2010::/60
> 
> 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.




From owen at delong.com  Fri Oct 15 16:31:46 2010
From: owen at delong.com (Owen DeLong)
Date: Fri, 15 Oct 2010 13:31:46 -0700
Subject: [arin-ppml] Draft Policy 2010-12: IPv6 Subsequent Allocation -
	Last Call (text revised)
In-Reply-To: <4CB8B4D6.60709@townsley.net>
References: <4CB5F5FD.7090806@arin.net> <4CB8B4D6.60709@townsley.net>
Message-ID: <AFCC6C64-E6DF-4200-AA70-FC4BF4B2E919@delong.com>


On Oct 15, 2010, at 1:08 PM, Mark Townsley wrote:

> 
> ARIN and all,
> 
> This has been an enlightening exchange over the past week or so. I
> appreciate all time and attention devoted to this topic, as well as the
> lively exchanges by all. For my part, I am now off to enjoy a final
> weekend at home before traveling four out of the next five weeks.
> 
> For the record, my position on the last call below is:
> 
> 1. I am very pleased to see a policy for subsequent allocation, and that
> ARIN recognizes the need for 6rd at this stage of deployment and has
> acted accordingly. I admit that there are no ideal alternatives, all are
> tradeoffs at one level or another.
> 
> 2. One the following two revisions
> 
> "- Requests for transition space will not be exempt from returns."
> "- Allocations will be from a designated block."
> 
> I do not support use of a segregated space for all 6rd allocations, nor
> the idea that return of that space could happen in bulk while
> individual allocations were still in use by some ISPs. However, I would
> support individual review and return of space when individual ISPs are
> finished with it. I admit to not fully understanding what the return
> process might be though, which could be clouding my judgment. Perhaps a
> future date, 7-10 years has been suggested here by some, before any such
> return could be considered would be useful for other folks like me to
> have less concern.
> 
I am not in favor of establishing any definite end date at this time.
The policy provides for 3-year reviews of utilization, but, does not
provide for reclamation as part of that review unless there is a lack
of utilization.

I think this is reasonable.

> 3. On the following revision:
> 
> "- /24 was added as the maximum prefix size."
> 
> /24 for 6rd seems generous, /28 would probably suffice, particularly if
> it would come with less "strings attached" in terms of possibility of
> return before the ISP is ready for the space to be returned.
> 
I would not favor reducing what you call "strings attached" even if we
reduced the size to /32. The /24 allows for /56 assignments through
6rd to end sites. /28 would only facilitate /60s which I think will set
a bad precedent for home network size.

While I realize that Free is using /60s, that doesn't mean i have to think
it is in any way desirable that they do so.

> 4. Above all, I do not want to see any delay in implementation of a
> policy that allows for SPs to get a subsequent allocation of at least
> /28 for 6rd deployment in the ARIN region.
> 
I think that /24 and /28 would be approvable on the same time table.
I haven't heard anyone speaking in opposition to this policy in last
call.

Frankly, I think that the concerns you have expressed are mostly
not actually present in the policy as written.  I would be surprised
if any meaningful effort was made to deprecate these addresses
before there were viable native solutions available for all technologies
and the vast majority of providers had made the switch to native.

While I think it is important to preserve the ability to make a
communal decision to deprecate these addresses, I am not at
all in favor of deprecating them rapidly or prematurely.

Owen

> Best Regards,
> 
> - Mark
> 
> 
> 
> 
> On 10/13/10 8:10 PM, ARIN wrote:
> 
>> The ARIN Advisory Council (AC) met on 8 October 2010 and decided to
>> send the following draft policy to last call:
>> 
>>   Draft Policy 2010-12: IPv6 Subsequent Allocation
>> 
>> The AC made the following revisions to the text:
>>  - /24 was added as the maximum prefix size.
>>  - Allocations will be from a designated block.
>>  - Requests for transition space will not be exempt from returns.
>> 
>> Feedback is encouraged during the last call period. All comments should
>> be provided to the Public Policy Mailing List. Last call for 2010-12
>> will expire on 27 October 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,
>> 
>> Communications and Member Services
>> American Registry for Internet Numbers (ARIN)
>> 
>> 
>> ## * ##
>> 
>> 
>> Draft Policy 2010-12
>> IPv6 Subsequent Allocation
>> 
>> Version/Date: 13 October 2010
>> 
>> Policy statement:
>> 
>> Modify 6.5.2.1 Subsequent allocation criteria. Add the following:
>> 
>> Subsequent allocations will also be considered for deployments that
>> cannot be accommodated by, nor were accounted for, under the initial
>> allocation. Justification for the subsequent subnet size will be based
>> on the plan and technology provided with a /24 being the maximum allowed
>> for a transition technology. Justification for these allocations will be
>> reviewed every 3 years and reclaimed if it is not in use. All such
>> allocations for transitional technology will be made from a block
>> designated for this purpose.
>> 
>> Rationale:
>> 
>> Current organizations cannot get an allocation for a IPv6 transitional
>> technology if they have already received their initial allocation of
>> IPv6. The reason they cannot get an additional IPV6 allocation is
>> because they don't meet the HD ratio for a subsequent allocation and
>> they don't want to use their initial assignment because it is
>> insufficient, mapped out for other long term plans, or already has
>> portions in use.
>> 
>> An alternative proposal to permit more allocations was submitted that
>> supported 6rd but since then community members have come forward with
>> concern that this should support not just one particular technology but
>> any that enable v6 deployment.
>> 
>> Justification Example: Below is an example of how the details for a
>> technology and its subnet requirements could be provided as
>> justification. This example is based of 6rd.
>> 
>> 6rd is intended to be an incremental method for deploying IPv6 and
>> bridge the gap for End Users to the IPv6 Internet. The method provides a
>> native dual-stack service to a subscriber site by leveraging existing
>> infrastructure. If an entity already has a /32 of IPv6 they can not use
>> the same /32 for native IPv6 as they do for the 6rd routing and a
>> separate minimum size of a /32 is required while a larger subnet like a
>> /28 may be needed based on a non-contiguous IPv4 addressing plan.
>> 
>> The 6rd prefix is an RIR delegated IPv6 prefix. It must encapsulate an
>> IPv4 address and must be short enough so that a /56 or /60 can be given
>> to subscribers. This example shows how the 6rd prefix is created based
>> on a /32 IPv6 prefix using RFC1918 address space from 10.0.0.0/8:
>> 
>> SP IPv6 prefix: 2001:0DB8::/32 v4suffix-length: 24 (from 10/8, first
>> octet (10) is excluded from the encoding) 6rd CE router IPv4 address:
>> 10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56
>> 
>> This example shows how the 6rd prefix is created based on a /28 IPv6
>> prefix using one of several non-contiguous global address ranges:
>> 
>> SP IPv6 prefix: 2001:0DB0::/28 v4suffix-length: 32 (unable to exclude
>> common bits due to non-contiguous IPv4 allocations) 6rd CE router IPv4
>> address: 192.0.2.1 6rd site IPv6 prefix: 2001:0DBC:0000:2010::/60
>> 
>> Timetable for implementation: Immediate
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From ppml at rs.seastrom.com  Fri Oct 15 16:38:26 2010
From: ppml at rs.seastrom.com (Robert E. Seastrom)
Date: Fri, 15 Oct 2010 16:38:26 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <AANLkTikvgOQVav9zub3-zun+0tBooweSjUwoOO_7GF5M@mail.gmail.com>
	(Lorenzo Colitti's message of "Fri, 15 Oct 2010 09:16:07 -0700")
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938134250@EMV01-UKBR.domain1.systemhost.net>
	<4CB8335B.70805@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B4239381343EE@EMV01-UKBR.domain1.systemhost.net>
	<AANLkTikvgOQVav9zub3-zun+0tBooweSjUwoOO_7GF5M@mail.gmail.com>
Message-ID: <86k4lj5gzh.fsf@seastrom.com>


Lorenzo Colitti <lorenzo at google.com> writes:

> On Fri, Oct 15, 2010 at 5:13 AM, <[[michael.dillon at bt.com]]> wrote:

>
>                Seems to me that you are just spreading FUD. CPE
>      vendors are going to implement according to DOCSIS 3.0 and
>      Broadband Forum specs. They are not going to make up their own
>      thing.

> Please base your statements on facts. I am testing IPv6-capable CPEs
> right now and some of them do not support anything other than
> /64. Fortunately the ones I know of are either in beta or support
> automatic updates, so I am trying to get them fixed.

{{Citation needed}} 

-r



From bill at herrin.us  Fri Oct 15 19:30:08 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 15 Oct 2010 19:30:08 -0400
Subject: [arin-ppml] Controlling the IPv6 address consumption rate
In-Reply-To: <AANLkTikuWbvAPUEJb_gp0zjv+fHw9pBwPwHnyP0nEk2h@mail.gmail.com>
References: <AANLkTik+5zsTzepnf40faZVgOxNF2OOeMt-3o4p2wLEw@mail.gmail.com>
	<2B6D8499-377A-40FF-8263-79C6A3BFD3AE@delong.com>
	<AANLkTikQqyg8508hSUbxM5gMp=_BSuf41jaRByztaGuh@mail.gmail.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B4239378EABD9@EMV01-UKBR.domain1.systemhost.net>
	<AANLkTinCOsaG-c9Yp3GA-FXbO3TOFE418ZpXrB4TXdvt@mail.gmail.com>
	<AANLkTikuWbvAPUEJb_gp0zjv+fHw9pBwPwHnyP0nEk2h@mail.gmail.com>
Message-ID: <AANLkTimifNggNxSAj3f7uvgMXTMR2i402697Mv8mxq6O@mail.gmail.com>

On Fri, Oct 15, 2010 at 1:51 PM, Heather Schiller
<heather.skanks at gmail.com> wrote:
> On Wed, Oct 13, 2010 at 11:16 AM, William Herrin <bill at herrin.us> wrote:
>> At the same time (maybe even in the same RFC), the IETF decided that
>> end users would not multihome using BGP with multiple ISPs under IPv6.
>> That too is the official standard.
>
> ? I don't believe IETF ever "decided that end users would not
> multihome using bgp with multiple ISP's" ? It was more like they
> repeatedly tried to create an alternate method of multihoming that did
> not rely on *deaggregation*

Hi Heather,

And we're still trying. I spent the last three years in the IRTF RRG
and we still don't have either a consensus approach or a technology
which can be proven to do useful work in even the corner cases. There
are some really clever ideas there with some real promise, but not
enough of them are being built and tried to answer some of the
identified unknowns and lock in on what might work.

> But then we
> passed the end user IPv6 assignment policy and instantly lost the much
> of the motivation to complete that work.

I've harped on it before, but if we had a pool of cheap, non-need
based registry-assigned addresses that were explicitly and
intentionally barred from BGP, the combination of all the kiddies
wanting PI and the availability of PI addresses might restore some of
the motivation to develop a tech capable of using them.


>> We always listen to what the folks in the IETF have to say, but
>> sometimes they don't know what the eff they're talking about.
>
> ?Maybe rather than just listening to what the folks in IETF have to
> say, operators should participate more, in order to develop solutions
> that are operationally feasible. ?Be a part of the solution.

In spirit I'm with you 100%. Pragmatically though, the number of folks
who enjoy both development and operations is a lot smaller than the
number who enjoy one or the other.


On Fri, Oct 15, 2010 at 2:44 PM, Joel Jaeggli <joelja at bogus.com> wrote:
>> On Wed, Oct 13, 2010 at 11:16 AM, William Herrin <bill at herrin.us> wrote:
>>> We always listen to what the folks in the IETF have to say, but
>>> sometimes they don't know what the eff they're talking about.
>
> I'm not convinced that you do listen, or that if you do listen that you
> agree.

Joel,

I can set your mind at ease for the second part. For the former,
you'll have to decide for yourself whether I made an adequate effort
to understand your viewpoint before disagreeing with it.


> It's pretty
> easy to characterize the activities of 15-18 years ago as deluded or
> misguided, it seems to be harder for us to accept that what was done was
> as good as it could be under the circumstances and that we need to move
> on changing what we have in minor ways rather than boiling the baby (who
> is now a teenager in any event) in the bathwater.

We should change things exactly as much as experience and a healthy
caution reveals is needed. If you did as a good a job on IPv6 as was
done on IPv4, you can expect as little change as IPv4 underwent. Did
you? And when we think back, just how minor were IPv4's needful
changes like CIDR and NAT?

Yesteryear's best decisions were rarely deluded or misguided.
Following them uncritically today can be.

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 ALanstein at FireEye.com  Fri Oct 15 20:10:14 2010
From: ALanstein at FireEye.com (Alex Lanstein)
Date: Fri, 15 Oct 2010 17:10:14 -0700
Subject: [arin-ppml] Policy requests
Message-ID: <60B0F2124D07B942988329B5B7CA393D03469FAFAC@mail2.FireEye.com>

First off, apologies if any of these have been brought up before, but I've spoken with a number of ARIN members and have each time been encouraged to post some thoughts to PPML.  I understand all new policies must come from the community, but I don't doubt I'll be showing my naivet? with how things work at ARIN.

1) ICANN has a policy for certain TLDs that WHOIS details must be accurate.  There are many issues with this, such as enforceability and the use of privacy proxies, but enforcement is impossible without a clear policy to begin with.  Is there a reason ARIN does not have a policy against fraudulent SWIPing and fake PTR records?  I was told to look at Paragraph 8 of the RSA, but it really doesn't address my concern --- https://www.arin.net/resources/agreements/rsa.pdf.

I think it makes sense that ARIN have the same policies on accuracy of SWIPing, and that there should be some language that prevents someone from creating fraudulent reverse records.

2) I believe I should be able to review the network diagrams for requests of IP allocations that are not flagged as confidential.  I understand there needs to be a mechanism to protect trade secrets, but at the same time, it would make sense to be as open as possible.  I wouldn't expect to see the blueprints for a new CIA building, but I would for a new road in my town.

3) I think there should be a mechanism to allow researchers to advertise IP space that has been abandoned by criminals.  There are lots of corner cases of course, but this sort of thing is already happening, with 1/8 being advertised recently as a research project.  Perhaps the easiest way to accommodate this would be to wait until the IP allocation expires due to non-payment, then assign that to a researcher.  For instance, it would be very nice to be able to advertise ex-mccolo space, sinkhole the data to Shadowserver, then provide telemetry back into the ISP community about infections.  

Thanks,

Alex Lanstein
(not speaking for my employer)

From heather.skanks at gmail.com  Sat Oct 16 00:41:26 2010
From: heather.skanks at gmail.com (Heather Schiller)
Date: Sat, 16 Oct 2010 00:41:26 -0400
Subject: [arin-ppml] Policy requests
In-Reply-To: <60B0F2124D07B942988329B5B7CA393D03469FAFAC@mail2.FireEye.com>
References: <60B0F2124D07B942988329B5B7CA393D03469FAFAC@mail2.FireEye.com>
Message-ID: <AANLkTikQzbbFNdRRwM1Q-AhJedZQDUhQV9kaTaqY_fdN@mail.gmail.com>

Comments (lots!) in line..

On Fri, Oct 15, 2010 at 8:10 PM, Alex Lanstein <ALanstein at fireeye.com> wrote:
> First off, apologies if any of these have been brought up before, but I've spoken with a number of ARIN members and have each time been encouraged to post some thoughts to PPML. ?I understand all new policies must come from the community, but I don't doubt I'll be showing my naivet? with how things work at ARIN.
>
> 1) ICANN has a policy for certain TLDs that WHOIS details must be accurate. ?There are many issues with this, such as enforceability and the use of privacy proxies, but enforcement is impossible without a clear policy to begin with. ?Is there a reason ARIN does not have a policy against fraudulent SWIPing and fake PTR records? ?I was told to look at Paragraph 8 of the RSA, but it really doesn't address my concern --- https://www.arin.net/resources/agreements/rsa.pdf.
>
> I think it makes sense that ARIN have the same policies on accuracy of SWIPing, and that there should be some language that prevents someone from creating fraudulent reverse records.
>

Try section 5 of the RSA for the reassigning bit: "(b) Responsibility
for Directory Services Data. Applicant is responsible 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."

and section 3 of the RSA for the rest: "If, at any point, including
during the application process and/or the pendency of this Agreement,
Applicant actively misrepresents, falsifies, or otherwise fraudulently
provides information, ARIN may immediately terminate this Agreement."

There is an ARIN policy that requires staff do POC validation - the
data about which resources have invalid POC data is available through
the bulk whois process.  In theory one could obtain the list of
prefixes with invalid POC data and use it in a variety of ways,
examples: not announce the prefix, not accept the prefix, filter
traffic from the prefix, not accept mail from the prefix, call your
customer and ask them to update the data, update your own invalid POC
records, etc.

Poc Validation policy: https://www.arin.net/policy/nrpm.html#three6
Bulk Whois process: https://www.arin.net/resources/request/bulkwhois.html

Take a look at this proposed text:
https://www.arin.net/policy/proposals/2010_14.html
This text will probably be broken up and reworked, for the spring
meeting.  You may want to provide some feedback to Chris G or one of
the AC shepherds - Providing specific examples of changes you propose
- even providing text - would go a long way.   For example, you
mention preventing someone from creating fraudulent SWIP records -
would you propose that staff take some step to verify the contact
information is valid when a reassign/reallocate template is submitted?

ARIN has a fraud reporting process:  https://www.arin.net/resources/fraud/
Which you can use if you believe that someone has, amongst other
things, submitted false utilization or organization information.

Unfortunately, ARIN has a little bit less control over the data that
is submitted to them via SWIP for reassignment records.  They don't
have a direct relationship with the organization that an ISP delegates
a resource to, making it harder for ARIN to know/verify that the
reassignment information is correct.

For what it's worth - I think that the majority of the data that goes
into SWIP reassignment records, is accurate to the best of the
submitter's knowledge at the time - but a lot of it has gotten stale
over the years.  The POC validation process aims to help that.  I
think that the intentionally submitted fraudulent SWIP reassignment
records are a fraction of the SWIP reassignments - but the problem is
exacerbated by the bad actors using the space.

> 2) I believe I should be able to review the network diagrams for requests of IP allocations that are not flagged as confidential. ?I understand there needs to be a mechanism to protect trade secrets, but at the same time, it would make sense to be as open as possible. ?I wouldn't expect to see the blueprints for a new CIA building, but I would for a new road in my town.
>

I strongly disagree.  Many companies only provide copies of their
network diagrams under NDA - be it to ARIN, their ISP or any other
vendor.  For many companies, their network architecture *is* their
product, it is their 'trade secret'

I even disagree with publicly disclosing the non- network diagram
details of a request - such as subnetting plans and existing and
projected utilization.  In a request for space you may need to detail
your deployment and business plans for the next 6 months or in the
case of IPv6, for the next 1, 2 and 5 years.  Publicly disclosing this
information can give your competitors a road map of your business plan
for the next 5 years.

How would you propose to draw the line (in policy text) between CIA
building and new road in your town?

I'm not sure I understand what it will buy you anyway - If the bad
guys are lying to get space, they are probably lying about their
network architecture.   Are you wanting this as a check on ARIN?  or
to be able to uncover some helpful clue about the bad guys?

>
> 3) I think there should be a mechanism to allow researchers to advertise IP space that has been abandoned by criminals. ?There are lots of corner cases of course, but this sort of thing is already happening, with 1/8 being advertised recently as a research project. ?Perhaps the easiest way to accommodate this would be to wait until the IP allocation expires due to non-payment, then assign that to a researcher. ?For instance, it would be very nice to be able to advertise ex-mccolo space, sinkhole the data to Shadowserver, then provide telemetry back into the ISP community about infections.

1/8 is NOT a research project!  It was allocated to APNIC!  They have
allocated significant portions of it.  I believe they have not
allocated the portions that were deemed to generate too much
background noise.  They did do some test announcements when they first
received it, in order to determine how polluted it was.

I don't disagree with the idea.. I'm not sure it's an issue for the
NRPM (policy manual) but more an ARIN operational practice.  You might
try submitting it to the ARIN Consultation and Suggestion process:
https://www.arin.net/participate/acsp/index.html

>
> Thanks,
>
> Alex Lanstein
> (not speaking for my employer)
> _______________________________________________
> 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 ppml at rs.seastrom.com  Sat Oct 16 07:31:19 2010
From: ppml at rs.seastrom.com (Robert E. Seastrom)
Date: Sat, 16 Oct 2010 07:31:19 -0400
Subject: [arin-ppml] Policy requests
In-Reply-To: <AANLkTikQzbbFNdRRwM1Q-AhJedZQDUhQV9kaTaqY_fdN@mail.gmail.com>
	(Heather Schiller's message of "Sat, 16 Oct 2010 00:41:26 -0400")
References: <60B0F2124D07B942988329B5B7CA393D03469FAFAC@mail2.FireEye.com>
	<AANLkTikQzbbFNdRRwM1Q-AhJedZQDUhQV9kaTaqY_fdN@mail.gmail.com>
Message-ID: <86ocaupe60.fsf@seastrom.com>


Heather Schiller <heather.skanks at gmail.com> writes:

> Comments (lots!) in line..

+1 to pretty much everything Heather said.  One thing added on is below...

>> 3) I think there should be a mechanism to allow researchers to
>> advertise IP space that has been abandoned by criminals. ??There
>> are lots of corner cases of course, but this sort of thing is
>> already happening, with 1/8 being advertised recently as a research
>> project. ??Perhaps the easiest way to accommodate this would be to
>> wait until the IP allocation expires due to non-payment, then
>> assign that to a researcher. ??For instance, it would be very nice
>> to be able to advertise ex-mccolo space, sinkhole the data to
>> Shadowserver, then provide telemetry back into the ISP community
>> about infections.
>
> 1/8 is NOT a research project!  It was allocated to APNIC!  They have
> allocated significant portions of it.  I believe they have not
> allocated the portions that were deemed to generate too much
> background noise.  They did do some test announcements when they first
> received it, in order to determine how polluted it was.
>
> I don't disagree with the idea.. I'm not sure it's an issue for the
> NRPM (policy manual) but more an ARIN operational practice.  You might
> try submitting it to the ARIN Consultation and Suggestion process:
> https://www.arin.net/participate/acsp/index.html

Actually there is already a policy for this.  See section 11 of the NRPM.

https://www.arin.net/policy/nrpm.html#eleven

And bring your proposals, please!

Note that this is for pure research.  If you're planning to do traffic
analysis and sell the telemetry, this practice doesn't fly under section 11.

-r



From mpetach at netflight.com  Sat Oct 16 13:32:25 2010
From: mpetach at netflight.com (Matthew Petach)
Date: Sat, 16 Oct 2010 10:32:25 -0700
Subject: [arin-ppml] Draft Policy 2010-12: IPv6 Subsequent Allocation -
 Last Call (text revised)
In-Reply-To: <4CB5F5FD.7090806@arin.net>
References: <4CB5F5FD.7090806@arin.net>
Message-ID: <AANLkTi=Pq5n6=j4okFN=M=U9-uO=bYEfpaimLAQcM53+@mail.gmail.com>

On Wed, Oct 13, 2010 at 11:10 AM, ARIN <info at arin.net> wrote:
> The ARIN Advisory Council (AC) met on 8 October 2010 and decided to
> send the following draft policy to last call:
...
> Draft Policy 2010-12
> IPv6 Subsequent Allocation
>
> Version/Date: 13 October 2010
>
> Policy statement:
>
> Modify 6.5.2.1 Subsequent allocation criteria. Add the following:
>
> Subsequent allocations will also be considered for deployments that
> cannot be accommodated by, nor were accounted for, under the initial
> allocation. Justification for the subsequent subnet size will be based
> on the plan and technology provided with a /24 being the maximum allowed
> for a transition technology. Justification for these allocations will be
> reviewed every 3 years and reclaimed if it is not in use. All such
> allocations for transitional technology will be made from a block
> designated for this purpose.

I support 2010-12, but would like to see the phrase "reclaimed if it is not
in use" replaced with "reclaimed if it is no longer in use for transitional
purposes."  This space is *just* for use for transitional technologies,
not for native v6, there are separate allocation policies in place to handle
native deployments, and we need to ensure that people do no simply
start putting native customers on this space, and then never give it
up, citing the "still in use" clause.  I really, really don't want to see
transitional mechanisms turn into the new swamp.  Once the transition
is done, and you've gone native...give back the transitional block, and
move on.

Thanks!

Matt


From owen at delong.com  Sat Oct 16 13:36:30 2010
From: owen at delong.com (Owen DeLong)
Date: Sat, 16 Oct 2010 10:36:30 -0700
Subject: [arin-ppml] Draft Policy 2010-12: IPv6 Subsequent Allocation -
	Last Call (text revised)
In-Reply-To: <AANLkTi=Pq5n6=j4okFN=M=U9-uO=bYEfpaimLAQcM53+@mail.gmail.com>
References: <4CB5F5FD.7090806@arin.net>
	<AANLkTi=Pq5n6=j4okFN=M=U9-uO=bYEfpaimLAQcM53+@mail.gmail.com>
Message-ID: <E3539DAE-46D2-4BD0-9DB5-4480BEB954F0@delong.com>

I support this change.

Owen

On Oct 16, 2010, at 10:32 AM, Matthew Petach wrote:

> On Wed, Oct 13, 2010 at 11:10 AM, ARIN <info at arin.net> wrote:
>> The ARIN Advisory Council (AC) met on 8 October 2010 and decided to
>> send the following draft policy to last call:
> ...
>> Draft Policy 2010-12
>> IPv6 Subsequent Allocation
>> 
>> Version/Date: 13 October 2010
>> 
>> Policy statement:
>> 
>> Modify 6.5.2.1 Subsequent allocation criteria. Add the following:
>> 
>> Subsequent allocations will also be considered for deployments that
>> cannot be accommodated by, nor were accounted for, under the initial
>> allocation. Justification for the subsequent subnet size will be based
>> on the plan and technology provided with a /24 being the maximum allowed
>> for a transition technology. Justification for these allocations will be
>> reviewed every 3 years and reclaimed if it is not in use. All such
>> allocations for transitional technology will be made from a block
>> designated for this purpose.
> 
> I support 2010-12, but would like to see the phrase "reclaimed if it is not
> in use" replaced with "reclaimed if it is no longer in use for transitional
> purposes."  This space is *just* for use for transitional technologies,
> not for native v6, there are separate allocation policies in place to handle
> native deployments, and we need to ensure that people do no simply
> start putting native customers on this space, and then never give it
> up, citing the "still in use" clause.  I really, really don't want to see
> transitional mechanisms turn into the new swamp.  Once the transition
> is done, and you've gone native...give back the transitional block, and
> move on.
> 
> Thanks!
> 
> Matt
> _______________________________________________
> 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 ppml at rs.seastrom.com  Sat Oct 16 14:19:55 2010
From: ppml at rs.seastrom.com (Robert E. Seastrom)
Date: Sat, 16 Oct 2010 14:19:55 -0400
Subject: [arin-ppml] Draft Policy 2010-12: IPv6 Subsequent Allocation -
	Last Call (text revised)
In-Reply-To: <AANLkTi=Pq5n6=j4okFN=M=U9-uO=bYEfpaimLAQcM53+@mail.gmail.com>
	(Matthew Petach's message of "Sat, 16 Oct 2010 10:32:25 -0700")
References: <4CB5F5FD.7090806@arin.net>
	<AANLkTi=Pq5n6=j4okFN=M=U9-uO=bYEfpaimLAQcM53+@mail.gmail.com>
Message-ID: <86pqvaknjo.fsf@seastrom.com>


Matthew Petach <mpetach at netflight.com> writes:

> I support 2010-12, but would like to see the phrase "reclaimed if it is not
> in use" replaced with "reclaimed if it is no longer in use for transitional
> purposes."  This space is *just* for use for transitional technologies,
> not for native v6, there are separate allocation policies in place to handle
> native deployments, and we need to ensure that people do no simply
> start putting native customers on this space, and then never give it
> up, citing the "still in use" clause.  I really, really don't want to see
> transitional mechanisms turn into the new swamp.  Once the transition
> is done, and you've gone native...give back the transitional block, and
> move on.

This would be a good improvement.  I support it.

-r



From michael.dillon at bt.com  Mon Oct 18 06:31:07 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 18 Oct 2010 11:31:07 +0100
Subject: [arin-ppml] Policy requests
In-Reply-To: <60B0F2124D07B942988329B5B7CA393D03469FAFAC@mail2.FireEye.com>
References: <60B0F2124D07B942988329B5B7CA393D03469FAFAC@mail2.FireEye.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423938134983@EMV01-UKBR.domain1.systemhost.net>

> I think it makes sense that ARIN have the same policies on accuracy of
> SWIPing, and that there should be some language that prevents someone
> from creating fraudulent reverse records.

Something like this has been tried and it was contentious. I don't think
that you will have much luck with this.

> 2) I believe I should be able to review the network diagrams for
> requests of IP allocations that are not flagged as confidential.  I
> understand there needs to be a mechanism to protect trade secrets, but
> at the same time, it would make sense to be as open as possible.  I
> wouldn't expect to see the blueprints for a new CIA building, but I
> would for a new road in my town.

All network diagrams are currently flagged as confidential since they are
received under the blanket NDA for communications with Registry Services.
You would need to change policy to, first of all, require network diagrams
to be filed, and secondly, to require them to be public and not under
the NDA. Even then this would not apply to any network diagrams filed in
the past. Of course, many orgs would redact their diagrams before filing.

> 3) I think there should be a mechanism to allow researchers to
> advertise IP space that has been abandoned by criminals.  There are
> lots of corner cases of course, but this sort of thing is already
> happening, with 1/8 being advertised recently as a research project.
> Perhaps the easiest way to accommodate this would be to wait until the
> IP allocation expires due to non-payment, then assign that to a
> researcher.  For instance, it would be very nice to be able to
> advertise ex-mccolo space, sinkhole the data to Shadowserver, then
> provide telemetry back into the ISP community about infections.

This is an interesting proposal and I think you should pursue it first.
ARIN has some provisions for experimental use and you may find it
useful to propose this as an extension. As long as these allocations
are time bounded in some way, this sounds like something that the
community might accept.

--Michael Dillon




From springer at inlandnet.com  Tue Oct 19 11:16:21 2010
From: springer at inlandnet.com (John Springer)
Date: Tue, 19 Oct 2010 08:16:21 -0700 (PDT)
Subject: [arin-ppml] Best Wishes
Message-ID: <20101019081411.Q75715@mail.inlandnet.com>

Let me be one of the first to congratulate you.
It's always good to talk to you. See you next time.

John Springer                   Manager, Information Technology
Inland Telephone Company                      Tel: 509.649.4638
Box 171 - 103 S. Second St                    Fax: 509.649.3411
Roslyn, WA  98941-0171                   springer at inlandnet.com



From packetgrrl at gmail.com  Tue Oct 19 11:20:24 2010
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Tue, 19 Oct 2010 09:20:24 -0600
Subject: [arin-ppml] Best Wishes
In-Reply-To: <20101019081411.Q75715@mail.inlandnet.com>
References: <20101019081411.Q75715@mail.inlandnet.com>
Message-ID: <AANLkTi=MdJy6rc09A2USdapNbn387O0Tf2yKeeKibTTL@mail.gmail.com>

Thanks John!  I appreciate it!

On Tue, Oct 19, 2010 at 9:16 AM, John Springer <springer at inlandnet.com>wrote:

> Let me be one of the first to congratulate you.
> It's always good to talk to you. See you next time.
>
> John Springer                   Manager, Information Technology
> Inland Telephone Company                      Tel: 509.649.4638
> Box 171 - 103 S. Second St                    Fax: 509.649.3411
> Roslyn, WA  98941-0171                   springer at inlandnet.com
>
> _______________________________________________
> 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/20101019/36674163/attachment.htm>

From springer at inlandnet.com  Tue Oct 19 11:54:44 2010
From: springer at inlandnet.com (John Springer)
Date: Tue, 19 Oct 2010 08:54:44 -0700 (PDT)
Subject: [arin-ppml] Best Wishes
In-Reply-To: <AANLkTi=MdJy6rc09A2USdapNbn387O0Tf2yKeeKibTTL@mail.gmail.com>
References: <20101019081411.Q75715@mail.inlandnet.com>
	<AANLkTi=MdJy6rc09A2USdapNbn387O0Tf2yKeeKibTTL@mail.gmail.com>
Message-ID: <20101019084944.L75715@mail.inlandnet.com>

Apologies to the list for the noise.


From lorenzo at google.com  Wed Oct 20 23:58:05 2010
From: lorenzo at google.com (Lorenzo Colitti)
Date: Wed, 20 Oct 2010 20:58:05 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <86k4lj5gzh.fsf@seastrom.com>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938134250@EMV01-UKBR.domain1.systemhost.net>
	<4CB8335B.70805@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B4239381343EE@EMV01-UKBR.domain1.systemhost.net>
	<AANLkTikvgOQVav9zub3-zun+0tBooweSjUwoOO_7GF5M@mail.gmail.com>
	<86k4lj5gzh.fsf@seastrom.com>
Message-ID: <AANLkTikHzGvLyxmY=4U4JWN5Y2f_XsQFKvkZX5w4==p3@mail.gmail.com>

On Fri, Oct 15, 2010 at 1:38 PM, Robert E. Seastrom <ppml at rs.seastrom.com>wrote:

> > Please base your statements on facts. I am testing IPv6-capable CPEs
> > right now and some of them do not support anything other than
> > /64. Fortunately the ones I know of are either in beta or support
> > automatic updates, so I am trying to get them fixed.
>
> {{Citation needed}}


I can't reveal the manufacturer as it's unreleased code that I was testing
under NDA. However, it is a manufacturer that is commonly found on store
shelves.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101020/4c729432/attachment.htm>

From mueller at syr.edu  Sun Oct 24 03:07:16 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Sun, 24 Oct 2010 03:07:16 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <015201cb6bfd$97e9a200$c7bce600$@net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
	<6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com>
	<4CB777FB.20102@townsley.net>
	<5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com>
	<015201cb6bfd$97e9a200$c7bce600$@net>
Message-ID: <75822E125BCB994F8446858C4B19F0D70AC108D429@SUEX07-MBX-04.ad.syr.edu>


...financial backpressure will be much more effective than any proscriptive language that makes it past ppml.

This is definitely true

The hardest part of that approach is that the fee for a provider that is offering dual-stack /48 to each customer should be substantially less than a 6rd deployment offering /60. It is not ARIN's role to define end  product offerings, so differentiating the fee schedule for 2 ISPs requesting a /28 based on how they plan to use it is probably out of the question.

So how do you get your escalating fee structure without doing that? This sounds like a hard problem, administratively and economically. And you're right, once the fees are set they will establish parameters around which implementations are incentivized. I can't tell from all the list noise where things are going but it does seem to me that policy and fees are becoming more closely related all the time, which may require another look at ARIN's separation of the two.

--MM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101024/14b78831/attachment.htm>

From alh-ietf at tndh.net  Mon Oct 25 12:34:03 2010
From: alh-ietf at tndh.net (Tony Hain)
Date: Mon, 25 Oct 2010 09:34:03 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <75822E125BCB994F8446858C4B19F0D70AC108D429@SUEX07-MBX-04.ad.syr.edu>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>	<4CB5E076.7000701@townsley.net>	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>	<4CB6F929.3080207@townsley.net>	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>	<4CB707F7.9020506@townsley.net>	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>	<6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com>	<4CB777FB.20102@townsley.net>	<5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com>
	<015201cb6bfd$97e9a200$c7bce600$@net>
	<75822E125BCB994F8446858C4B19F0D70AC108D429@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <06e901cb7462$72580820$57081860$@net>

At the end of the day, ARIN really has to take a hands-off approach and let
the market sort out bad behavior. While I would like to see someone that is
locked into 6rd pay substantially more than someone offering a /48 to every
customer (because I want the space in the home to innovate), that is a
market decision to sort out. If the fee structure gets too wound around
block size in an attempt to drive out 6rd, the unintended consequence will
be that smaller providers will opt for the minimum size block and reduce the
prefix space they allow a customer  to have. This is counterproductive, and
economically punishes a /48 provider for the sins of the lingering 6rd
provider. 

 

Putting in hard dates to try to sunset an address range will just lead to
endless debate. Putting in an explicit cost that is only borne by those who
need the crutch will result in a natural weaning.  As much as I don't want
to see 6rd in a different prefix range, maybe that is the out here. Create a
specific fee schedule for a dedicated use prefix range, which would enable a
path forward in the short term at the same time it motivates providers to
get off of the technology asap. 

 

To avoid blocking small players from getting started, the fee would need to
be fairly low. A fee that is significantly less than a rounding error for a
large provider will not provide incentive to move. Finding the middle ground
... start with a modest fee, then after 3 years double the fee for
allocations within the 6rd prefix every year. Anyone with an IPv4 allocation
can get a 6rd /24 and keep it as long as they are willing to pay the
doubling fee. Any other IPv6 allocation they have would fall under the
current fee structure.

 

Tony

 

 

From: Milton L Mueller [mailto:mueller at syr.edu] 
Sent: Sunday, October 24, 2010 12:07 AM
To: Tony Hain
Cc: arin-ppml at arin.net
Subject: RE: [arin-ppml] Opposed to 2010-9 and 2010-12

 

 

.financial backpressure will be much more effective than any proscriptive
language that makes it past ppml. 

 

This is definitely true

 

The hardest part of that approach is that the fee for a provider that is
offering dual-stack /48 to each customer should be substantially less than a
6rd deployment offering /60. It is not ARIN's role to define end  product
offerings, so differentiating the fee schedule for 2 ISPs requesting a /28
based on how they plan to use it is probably out of the question.

 

So how do you get your escalating fee structure without doing that? This
sounds like a hard problem, administratively and economically. And you're
right, once the fees are set they will establish parameters around which
implementations are incentivized. I can't tell from all the list noise where
things are going but it does seem to me that policy and fees are becoming
more closely related all the time, which may require another look at ARIN's
separation of the two. 

 

--MM

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

From info at arin.net  Mon Oct 25 15:13:09 2010
From: info at arin.net (ARIN)
Date: Mon, 25 Oct 2010 15:13:09 -0400
Subject: [arin-ppml] draft-ietf-v6ops-3177bis-end-sites-00
Message-ID: <4CC5D6C5.4020104@arin.net>

The IETF Internet-Draft titled "IPv6 Address Assignment to End Sites" is
in last call on the v6ops mailing list. If you want to participate in
the last call, please do so on the v6ops list. Abstract and mailing list
information:

Abstract

    RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks
    in most cases. The Regional Internet Registries (RIRs) adopted that
    recommendation in 2002, but began reconsidering the policy in 2005.
    This document revisits and updates the RFC 3177 recommendations on
    the assignment of IPv6 address space to end sites.  The exact choice
    of how much address space to assign end sites is an issue for the
    operational community. The role of the IETF is limited to providing
    guidance on IPv6 architectural and operational considerations. This
    document reviews the architectural and operational considerations of
    end site assignments as well as the motivations behind the original
    3177 recommendations. Moreover, the document clarifies that a one-
    size-fits-all recommendation of /48 is not nuanced enough for the
    broad range of end sites and is no longer recommended as a single
    default.

    This document updates and replaces RFC 3177.

IETF IPv6 Operations (v6ops) information including mailing list archive
and subscription information is available at:
http://datatracker.ietf.org/wg/v6ops/charter/

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)






















From bill at herrin.us  Mon Oct 25 15:42:57 2010
From: bill at herrin.us (William Herrin)
Date: Mon, 25 Oct 2010 15:42:57 -0400
Subject: [arin-ppml] draft-ietf-v6ops-3177bis-end-sites-00
In-Reply-To: <4CC5D6C5.4020104@arin.net>
References: <4CC5D6C5.4020104@arin.net>
Message-ID: <AANLkTik8BNMM+trB0b_yk2kXcmSKJO6-p1YR6GDFVD2W@mail.gmail.com>

On Mon, Oct 25, 2010 at 3:13 PM, ARIN <info at arin.net> wrote:
> The IETF Internet-Draft titled "IPv6 Address Assignment to End Sites" is
> in last call on the v6ops mailing list. If you want to participate in
> the last call, please do so on the v6ops list. Abstract and mailing list
> information:
>
> Abstract
>
> ? RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks
> ? in most cases. The Regional Internet Registries (RIRs) adopted that
> ? recommendation in 2002, but began reconsidering the policy in 2005.
> ? This document revisits and updates the RFC 3177 recommendations on
> ? the assignment of IPv6 address space to end sites. ?The exact choice
> ? of how much address space to assign end sites is an issue for the
> ? operational community. The role of the IETF is limited to providing
> ? guidance on IPv6 architectural and operational considerations. This
> ? document reviews the architectural and operational considerations of
> ? end site assignments as well as the motivations behind the original
> ? 3177 recommendations. Moreover, the document clarifies that a one-
> ? size-fits-all recommendation of /48 is not nuanced enough for the
> ? broad range of end sites and is no longer recommended as a single
> ? default.
>
> ? This document updates and replaces RFC 3177.

This appears to be:

https://datatracker.ietf.org/doc/draft-ietf-v6ops-3177bis-end-sites/

Is that correct?



-- 
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 lea.roberts at stanford.edu  Mon Oct 25 15:58:09 2010
From: lea.roberts at stanford.edu (Lea Roberts)
Date: Mon, 25 Oct 2010 12:58:09 -0700 (PDT)
Subject: [arin-ppml] draft-ietf-v6ops-3177bis-end-sites-00
In-Reply-To: <AANLkTik8BNMM+trB0b_yk2kXcmSKJO6-p1YR6GDFVD2W@mail.gmail.com>
References: <4CC5D6C5.4020104@arin.net>
	<AANLkTik8BNMM+trB0b_yk2kXcmSKJO6-p1YR6GDFVD2W@mail.gmail.com>
Message-ID: <alpine.DEB.1.10.1010251257160.25295@networking.stanford.edu>

On Mon, 25 Oct 2010, William Herrin wrote:

> On Mon, Oct 25, 2010 at 3:13 PM, ARIN <info at arin.net> wrote:
>> The IETF Internet-Draft titled "IPv6 Address Assignment to End Sites" is
>> in last call on the v6ops mailing list. If you want to participate in
>> the last call, please do so on the v6ops list. Abstract and mailing list
>> information:
>>
>> Abstract
>>
>> ? RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks
>> ? in most cases. The Regional Internet Registries (RIRs) adopted that
>> ? recommendation in 2002, but began reconsidering the policy in 2005.
>> ? This document revisits and updates the RFC 3177 recommendations on
>> ? the assignment of IPv6 address space to end sites. ?The exact choice
>> ? of how much address space to assign end sites is an issue for the
>> ? operational community. The role of the IETF is limited to providing
>> ? guidance on IPv6 architectural and operational considerations. This
>> ? document reviews the architectural and operational considerations of
>> ? end site assignments as well as the motivations behind the original
>> ? 3177 recommendations. Moreover, the document clarifies that a one-
>> ? size-fits-all recommendation of /48 is not nuanced enough for the
>> ? broad range of end sites and is no longer recommended as a single
>> ? default.
>>
>> ? This document updates and replaces RFC 3177.
>
> This appears to be:
>
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-3177bis-end-sites/
>
> Is that correct?

yes, that is correct...   /Lea

From mueller at syr.edu  Tue Oct 26 12:39:22 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Tue, 26 Oct 2010 12:39:22 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <06e901cb7462$72580820$57081860$@net>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>
	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>
	<4CB5E076.7000701@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>
	<4CB6F929.3080207@townsley.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>
	<4CB707F7.9020506@townsley.net>
	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>
	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>
	<6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com>
	<4CB777FB.20102@townsley.net>
	<5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com>
	<015201cb6bfd$97e9a200$c7bce600$@net>
	<75822E125BCB994F8446858C4B19F0D70AC108D429@SUEX07-MBX-04.ad.syr.edu>
	<06e901cb7462$72580820$57081860$@net>
Message-ID: <75822E125BCB994F8446858C4B19F0D70AC125B318@SUEX07-MBX-04.ad.syr.edu>

worth pursuing further.

Putting in hard dates to try to sunset an address range will just lead to endless debate.

Agreed, but the escalating fees also require a somewhat arbitrary setting of the escalation rate. Double every year, or every two years? Doubling starts after [three][five][N] years?

Putting in an explicit cost that is only borne by those who need the crutch will result in a natural weaning.

Agreed

As much as I don't want to see 6rd in a different prefix range, maybe that is the out here. Create a specific fee schedule for a dedicated use prefix range, which would enable a path forward in the short term at the same time it motivates providers to get off of the technology asap.

That might work. Herrin was proposing segregation of prefix ranges for other purposes, got some flak but I can't remember exactly what for.

Another possibility might simply be to impose a 6rd surcharge that increases. If I am correct in assuming that 6rd users have to declare what they are doing in order to qualify for the larger blocks of addresses, the fee could be triggered by the declaration rather than the use of a specific address range.

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

From marty at akamai.com  Tue Oct 26 13:05:02 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Tue, 26 Oct 2010 13:05:02 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <75822E125BCB994F8446858C4B19F0D70AC125B318@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <C8EC827E.14C05%marty@akamai.com>




On 10/26/10 12:39 PM, "Milton L Mueller" <mueller at syr.edu> wrote:

worth pursuing further.


Putting in hard dates to try to sunset an address range will just lead to endless debate.

Agreed, but the escalating fees also require a somewhat arbitrary setting of the escalation rate. Double every year, or every two years? Doubling starts after [three][five][N] years?

Putting in an explicit cost that is only borne by those who need the crutch will result in a natural weaning.

Agreed

As much as I don?t want to see 6rd in a different prefix range, maybe that is the out here. Create a specific fee schedule for a dedicated use prefix range, which would enable a path forward in the short term at the same time it motivates providers to get off of the technology asap.

That might work. Herrin was proposing segregation of prefix ranges for other purposes, got some flak but I can?t remember exactly what for.

Another possibility might simply be to impose a 6rd surcharge that increases. If I am correct in assuming that 6rd users have to declare what they are doing in order to qualify for the larger blocks of addresses, the fee could be triggered by the declaration rather than the use of a specific address range.


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

From marty at akamai.com  Tue Oct 26 13:08:48 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Tue, 26 Oct 2010 13:08:48 -0400
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <75822E125BCB994F8446858C4B19F0D70AC125B318@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <C8EC8360.14C0A%marty@akamai.com>



[ Apologies for empty message; I was clicking "remove HTML" and it thought I
meant "send" ]

Inline:

On 10/26/10 12:39 PM, "Milton L Mueller" <mueller at syr.edu> wrote:

> worth pursuing further.
>  
> 
> Putting in hard dates to try to sunset an address range will just lead to
> endless debate. 
>  
> Agreed, but the escalating fees also require a somewhat arbitrary setting of
> the escalation rate. Double every year, or every two years? Doubling starts
> after [three][five][N] years?


It could be high at the onset and indexed to inventory. The higher
utilization of v6 could drive the costs of v4 higher or perhaps indexed to
some market cost of acquiring v4 assets for transfer. *shrug*.

-M<






From alh-ietf at tndh.net  Tue Oct 26 14:29:13 2010
From: alh-ietf at tndh.net (Tony Hain)
Date: Tue, 26 Oct 2010 11:29:13 -0700
Subject: [arin-ppml] Opposed to 2010-9 and 2010-12
In-Reply-To: <75822E125BCB994F8446858C4B19F0D70AC125B318@SUEX07-MBX-04.ad.syr.edu>
References: <20101013035520.5E0045AE2A2@drugs.dv.isc.org>	<2376C0DA-2491-40D4-B509-8C643C507A61@delong.com>	<4CB5E076.7000701@townsley.net>	<0F29D1BA57992E4CAB5AD2C9AE7B423938133CB0@EMV01-UKBR.domain1.systemhost.net>	<4CB6F929.3080207@townsley.net>	<0F29D1BA57992E4CAB5AD2C9AE7B423938133E80@EMV01-UKBR.domain1.systemhost.net>	<4CB707F7.9020506@townsley.net>	<D57A3ED6-3286-47E1-8BDA-4D5066D72AA4@delong.com>	<AANLkTikkBFDf4Lq9coCyeYXdRwEpLerAMeiPktPdQNB7@mail.gmail.com>	<6E489EC5-BE01-46E6-AA63-F7FF1F89303F@delong.com>	<4CB777FB.20102@townsley.net>	<5F0B969F-DBD9-446F-954E-1CC566E1EBB1@delong.com>
	<015201cb6bfd$97e9a200$c7bce600$@net>
	<75822E125BCB994F8446858C4B19F0D70AC108D429@SUEX07-MBX-04.ad.syr.edu>
	<06e901cb7462$72580820$57081860$@net>
	<75822E125BCB994F8446858C4B19F0D70AC125B318@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <030001cb753b$b23b92c0$16b2b840$@net>

Milton L Mueller wrote:
>worth pursuing further. 
>
>>Putting in hard dates to try to sunset an address range will 
>>just lead to endless debate. 
>
>Agreed, but the escalating fees also require a somewhat arbitrary 
>setting of the escalation rate. Double every year, or every two 
>years? Doubling starts after [three][five][N] years?

Yes the values are arbitrary, but not completely. Just about everyone can
find a way to move infrastructure in 3-5 years, particularly when there is
an obvious financial motivation. Also, no matter what values are picked,
people will game the system to their local advantage. Picking too short a
window will lead smaller players to wait to start any IPv6 deployment until
they can see that they will be able to complete an infrastructure swap
before the price increases significantly. Pick too large a window and the
motivator to move off the transition doesn't kick in for a longer period. At
the same time the price increment can be just about anything. I picked
doubling because that is easy to understand and just about everyone has seen
the math about where that quickly leads. 

The trick here is finding the balance that provides motivation to move off
6rd in the 5-7 year timeframe, without being so threatening that the large
players object up front because there is a real possibility they will end up
at a financial disadvantage after the price increase kicks in because they
have more infrastructure to move. If the initial fee is low enough, they
will not even notice the first couple of doublings, so I think double every
year after 3 is a reasonable middle ground to give the large players a good
5 year window before the price really starts to pick up. 

>>Putting in an explicit cost that is only borne by those who 
>>need the crutch will result in a natural weaning.  
>
>Agreed
>
>>As much as I don't want to see 6rd in a different prefix range, 
>>maybe that is the out here. Create a specific fee schedule for a 
>>dedicated use prefix range, which would enable a path forward in 
>>the short term at the same time it motivates providers to get off 
>>of the technology asap. 
>
>That might work. Herrin was proposing segregation of prefix ranges 
>for other purposes, got some flak but I can't remember exactly what 
>for.

I am not overly happy with the idea of 6rd being in a separate prefix from
what the isp would normally use, and I am not overly happy with the idea of
different charges for different address ranges. That said, I don't see any
clean way to deal with sun-setting a transition allocation other than
financial feedback. As you noted, even that path is arbitrary so it is not
all that clean. The advantage it has is the ability for people to build an
internal business case about moving off the transition allocation. Any
ad-hoc attempts at artificial reclamation and/or filtering will be met with
legal action because they will not be universally applied to or by all. As
much as there is an arbitrary nature to an escalating fee structure, if it
is agreed to up front and universally applied there is little ground for
future legal action to leverage.

>Another possibility might simply be to impose a 6rd surcharge that 
>increases. If I am correct in assuming that 6rd users have to 
>declare what they are doing in order to qualify for the larger blocks 
>of addresses, the fee could be triggered by the declaration rather 
>than the use of a specific address range. 

This would address my concern about using an identifiable range, and if
policy evolves to get us past the /32 strangulation mindset, might even
result in most providers keeping their initial allocation rather than having
to migrate between a transitional allocation and a long term one. A /32 is
intended for a startup with 0 customers, so every isp with an existing
customer base should have a good sized allocation to begin with, and there
is no reason to force them to renumber except to reclaim the 6rd oversized
allocation. If they all got a /24 now to support 6rd, then in 3 years had to
justify keeping that based on existing customers with native IPv6 or pay the
increasing 6rd fee, worst case should result in the smallest players
shrinking from a /24 to a /28. As long as they know up front that will be
the case, they can build their long term address plan to fit within the /28
so there is no need to renumber once 6rd is decommissioned. 

Tony






From info at arin.net  Wed Oct 27 10:54:32 2010
From: info at arin.net (ARIN)
Date: Wed, 27 Oct 2010 10:54:32 -0400
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated Transfer
	Policy - revised
Message-ID: <4CC83D28.90100@arin.net>

The proposal originator submitted a revised version of the proposal.

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal 119: Globally Coordinated Transfer Policy

Proposal Originator: Chris Grundemann, Martin Hannigan, Jason Schiller

Proposal Version: 2.0

Date: 27 October 2010

Proposal type: new

Policy term: permanent

Policy statement: Any RIR's resource registrant may transfer IPv4
addresses to the resource registrant of another RIR as long as the two
RIRs agree and exercise Internet stewardship and the values expressed in
RFC2050.

Rationale: Since individual RIRs now allow transfers, it makes sense to
be able to transfer between regions as well.

Timetable for implementation: upon ratification of all five RIRs

Timetable for de-implementation: upon change to this policy text in any RIR





From owen at delong.com  Wed Oct 27 13:12:16 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 27 Oct 2010 10:12:16 -0700
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated Transfer
	Policy - revised
In-Reply-To: <4CC83D28.90100@arin.net>
References: <4CC83D28.90100@arin.net>
Message-ID: <9D287A2B-C076-41CB-B2EC-DF19F988C40B@delong.com>

With the changes to language in this version, I can now support this
proposal once we enact appropriate language in ARIN policy
covering what is or is not an acceptable set of transfer conditions.

Owen

On Oct 27, 2010, at 7:54 AM, ARIN wrote:

> The proposal originator submitted a revised version of the proposal.
> 
> Regards,
> 
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Policy Proposal 119: Globally Coordinated Transfer Policy
> 
> Proposal Originator: Chris Grundemann, Martin Hannigan, Jason Schiller
> 
> Proposal Version: 2.0
> 
> Date: 27 October 2010
> 
> Proposal type: new
> 
> Policy term: permanent
> 
> Policy statement: Any RIR's resource registrant may transfer IPv4
> addresses to the resource registrant of another RIR as long as the two
> RIRs agree and exercise Internet stewardship and the values expressed in
> RFC2050.
> 
> Rationale: Since individual RIRs now allow transfers, it makes sense to
> be able to transfer between regions as well.
> 
> Timetable for implementation: upon ratification of all five RIRs
> 
> Timetable for de-implementation: upon change to this policy text in any RIR
> 
> 
> 
> _______________________________________________
> 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 marty at akamai.com  Wed Oct 27 14:05:16 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Wed, 27 Oct 2010 14:05:16 -0400
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated Transfer
 Policy - revised
In-Reply-To: <9D287A2B-C076-41CB-B2EC-DF19F988C40B@delong.com>
Message-ID: <C8EDE21C.14F0D%marty@akamai.com>




On 10/27/10 1:12 PM, "Owen DeLong" <owen at delong.com> wrote:

> With the changes to language in this version, I can now support this
> proposal once we enact appropriate language in ARIN policy
> covering what is or is not an acceptable set of transfer conditions.
> 


English?


Best regards,

-M<




From owen at delong.com  Wed Oct 27 14:37:26 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 27 Oct 2010 11:37:26 -0700
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated Transfer
	Policy - revised
In-Reply-To: <C8EDE21C.14F0D%marty@akamai.com>
References: <C8EDE21C.14F0D%marty@akamai.com>
Message-ID: <56669D1F-0C18-45BB-8FE1-F9073DD3D09D@delong.com>


On Oct 27, 2010, at 11:05 AM, Hannigan, Martin wrote:

> 
> 
> 
> On 10/27/10 1:12 PM, "Owen DeLong" <owen at delong.com> wrote:
> 
>> With the changes to language in this version, I can now support this
>> proposal once we enact appropriate language in ARIN policy
>> covering what is or is not an acceptable set of transfer conditions.
>> 
> 
> 
> English?
> 
> 
That was English.

I think that ARIN needs policy or at least an understanding in a procedural
document of what transfers would or would not be agreeable to ARIN under
this transfer regime. The policy leaves a lot left to the imagination, as it should
on the global level, but, before enacting it globally, I'd want to have some
documented idea of the in-region ramifications.

Owen



From BillD at cait.wustl.edu  Wed Oct 27 14:54:12 2010
From: BillD at cait.wustl.edu (Bill Darte)
Date: Wed, 27 Oct 2010 13:54:12 -0500
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated
	TransferPolicy - revised
In-Reply-To: <56669D1F-0C18-45BB-8FE1-F9073DD3D09D@delong.com>
References: <C8EDE21C.14F0D%marty@akamai.com>
	<56669D1F-0C18-45BB-8FE1-F9073DD3D09D@delong.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087B5DA9E@ex1.cait.wustl.edu>

Seems to me, that if addresses are unavailable with a region....that the
requestor is a legitimate member of (there's my problem with
definition), then they can make a request or another region....but that
their request would have to conform to the policies of both RIRs.

Doesn't make sense to allow a transfer from out of region if there are
addresses available locally.
Doesn't make sense to allow someone to shop around for a more favorable
policy than their own region.
Doesn't make sense to allow someone to only have to conform to the
'local' policy if it is less stringent than the policy of the RIR it's
requesting transfer from....the RIR with available addresses would then
be placing their own constituents at a disadvantage.

If a multinational org with offices in all 5 regions needs
addresses...which are now only available in 1 region, they would have to
conform to that regions policy.  No different that requesting those
resources today.

bd 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
> Sent: Wednesday, October 27, 2010 1:37 PM
> To: Hannigan, Martin
> Cc: arin-ppml at arin.net List
> Subject: Re: [arin-ppml] Policy Proposal 119: Globally 
> Coordinated TransferPolicy - revised
> 
> 
> On Oct 27, 2010, at 11:05 AM, Hannigan, Martin wrote:
> 
> > 
> > 
> > 
> > On 10/27/10 1:12 PM, "Owen DeLong" <owen at delong.com> wrote:
> > 
> >> With the changes to language in this version, I can now 
> support this 
> >> proposal once we enact appropriate language in ARIN policy 
> covering 
> >> what is or is not an acceptable set of transfer conditions.
> >> 
> > 
> > 
> > English?
> > 
> > 
> That was English.
> 
> I think that ARIN needs policy or at least an understanding 
> in a procedural document of what transfers would or would not 
> be agreeable to ARIN under this transfer regime. The policy 
> leaves a lot left to the imagination, as it should on the 
> global level, but, before enacting it globally, I'd want to 
> have some documented idea of the in-region ramifications.
> 
> 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 dogwallah at gmail.com  Thu Oct 28 11:53:26 2010
From: dogwallah at gmail.com (McTim)
Date: Thu, 28 Oct 2010 18:53:26 +0300
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated
 TransferPolicy - revised
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087B5DA9E@ex1.cait.wustl.edu>
References: <C8EDE21C.14F0D%marty@akamai.com>
	<56669D1F-0C18-45BB-8FE1-F9073DD3D09D@delong.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087B5DA9E@ex1.cait.wustl.edu>
Message-ID: <AANLkTi=o_1_jeS1DwQy0jfqDcSctAuYmb5F0779AbyvK@mail.gmail.com>

All,

FYI a proposed policy in the AfriNIC region has the following clause:

"7.4) AfriNIC resources are for the AfriNIC geographical region. For
each allocation or assignment made during the Exhaustion Phase, no
more than 10% of these resources may be used outside of the AfriNIC
region, and any use outside the AfriNIC region shall be solely in
support of connectivity back to the AfriNIC region."

If this reaches consensus, it would probably mean that this global
policy (Policy Proposal 119: Globally Coordinated Transfer Policy)
wouldn't fly in the AfriNIC region.


-- 
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A
route indicates how we get there."  Jon Postel

On Wed, Oct 27, 2010 at 9:54 PM, Bill Darte <BillD at cait.wustl.edu> wrote:
> Seems to me, that if addresses are unavailable with a region....that the
> requestor is a legitimate member of (there's my problem with
> definition), then they can make a request or another region....but that
> their request would have to conform to the policies of both RIRs.
>
> Doesn't make sense to allow a transfer from out of region if there are
> addresses available locally.
> Doesn't make sense to allow someone to shop around for a more favorable
> policy than their own region.
> Doesn't make sense to allow someone to only have to conform to the
> 'local' policy if it is less stringent than the policy of the RIR it's
> requesting transfer from....the RIR with available addresses would then
> be placing their own constituents at a disadvantage.
>
> If a multinational org with offices in all 5 regions needs
> addresses...which are now only available in 1 region, they would have to
> conform to that regions policy. ?No different that requesting those
> resources today.
>
> bd
>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net
>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
>> Sent: Wednesday, October 27, 2010 1:37 PM
>> To: Hannigan, Martin
>> Cc: arin-ppml at arin.net List
>> Subject: Re: [arin-ppml] Policy Proposal 119: Globally
>> Coordinated TransferPolicy - revised
>>
>>
>> On Oct 27, 2010, at 11:05 AM, Hannigan, Martin wrote:
>>
>> >
>> >
>> >
>> > On 10/27/10 1:12 PM, "Owen DeLong" <owen at delong.com> wrote:
>> >
>> >> With the changes to language in this version, I can now
>> support this
>> >> proposal once we enact appropriate language in ARIN policy
>> covering
>> >> what is or is not an acceptable set of transfer conditions.
>> >>
>> >
>> >
>> > English?
>> >
>> >
>> That was English.
>>
>> I think that ARIN needs policy or at least an understanding
>> in a procedural document of what transfers would or would not
>> be agreeable to ARIN under this transfer regime. The policy
>> leaves a lot left to the imagination, as it should on the
>> global level, but, before enacting it globally, I'd want to
>> have some documented idea of the in-region ramifications.
>>
>> 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.
>


From scottleibrand at gmail.com  Thu Oct 28 12:05:08 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 28 Oct 2010 09:05:08 -0700
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated
	TransferPolicy - revised
In-Reply-To: <AANLkTi=o_1_jeS1DwQy0jfqDcSctAuYmb5F0779AbyvK@mail.gmail.com>
References: <C8EDE21C.14F0D%marty@akamai.com>
	<56669D1F-0C18-45BB-8FE1-F9073DD3D09D@delong.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087B5DA9E@ex1.cait.wustl.edu>
	<AANLkTi=o_1_jeS1DwQy0jfqDcSctAuYmb5F0779AbyvK@mail.gmail.com>
Message-ID: <7176F823-CD0A-428C-A319-09319F2E0C96@gmail.com>

McTim,

I don't think it should be necessary to allow addresses to leave the AfriNIC region in order to pass this globally coordinated transfer policy. As I read it, passing both, in the absence of any local transfer policy in the AfriNIC region, would simply mean that AfriNIC does not object to other regions engaging in inter-RIR transfers, and would open up the possibility of AfriNIC participating at a later date if the community so chooses, perhaps upon exhaustion of the AfriNIC free pool. 

Do you still see a conflict? If so, can you explain further?

Thanks,
Scott

On Oct 28, 2010, at 8:53 AM, McTim <dogwallah at gmail.com> wrote:

> All,
> 
> FYI a proposed policy in the AfriNIC region has the following clause:
> 
> "7.4) AfriNIC resources are for the AfriNIC geographical region. For
> each allocation or assignment made during the Exhaustion Phase, no
> more than 10% of these resources may be used outside of the AfriNIC
> region, and any use outside the AfriNIC region shall be solely in
> support of connectivity back to the AfriNIC region."
> 
> If this reaches consensus, it would probably mean that this global
> policy (Policy Proposal 119: Globally Coordinated Transfer Policy)
> wouldn't fly in the AfriNIC region.
> 
> 
> -- 
> Cheers,
> 
> McTim
> "A name indicates what we seek. An address indicates where it is. A
> route indicates how we get there."  Jon Postel
> 
> On Wed, Oct 27, 2010 at 9:54 PM, Bill Darte <BillD at cait.wustl.edu> wrote:
>> Seems to me, that if addresses are unavailable with a region....that the
>> requestor is a legitimate member of (there's my problem with
>> definition), then they can make a request or another region....but that
>> their request would have to conform to the policies of both RIRs.
>> 
>> Doesn't make sense to allow a transfer from out of region if there are
>> addresses available locally.
>> Doesn't make sense to allow someone to shop around for a more favorable
>> policy than their own region.
>> Doesn't make sense to allow someone to only have to conform to the
>> 'local' policy if it is less stringent than the policy of the RIR it's
>> requesting transfer from....the RIR with available addresses would then
>> be placing their own constituents at a disadvantage.
>> 
>> If a multinational org with offices in all 5 regions needs
>> addresses...which are now only available in 1 region, they would have to
>> conform to that regions policy.  No different that requesting those
>> resources today.
>> 
>> bd
>> 
>>> -----Original Message-----
>>> From: arin-ppml-bounces at arin.net
>>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
>>> Sent: Wednesday, October 27, 2010 1:37 PM
>>> To: Hannigan, Martin
>>> Cc: arin-ppml at arin.net List
>>> Subject: Re: [arin-ppml] Policy Proposal 119: Globally
>>> Coordinated TransferPolicy - revised
>>> 
>>> 
>>> On Oct 27, 2010, at 11:05 AM, Hannigan, Martin wrote:
>>> 
>>>> 
>>>> 
>>>> 
>>>> On 10/27/10 1:12 PM, "Owen DeLong" <owen at delong.com> wrote:
>>>> 
>>>>> With the changes to language in this version, I can now
>>> support this
>>>>> proposal once we enact appropriate language in ARIN policy
>>> covering
>>>>> what is or is not an acceptable set of transfer conditions.
>>>>> 
>>>> 
>>>> 
>>>> English?
>>>> 
>>>> 
>>> That was English.
>>> 
>>> I think that ARIN needs policy or at least an understanding
>>> in a procedural document of what transfers would or would not
>>> be agreeable to ARIN under this transfer regime. The policy
>>> leaves a lot left to the imagination, as it should on the
>>> global level, but, before enacting it globally, I'd want to
>>> have some documented idea of the in-region ramifications.
>>> 
>>> 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.
>> 
> _______________________________________________
> 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 john.sweeting at twcable.com  Thu Oct 28 12:19:40 2010
From: john.sweeting at twcable.com (Sweeting, John)
Date: Thu, 28 Oct 2010 12:19:40 -0400
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated
 TransferPolicy - revised
In-Reply-To: <7176F823-CD0A-428C-A319-09319F2E0C96@gmail.com>
Message-ID: <C8EF1ADC.179FD%john.sweeting@twcable.com>

As I read the AFRINIC proposal it is to keep Global Companies that have global networks and are eligible to get address space from AFRINIC can do so but only for the portion of their networks that is located in the AFRINIC region and for connectivity directly into the AFRINIC region.


On 10/28/10 12:05 PM, "Scott Leibrand" <scottleibrand at gmail.com> wrote:

McTim,

I don't think it should be necessary to allow addresses to leave the AfriNIC region in order to pass this globally coordinated transfer policy. As I read it, passing both, in the absence of any local transfer policy in the AfriNIC region, would simply mean that AfriNIC does not object to other regions engaging in inter-RIR transfers, and would open up the possibility of AfriNIC participating at a later date if the community so chooses, perhaps upon exhaustion of the AfriNIC free pool.

Do you still see a conflict? If so, can you explain further?

Thanks,
Scott

On Oct 28, 2010, at 8:53 AM, McTim <dogwallah at gmail.com> wrote:

> All,
>
> FYI a proposed policy in the AfriNIC region has the following clause:
>
> "7.4) AfriNIC resources are for the AfriNIC geographical region. For
> each allocation or assignment made during the Exhaustion Phase, no
> more than 10% of these resources may be used outside of the AfriNIC
> region, and any use outside the AfriNIC region shall be solely in
> support of connectivity back to the AfriNIC region."
>
> If this reaches consensus, it would probably mean that this global
> policy (Policy Proposal 119: Globally Coordinated Transfer Policy)
> wouldn't fly in the AfriNIC region.
>
>
> --
> Cheers,
>
> McTim
> "A name indicates what we seek. An address indicates where it is. A
> route indicates how we get there."  Jon Postel
>
> On Wed, Oct 27, 2010 at 9:54 PM, Bill Darte <BillD at cait.wustl.edu> wrote:
>> Seems to me, that if addresses are unavailable with a region....that the
>> requestor is a legitimate member of (there's my problem with
>> definition), then they can make a request or another region....but that
>> their request would have to conform to the policies of both RIRs.
>>
>> Doesn't make sense to allow a transfer from out of region if there are
>> addresses available locally.
>> Doesn't make sense to allow someone to shop around for a more favorable
>> policy than their own region.
>> Doesn't make sense to allow someone to only have to conform to the
>> 'local' policy if it is less stringent than the policy of the RIR it's
>> requesting transfer from....the RIR with available addresses would then
>> be placing their own constituents at a disadvantage.
>>
>> If a multinational org with offices in all 5 regions needs
>> addresses...which are now only available in 1 region, they would have to
>> conform to that regions policy.  No different that requesting those
>> resources today.
>>
>> bd
>>
>>> -----Original Message-----
>>> From: arin-ppml-bounces at arin.net
>>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
>>> Sent: Wednesday, October 27, 2010 1:37 PM
>>> To: Hannigan, Martin
>>> Cc: arin-ppml at arin.net List
>>> Subject: Re: [arin-ppml] Policy Proposal 119: Globally
>>> Coordinated TransferPolicy - revised
>>>
>>>
>>> On Oct 27, 2010, at 11:05 AM, Hannigan, Martin wrote:
>>>
>>>>
>>>>
>>>>
>>>> On 10/27/10 1:12 PM, "Owen DeLong" <owen at delong.com> wrote:
>>>>
>>>>> With the changes to language in this version, I can now
>>> support this
>>>>> proposal once we enact appropriate language in ARIN policy
>>> covering
>>>>> what is or is not an acceptable set of transfer conditions.
>>>>>
>>>>
>>>>
>>>> English?
>>>>
>>>>
>>> That was English.
>>>
>>> I think that ARIN needs policy or at least an understanding
>>> in a procedural document of what transfers would or would not
>>> be agreeable to ARIN under this transfer regime. The policy
>>> leaves a lot left to the imagination, as it should on the
>>> global level, but, before enacting it globally, I'd want to
>>> have some documented idea of the in-region ramifications.
>>>
>>> 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.
>>
> _______________________________________________
> 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 E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.


From dogwallah at gmail.com  Thu Oct 28 14:25:12 2010
From: dogwallah at gmail.com (McTim)
Date: Thu, 28 Oct 2010 21:25:12 +0300
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated
 TransferPolicy - revised
In-Reply-To: <7176F823-CD0A-428C-A319-09319F2E0C96@gmail.com>
References: <C8EDE21C.14F0D%marty@akamai.com>
	<56669D1F-0C18-45BB-8FE1-F9073DD3D09D@delong.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087B5DA9E@ex1.cait.wustl.edu>
	<AANLkTi=o_1_jeS1DwQy0jfqDcSctAuYmb5F0779AbyvK@mail.gmail.com>
	<7176F823-CD0A-428C-A319-09319F2E0C96@gmail.com>
Message-ID: <AANLkTinZxPYZmKpCd6hfwjvPDx9HZ4ajbOwxFAJY0goR@mail.gmail.com>

On Thu, Oct 28, 2010 at 7:05 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
> McTim,
>
> I don't think it should be necessary to allow addresses to leave the AfriNIC region in order to pass this globally coordinated transfer policy. As I read it, passing both, in the absence of any local transfer policy in the AfriNIC region, would simply mean that AfriNIC does not object to other regions engaging in inter-RIR transfers, and would open up the possibility of AfriNIC participating at a later date if the community so chooses, perhaps upon exhaustion of the AfriNIC free pool.

If we pass it in the AfriNIC region, then we in the AfriNIC region
could only participate in inter Regional transfers until the
Exhaustion Phase as per the proposed Soft-Landing Policy.

>
> Do you still see a conflict? If so, can you explain further?
>

I understand your POV, however it just seems that the Global Transfer
Policy would be a hard sell in the AfriNIC region if the Soft Landing
reaches consensus.  AFAIK, the Global Transfer Policy hasn't been
introduced yet in the AfriNIC region.  If it is AND if the Soft
Landing is enacted, then AfriNIC would be bound by the Soft Landing
Policy NOT to agree to any inter RIR transfer.  That's my reading of
it anyway.

-- 
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A
route indicates how we get there."? Jon Postel


From owen at delong.com  Thu Oct 28 15:28:47 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 28 Oct 2010 12:28:47 -0700
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated
	TransferPolicy - revised
In-Reply-To: <C8EF1ADC.179FD%john.sweeting@twcable.com>
References: <C8EF1ADC.179FD%john.sweeting@twcable.com>
Message-ID: <5F76FD80-861A-4C0D-AE35-425E3A4C04E4@delong.com>

Right, but, in that same Vein, AfriNIC isn't going to want to create a situation
where their member organizations can start using "address flipping" to
Europe/Asia as a revenue stream.

Owen

On Oct 28, 2010, at 9:19 AM, Sweeting, John wrote:

> As I read the AFRINIC proposal it is to keep Global Companies that have global networks and are eligible to get address space from AFRINIC can do so but only for the portion of their networks that is located in the AFRINIC region and for connectivity directly into the AFRINIC region.
> 
> 
> On 10/28/10 12:05 PM, "Scott Leibrand" <scottleibrand at gmail.com> wrote:
> 
> McTim,
> 
> I don't think it should be necessary to allow addresses to leave the AfriNIC region in order to pass this globally coordinated transfer policy. As I read it, passing both, in the absence of any local transfer policy in the AfriNIC region, would simply mean that AfriNIC does not object to other regions engaging in inter-RIR transfers, and would open up the possibility of AfriNIC participating at a later date if the community so chooses, perhaps upon exhaustion of the AfriNIC free pool.
> 
> Do you still see a conflict? If so, can you explain further?
> 
> Thanks,
> Scott
> 
> On Oct 28, 2010, at 8:53 AM, McTim <dogwallah at gmail.com> wrote:
> 
>> All,
>> 
>> FYI a proposed policy in the AfriNIC region has the following clause:
>> 
>> "7.4) AfriNIC resources are for the AfriNIC geographical region. For
>> each allocation or assignment made during the Exhaustion Phase, no
>> more than 10% of these resources may be used outside of the AfriNIC
>> region, and any use outside the AfriNIC region shall be solely in
>> support of connectivity back to the AfriNIC region."
>> 
>> If this reaches consensus, it would probably mean that this global
>> policy (Policy Proposal 119: Globally Coordinated Transfer Policy)
>> wouldn't fly in the AfriNIC region.
>> 
>> 
>> --
>> Cheers,
>> 
>> McTim
>> "A name indicates what we seek. An address indicates where it is. A
>> route indicates how we get there."  Jon Postel
>> 
>> On Wed, Oct 27, 2010 at 9:54 PM, Bill Darte <BillD at cait.wustl.edu> wrote:
>>> Seems to me, that if addresses are unavailable with a region....that the
>>> requestor is a legitimate member of (there's my problem with
>>> definition), then they can make a request or another region....but that
>>> their request would have to conform to the policies of both RIRs.
>>> 
>>> Doesn't make sense to allow a transfer from out of region if there are
>>> addresses available locally.
>>> Doesn't make sense to allow someone to shop around for a more favorable
>>> policy than their own region.
>>> Doesn't make sense to allow someone to only have to conform to the
>>> 'local' policy if it is less stringent than the policy of the RIR it's
>>> requesting transfer from....the RIR with available addresses would then
>>> be placing their own constituents at a disadvantage.
>>> 
>>> If a multinational org with offices in all 5 regions needs
>>> addresses...which are now only available in 1 region, they would have to
>>> conform to that regions policy.  No different that requesting those
>>> resources today.
>>> 
>>> bd
>>> 
>>>> -----Original Message-----
>>>> From: arin-ppml-bounces at arin.net
>>>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
>>>> Sent: Wednesday, October 27, 2010 1:37 PM
>>>> To: Hannigan, Martin
>>>> Cc: arin-ppml at arin.net List
>>>> Subject: Re: [arin-ppml] Policy Proposal 119: Globally
>>>> Coordinated TransferPolicy - revised
>>>> 
>>>> 
>>>> On Oct 27, 2010, at 11:05 AM, Hannigan, Martin wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 10/27/10 1:12 PM, "Owen DeLong" <owen at delong.com> wrote:
>>>>> 
>>>>>> With the changes to language in this version, I can now
>>>> support this
>>>>>> proposal once we enact appropriate language in ARIN policy
>>>> covering
>>>>>> what is or is not an acceptable set of transfer conditions.
>>>>>> 
>>>>> 
>>>>> 
>>>>> English?
>>>>> 
>>>>> 
>>>> That was English.
>>>> 
>>>> I think that ARIN needs policy or at least an understanding
>>>> in a procedural document of what transfers would or would not
>>>> be agreeable to ARIN under this transfer regime. The policy
>>>> leaves a lot left to the imagination, as it should on the
>>>> global level, but, before enacting it globally, I'd want to
>>>> have some documented idea of the in-region ramifications.
>>>> 
>>>> 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.
>>> 
>> _______________________________________________
>> 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 E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
> _______________________________________________
> 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 Oct 28 15:36:50 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 28 Oct 2010 12:36:50 -0700
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated
	TransferPolicy - revised
In-Reply-To: <AANLkTinZxPYZmKpCd6hfwjvPDx9HZ4ajbOwxFAJY0goR@mail.gmail.com>
References: <C8EDE21C.14F0D%marty@akamai.com>
	<56669D1F-0C18-45BB-8FE1-F9073DD3D09D@delong.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087B5DA9E@ex1.cait.wustl.edu>
	<AANLkTi=o_1_jeS1DwQy0jfqDcSctAuYmb5F0779AbyvK@mail.gmail.com>
	<7176F823-CD0A-428C-A319-09319F2E0C96@gmail.com>
	<AANLkTinZxPYZmKpCd6hfwjvPDx9HZ4ajbOwxFAJY0goR@mail.gmail.com>
Message-ID: <1F4F56F4-3A6D-4A26-89CD-4E204AAF094F@delong.com>


On Oct 28, 2010, at 11:25 AM, McTim wrote:

> On Thu, Oct 28, 2010 at 7:05 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
>> McTim,
>> 
>> I don't think it should be necessary to allow addresses to leave the AfriNIC region in order to pass this globally coordinated transfer policy. As I read it, passing both, in the absence of any local transfer policy in the AfriNIC region, would simply mean that AfriNIC does not object to other regions engaging in inter-RIR transfers, and would open up the possibility of AfriNIC participating at a later date if the community so chooses, perhaps upon exhaustion of the AfriNIC free pool.
> 
> If we pass it in the AfriNIC region, then we in the AfriNIC region
> could only participate in inter Regional transfers until the
> Exhaustion Phase as per the proposed Soft-Landing Policy.
> 
>> 
>> Do you still see a conflict? If so, can you explain further?
>> 
> 
> I understand your POV, however it just seems that the Global Transfer
> Policy would be a hard sell in the AfriNIC region if the Soft Landing
> reaches consensus.  AFAIK, the Global Transfer Policy hasn't been
> introduced yet in the AfriNIC region.  If it is AND if the Soft
> Landing is enacted, then AfriNIC would be bound by the Soft Landing
> Policy NOT to agree to any inter RIR transfer.  That's my reading of
> it anyway.
> 
Well, at least they would be unable to participate or agree to an outbound
transfer. I don't see that as a problem... Do you?

Owen



From farmer at umn.edu  Thu Oct 28 17:18:49 2010
From: farmer at umn.edu (David Farmer)
Date: Thu, 28 Oct 2010 16:18:49 -0500
Subject: [arin-ppml] Updated text for Draft Policy 2010-8
Message-ID: <4CC9E8B9.4080005@umn.edu>

The following text includes changes discussed at the ARIN XXVI Public 
Policy Meeting three weeks ago in Atlanta and several changes to address 
Staff Comments regarding confusing language in several sections.

Specifically;

Clause c of 6.5.8.1 was changed from "a network consisting of a total of 
1000 or more hosts" to "a network that makes active use of a minimum of 
2000 IPv6 addresses within 12 months."

Clause d of 6.5.8.1 was added.

Section 6.5.8.2 Initial assignment size and its subsections were 
rewritten for clarity to address staff concerns, but there should be no 
change in the intent of the policy.

Section 6.5.8.3 Subsequent assignments was rewritten for clarity to 
address staff concerns, but there should be no change in the intent of 
the policy.

Finally there were a number of related updates to the rationale.

----------------

Policy statement: Replace section 6.5.8 as follows;

6.5.8. Direct assignments from ARIN to end-user organizations

6.5.8.1 Initial Assignment Criteria

Organizations may justify an initial assignment for addressing devices 
directly attached to their own network infrastructure, with an intent 
for the addresses to begin operational use within 12 months, by meeting 
one of the following 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 having a network that makes active use of a minimum of 2000 IPv6 
addresses within 12 months, or;

d. By having a network that makes active use of a minimum of 200 /64 
subnets within 12 months, or;

e. By providing a reasonable technical justification indicating why IPv6 
addresses from an ISP or other LIR are unsuitable.

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 can justify the need for an assignment 
based on the fact that renumbering would have a broader than expected 
impact than simply the number of hosts directly 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 directly involved, an organization 
can justify the need for an assignment if renumbering would affect 2000 
or more individuals either internal or external to the organization.
? An organization with a network not connected to the Internet can 
justify the need for an assignment by documenting a need for guaranteed 
uniqueness, beyond the statistical uniqueness provided by ULA (see RFC 
4193).
? An organization with a network not connected to the Internet, such as 
a VPN overlay network, can justify the need for an assignment if they 
require authoritative delegation of reverse DNS.

6.5.8.2 Initial assignment size

Organizations that meet at least one of the initial assignment criteria 
above are eligible to receive an initial assignment of /48. Requests for 
larger initial assignments, reasonably justified with supporting 
documentation, will be evaluated based on the number of sites in an 
organization?s network and the number of subnets needed to support any 
extra-large sites defined below.

The initial assignment size will be determined by the number of sites 
justified below. An organization qualifies for an assignment on the next 
larger nibble boundary when their sites exceed 75% of the /48s available 
in a prefix. For example:

More than 1 but less than or equal to 12 sites justified, receives a /44 
assignment;
More than 12 but less than or equal to 192 /sites justified, receives a 
/40 assignment;
More than 192 but less than or equal to 3,072 sites justified, receives 
a /36 assignment;
More than 3,072 but less than or equal to 49,152 sites justified, 
receives a /32 assignment;
etc...

6.5.8.2.1 Standard sites

A site is a discrete location that is part of an organization?s network. 
A campus with multiple buildings may be considered as one or multiple 
sites, based on the implementation of its network infrastructure. For a 
campus to be considered as multiple sites, reasonable technical 
documentation must be submitted describing how the network 
infrastructure is implemented in a manner equivalent to multiple sites.

An organization may request up to a /48 for each site in its network, 
and any sites that will be operational within 12 months.

6.5.8.2.2 Extra-large sites

In rare cases, an organization may request more than a /48 for an 
extra-large site which requires more than 16,384 /64 subnets. In such a 
case, a detailed subnet plan must be submitted for each extra-large site 
in an organization?s network. An extra-large site qualifies for the next 
larger prefix when the total subnet utilization exceeds 25%. Each 
extra-large site will be counted as an equivalent number of /48 standard 
sites.

6.5.8.3 Subsequent assignments

Requests for subsequent assignments with supporting documentation will 
be evaluated based on the same criteria as an initial assignment under 
6.5.8.2 with the following modifications:

a. A subsequent assignment is justified when the total utilization based 
on the number of sites justified exceeds 75% across all of an 
organization?s assignments. If the organization received an assignment 
per section 6.11 IPv6 Multiple Discrete Networks, such assignments will 
be evaluated as if they were to a separate organization.

b. When possible subsequent assignments will result it the expansion of 
an existing assignment by one or more nibble boundaries as justified.

c. If it is not possible to expand an existing assignment, or to expand 
it adequately to meet the justified need, then a separate new assignment 
will be made of the size justified.

6.5.8.4 Consolidation and return of separate assignments

Organizations with multiple separate assignments should consolidate into 
a single aggregate, if feasible. If an organization stops using one or 
more of its separate assignments, any unused assignments must be 
returned to ARIN.

Rationale:

This proposal provides a complete rework of the IPv6 end-user assignment 
criteria, removing the dependency on IPv4 policy, providing clear 
guidance in requesting larger initial assignments, and eliminating 
HD-Ratio as criteria for evaluating end-user assignments.

The HD-Ratio is replaced with a simplified 75% utilization threshold 
based on nibble boundaries for end-user assignments. This threshold is 
somewhat more restrictive for larger assignments, while slightly less 
restrictive for the smaller /44 assignments, than the HD-Ratio. However, 
in both cases it is much easier for an end-user to understand the policy 
criteria that applies to them.

The following general concepts are included:

? Previously justified IPv4 resources may be used to justify the need 
for IPv6 resources
? Internet multihoming is sufficient justification for an IPv6 end-user 
assignment in and of itself
? Networks with more than 2000 hosts have a justified need for IPv6 
resources; as is the case in current policy, it is just more clearly 
stated without relying on a reference to, and the consequences of, IPv4 
policy
? Networks with more than 200 subnets have a justified need for IPv6 
resources, independent of the number of hosts they have
? Other end-users, not meeting one of the previous criteria, must 
justify why an ISP or LIR assignment is not sufficient for their needs
? Reservations are no longer necessary as ARIN has committed to sparse 
assignment for IPv6
? Providing sufficiently large initial assignments based on nibble 
boundaries along with sparse assignments will reduce route table growth 
caused solely by subsequent assignments

Organizations with multiple sites may receive a /48 for each site in 
their network.  A campus with multiple buildings may be considered as 
one or multiple sites, based on the implementation of its network 
infrastructure.  When multiple separate organizations have networks in 
the same building, such as in the case of a multi-tenant building, each 
organization justifies a separate /48 for its network at the site.

The 25% subnet utilization for an extra-large site is proposed as the 
threshold for a larger prefix in order to allow an extra-large site 
enough room to create an organized subnet plan. Requiring denser usage 
would make it almost impossible for an extra-large site to maintain any 
kind of organized subnet plan. Furthermore, even at 25% utilization, 
more than 16,384 subnets are required to justify more than a /48 for a 
site. Few, if any, sites can actually meet or exceed this threshold.

Organizations may have multiple separate assignments due to previous 
subsequent assignments made per clause 6.5.8.3.c or through Mergers and 
Acquisitions in section 8.2.  These multiple separate assignments must 
be considered in total when making subsequent assignments, unless they 
are part multiple discrete networks, per section 6.11.

The ARIN Board of Trusties should consider incentives that provide 
additional motivation for end-users to consolidate into a single 
aggregate per section 6.5.8.4 of this policy.

Timetable for implementation: Immediate



-- 
===============================================
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 scottleibrand at gmail.com  Fri Oct 29 01:13:43 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 28 Oct 2010 22:13:43 -0700
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated
 TransferPolicy - revised
In-Reply-To: <AANLkTinZxPYZmKpCd6hfwjvPDx9HZ4ajbOwxFAJY0goR@mail.gmail.com>
References: <C8EDE21C.14F0D%marty@akamai.com>
	<56669D1F-0C18-45BB-8FE1-F9073DD3D09D@delong.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087B5DA9E@ex1.cait.wustl.edu>
	<AANLkTi=o_1_jeS1DwQy0jfqDcSctAuYmb5F0779AbyvK@mail.gmail.com>
	<7176F823-CD0A-428C-A319-09319F2E0C96@gmail.com>
	<AANLkTinZxPYZmKpCd6hfwjvPDx9HZ4ajbOwxFAJY0goR@mail.gmail.com>
Message-ID: <AANLkTin0E4ST1FkCga3H90ueaZJTTof6g_9MQ2wEa0yU@mail.gmail.com>

On Thu, Oct 28, 2010 at 11:25 AM, McTim <dogwallah at gmail.com> wrote:
> On Thu, Oct 28, 2010 at 7:05 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
>> McTim,
>>
>> I don't think it should be necessary to allow addresses to leave the AfriNIC region in order to pass this globally coordinated transfer policy. As I read it, passing both, in the absence of any local transfer policy in the AfriNIC region, would simply mean that AfriNIC does not object to other regions engaging in inter-RIR transfers, and would open up the possibility of AfriNIC participating at a later date if the community so chooses, perhaps upon exhaustion of the AfriNIC free pool.
>
> If we pass it in the AfriNIC region, then we in the AfriNIC region
> could only participate in inter Regional transfers until the
> Exhaustion Phase as per the proposed Soft-Landing Policy.

As I understand it, if you pass this globally coordinated policy, the
AfriNIC region would not participate at all unless AfriNIC passed
local policy to allow transfers.


>> Do you still see a conflict? If so, can you explain further?
>>
>
> I understand your POV, however it just seems that the Global Transfer
> Policy would be a hard sell in the AfriNIC region if the Soft Landing
> reaches consensus. ?AFAIK, the Global Transfer Policy hasn't been
> introduced yet in the AfriNIC region. ?If it is AND if the Soft
> Landing is enacted, then AfriNIC would be bound by the Soft Landing
> Policy NOT to agree to any inter RIR transfer. ?That's my reading of
> it anyway.

I agree, but AFAICT AfriNIC would also be bound by its lack of a local
transfer policy to not allow any inter-RIR transfers, regardless of
whether Soft Landing reaches consensus.  IMO that's a feature, not a
bug: we don't want to force an RIR into allowing inter-RIR transfers
unless they decided to, via their local PDP.  On the other hand, we
don't want to prevent two RIRs from allowing transfers between their
members if they so choose...

-Scott


From info at arin.net  Fri Oct 29 12:32:44 2010
From: info at arin.net (ARIN)
Date: Fri, 29 Oct 2010 12:32:44 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - October 2010
Message-ID: <4CCAF72C.4090304@arin.net>

In accordance with the ARIN Policy Development Process the ARIN Advisory
Council (AC) held a meeting on 27 October 2010 and made decisions about
a draft policy and a policy proposal.

The AC moved the following draft policy to last call (it will be posted
separately to last call):

   2010-10 (Global Proposal): Global Policy for IPv4 Allocations by the
IANA Post Exhaustion

The AC accepted the following proposal on to the AC's docket for
development and evaluation:

   119. Globally Coordinated Transfer Policy

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,

Communications and Member Services
American Registry for Internet Numbers (ARIN)























From info at arin.net  Fri Oct 29 12:40:10 2010
From: info at arin.net (ARIN)
Date: Fri, 29 Oct 2010 12:40:10 -0400
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global Policy
 for IPv4 Allocations by the IANA Post Exhaustion - Last Call (text revised)
Message-ID: <4CCAF8EA.7080109@arin.net>

The ARIN Advisory Council (AC) met on 27 October 2010 and decided to
send the following draft policy to last call:

    Draft Policy 2010-10 (Global Proposal): Global Policy for IPv4
Allocations by the IANA Post Exhaustion

The AC made the following revisions to the text:
   - The second sentence in section 2 was changed into two sentences.
"Eligible address space includes addresses that are not designated as
"special use" by an IETF RFC. Address space may only be returned by the
issuing RIR."
   - In section 4, the sentence beginning "Exhaustion is defined as..."
was changed to: "An RIR is considered at exhaustion when the inventory
is less than the equivalent of a single /8 and is unable to further
assign address space to its customers in units equal to or shorter than
the longest of that RIR's policy defined minimum allocation unit."

Feedback is encouraged during the last call period. All comments should
be provided to the Public Policy Mailing List. Last call for 2010-10
will expire on 12 November 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,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2010-10 (Global Proposal)

Global Policy for IPv4 Allocations by the IANA Post Exhaustion

Version/Date: 29 October 2010

Policy statement:

1. Reclamation Pool
Upon adoption of this IPv4 address policy by the ICANN Board of
Directors, the IANA shall establish a Reclamation Pool to be utilized
post RIR IPv4 exhaustion as defined in Section 4. The reclamation pool
will initially contain any fragments that may be left over in IANA
inventory. As soon as the first RIR exhausts its inventory of IP address
space, this Reclamation Pool will be declared active. When the
Reclamation Pool is declared active, the Global Policy for the
Allocation of the Remaining IPv4 Address Space[3] and Policy for
Allocation of IPv4 Blocks to Regional Internet Registries[4] will be
formally deprecated.

2. Returning Address Space to the IANA
The IANA will accept into the Reclamation Pool all eligible IPv4 address
space that are offered for return. Eligible address space includes
addresses that are not designated as "special use" by an IETF RFC.
Address space may only be returned by the issuing RIR. Legacy address
holders may return address space directly to the IANA if they so choose.

3. Address Allocations from the Reclamation Pool by the IANA
Allocations from the Reclamation Pool may begin once the pool is
declared active. Addresses in the Reclamation Pool must be allocated on
a CIDR boundary. Allocations from the Reclamation Pool are subject to a
minimum allocation unit equal to the minimum allocation unit of all RIRs
and a maximum allocation unit of one /8. The Reclamation Pool will be
divided on CIDR boundaries and distributed evenly to all eligible RIRs
once each quarter. Any remainder not evenly divisible by the number of
eligible RIRs will remain in the Reclamation Pool until such time
sufficient address returns allow another round of allocations.

4. RIR Eligibility for Receiving Allocations from the Reclamation Pool
Upon the exhaustion of an RIR's free space pool and after receiving
their final /8 from the IANA[3], an RIR will become eligible to request
address space from the IANA Reclamation Pool when it publicly announces
via its respective global announcements email list and by posting a
notice on its website that it has exhausted its supply of IPv4 address
space. An RIR is considered at exhaustion when the inventory is less
than the equivalent of a single /8 and is unable to further assign
address space to its customers in units equal to or shorter than the
longest of that RIR's policy defined minimum allocation unit. Up to one
/10 or equivalent of IPv4 address space specifically reserved for any
special purpose by an RIR will not be counted against that RIR when
determining eligibility unless that space was received from the IANA
reclamation pool. Any RIR that is formed after the ICANN Board of
Directors has ratified this policy is not eligible to utilize this
policy to obtain IPv4 address space from the IANA.

5. Reporting Requirements
The IANA shall publish on at least a weekly basis a report that is
publicly available which at a minimum details all address space that has
been received and that has been allocated. The IANA shall publish a
Returned Address Space Report which indicates what resources were
returned, by whom and when. The IANA shall publish an Allocations Report
on at least a weekly basis which at a minimum indicates what IPv4
address space has been allocated, which RIR received the allocation and
when. The IANA shall publish a public notice confirming RIR eligibility
subsequent to Section 4.

6. No Transfer Rights
Address space assigned from the Reclamation Pool may be transferred if
there is either an ICANN Board ratified global policy or globally
coordinated RIR policy specifically written to deal with transfers
whether inter-RIR or from one entity to another. Transfers must meet the
requirements of such a policy. In the absence of such a policy, no
transfers of any kind related to address space allocated or assigned
from the reclamation pool is allowed.

7. Definitions
IANA - Internet Assigned Numbers Authority, or its successor
ICANN - Internet Corporation for Assigned Names and Numbers, or its
successor
RIR - Regional Internet Registry as recognized by ICANN
MOU - Memorandum of Understanding between ICANN and the RIRs
IPv4 - Internet Protocol Version Four(4), the target protocol of this
Global Policy
Free Space Pool - IPv4 Addresses that are in inventory at any RIR,
and/or the IANA

8. Contributors
The following individuals donated their time, resources and effort to
develop this proposal on behalf of the Internet Community:
Steve Bertrand <steve at ipv6canada.com>
Chris Grundemann <cgrundemann at gmail.com>
Martin Hannigan <marty at akamai.com>
Aaron Hughes <ahughes at bind.com>
Louie Lee <louie at equinix.com>
Matt Pounsett <matt at conundrum.com>
Jason Schiller <schiller at uu.net>

9. References

1. http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm
Global Policy for the Allocation of the Remaining IPv4 Address Space,
IANA, Retrieved 27 April 2010
2. http://aso.icann.org/documents/memorandum-of-understanding/index.html
ICANN Address Supporting Organization (ASO) MoU , Retrieved 27 May 2010.
3. http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm
Global Policy for the Allocation of the Remaining IPv4 Address Space
4. http://aso.icann.org/wp-content/uploads/2009/09/aso-001-2.pdf Policy
for Allocation of IPv4 Blocks to Regional Internet Registries








From bicknell at ufp.org  Fri Oct 29 12:47:38 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 29 Oct 2010 09:47:38 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global
	Policy for IPv4 Allocations by the IANA Post Exhaustion -
	Last Call (text revised)
In-Reply-To: <4CCAF8EA.7080109@arin.net>
References: <4CCAF8EA.7080109@arin.net>
Message-ID: <20101029164738.GA49730@ussenterprise.ufp.org>

In a message written on Fri, Oct 29, 2010 at 12:40:10PM -0400, ARIN wrote:
> The AC made the following revisions to the text:
>   - The second sentence in section 2 was changed into two sentences.
> "Eligible address space includes addresses that are not designated as
> "special use" by an IETF RFC. Address space may only be returned by the
> issuing RIR."

I am unsure if I am being pedantic here, or if there is an intent
to exclude legacy space.

Legacy space was not issued by any of the current RIR's.  ARIN may
be able to claim it is the decendant of the issuer (warning, can
of worms), but for instance other RIR's had legacy space transferred
to them years ago.

It is entirely possible to read that sentence as excluding legacy
space as a result, which I hope was not the intention.
s/issuing/responsible/ would clear up any confusion, although I'm
uncleaer why the sentence is needed at all.  Do we really need to
state that IANA shouldn't accept back an APNIC block if RIPE is the
one trying to return it?

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

From cgrundemann at gmail.com  Fri Oct 29 12:49:06 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Fri, 29 Oct 2010 10:49:06 -0600
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated
 TransferPolicy - revised
In-Reply-To: <AANLkTin0E4ST1FkCga3H90ueaZJTTof6g_9MQ2wEa0yU@mail.gmail.com>
References: <C8EDE21C.14F0D%marty@akamai.com>
	<56669D1F-0C18-45BB-8FE1-F9073DD3D09D@delong.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087B5DA9E@ex1.cait.wustl.edu>
	<AANLkTi=o_1_jeS1DwQy0jfqDcSctAuYmb5F0779AbyvK@mail.gmail.com>
	<7176F823-CD0A-428C-A319-09319F2E0C96@gmail.com>
	<AANLkTinZxPYZmKpCd6hfwjvPDx9HZ4ajbOwxFAJY0goR@mail.gmail.com>
	<AANLkTin0E4ST1FkCga3H90ueaZJTTof6g_9MQ2wEa0yU@mail.gmail.com>
Message-ID: <AANLkTim1kbird-Tc3LchTnhc4gTsv6CcksdVnKrKO1W-@mail.gmail.com>

On Thu, Oct 28, 2010 at 23:13, Scott Leibrand <scottleibrand at gmail.com> wrote:
<snip>
> we don't want to force an RIR into allowing inter-RIR transfers
> unless they decided to, via their local PDP. ?On the other hand, we
> don't want to prevent two RIRs from allowing transfers between their
> members if they so choose...

Exactly! Today, there is no option for inter-RIR transfers. This
policy simply creates an option.

Passing it in a region does not mandate that region to perform any
transfers, it only allows them to participate if they so choose.

~Chris

> -Scott
> _______________________________________________
> 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 cgrundemann at gmail.com  Fri Oct 29 13:00:23 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Fri, 29 Oct 2010 11:00:23 -0600
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global
 Policy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (text
 revised)
In-Reply-To: <20101029164738.GA49730@ussenterprise.ufp.org>
References: <4CCAF8EA.7080109@arin.net>
	<20101029164738.GA49730@ussenterprise.ufp.org>
Message-ID: <AANLkTimTgE+7z-FjPXzs4GHXbhMHDzdj=AFGbSjy9dTp@mail.gmail.com>

On Fri, Oct 29, 2010 at 10:47, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Fri, Oct 29, 2010 at 12:40:10PM -0400, ARIN wrote:
>> The AC made the following revisions to the text:
>> ? - The second sentence in section 2 was changed into two sentences.
>> "Eligible address space includes addresses that are not designated as
>> "special use" by an IETF RFC. Address space may only be returned by the
>> issuing RIR."
>
> I am unsure if I am being pedantic here, or if there is an intent
> to exclude legacy space.

That was certainly not the originators intent. Although I agree that
the AC did a less than optimum job of word-smithing; I must admit the
original text was less than perfectly clear as well.

In any case, I think the next sentence saves us from any potential
problem: "Legacy address holders may return address space directly to
the IANA if they so choose."

> Legacy space was not issued by any of the current RIR's. ?ARIN may
> be able to claim it is the decendant of the issuer (warning, can
> of worms), but for instance other RIR's had legacy space transferred
> to them years ago.
>
> It is entirely possible to read that sentence as excluding legacy
> space as a result, which I hope was not the intention.
> s/issuing/responsible/ would clear up any confusion, although I'm
> uncleaer why the sentence is needed at all. ?Do we really need to
> state that IANA shouldn't accept back an APNIC block if RIPE is the
> one trying to return it?

I think it makes sense to cover our bases.

~Chris

>
> --
> ? ? ? Leo Bicknell - bicknell at ufp.org - CCIE 3440
> ? ? ? ?PGP keys at http://www.ufp.org/~bicknell/
>
> _______________________________________________
> 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 BillD at cait.wustl.edu  Fri Oct 29 13:03:49 2010
From: BillD at cait.wustl.edu (Bill Darte)
Date: Fri, 29 Oct 2010 12:03:49 -0500
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):
	GlobalPolicy for IPv4 Allocations by the IANA Post Exhaustion
	-Last Call (text revised)
In-Reply-To: <20101029164738.GA49730@ussenterprise.ufp.org>
References: <4CCAF8EA.7080109@arin.net>
	<20101029164738.GA49730@ussenterprise.ufp.org>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087B5DB72@ex1.cait.wustl.edu>

 
> In a message written on Fri, Oct 29, 2010 at 12:40:10PM 
> -0400, ARIN wrote:
> > The AC made the following revisions to the text:
> >   - The second sentence in section 2 was changed into two sentences.
> > "Eligible address space includes addresses that are not 
> designated as 
> > "special use" by an IETF RFC. Address space may only be returned by 
> > the issuing RIR."
> 
> I am unsure if I am being pedantic here, or if there is an 
> intent to exclude legacy space.
> 
> Legacy space was not issued by any of the current RIR's.  
> ARIN may be able to claim it is the decendant of the issuer 
> (warning, can of worms), but for instance other RIR's had 
> legacy space transferred to them years ago.
> 
> It is entirely possible to read that sentence as excluding 
> legacy space as a result, which I hope was not the intention.
> s/issuing/responsible/ would clear up any confusion, although 
> I'm uncleaer why the sentence is needed at all.  Do we really 
> need to state that IANA shouldn't accept back an APNIC block 
> if RIPE is the one trying to return it?
> 

I don't believe the focus is legacy space, but rather space allocated
within the region.
Those addresses would have to returned to the RIR rather than directly
to IANA.  At least that is how I now understand its intent.

bd




> -- 
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/
> 


From john.sweeting at twcable.com  Fri Oct 29 13:39:53 2010
From: john.sweeting at twcable.com (Sweeting, John)
Date: Fri, 29 Oct 2010 13:39:53 -0400
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global
 Policy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (text
 revised)
In-Reply-To: <20101029164738.GA49730@ussenterprise.ufp.org>
Message-ID: <C8F07F29.17B14%john.sweeting@twcable.com>

Hi Leo,

If you read the whole paragraph then you will see that legacy space is covered:

Eligible address space includes addresses that are not designated as "special use" by an IETF RFC.
Address space may only be returned by the issuing RIR. Legacy address
holders may return address space directly to the IANA if they so choose.

Interpretation is that this covers all legacy address holders and if any RIR holds legacy space then they are "Legacy address
Holders" and may return the legacy space directly to IANA if they so chose.


On 10/29/10 12:47 PM, "Leo Bicknell" <bicknell at ufp.org> wrote:

In a message written on Fri, Oct 29, 2010 at 12:40:10PM -0400, ARIN wrote:
> The AC made the following revisions to the text:
>   - The second sentence in section 2 was changed into two sentences.
> "Eligible address space includes addresses that are not designated as
> "special use" by an IETF RFC. Address space may only be returned by the
> issuing RIR."

I am unsure if I am being pedantic here, or if there is an intent
to exclude legacy space.

Legacy space was not issued by any of the current RIR's.  ARIN may
be able to claim it is the decendant of the issuer (warning, can
of worms), but for instance other RIR's had legacy space transferred
to them years ago.

It is entirely possible to read that sentence as excluding legacy
space as a result, which I hope was not the intention.
s/issuing/responsible/ would clear up any confusion, although I'm
uncleaer why the sentence is needed at all.  Do we really need to
state that IANA shouldn't accept back an APNIC block if RIPE is the
one trying to return it?

--
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/



From farmer at umn.edu  Fri Oct 29 13:48:41 2010
From: farmer at umn.edu (David Farmer)
Date: Fri, 29 Oct 2010 12:48:41 -0500
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global
 Policy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (text
 revised)
In-Reply-To: <20101029164738.GA49730@ussenterprise.ufp.org>
References: <4CCAF8EA.7080109@arin.net>
	<20101029164738.GA49730@ussenterprise.ufp.org>
Message-ID: <4CCB08F9.1030303@umn.edu>

On 10/29/10 11:47 CDT, Leo Bicknell wrote:
> In a message written on Fri, Oct 29, 2010 at 12:40:10PM -0400, ARIN wrote:
>> The AC made the following revisions to the text:
>>    - The second sentence in section 2 was changed into two sentences.
>> "Eligible address space includes addresses that are not designated as
>> "special use" by an IETF RFC. Address space may only be returned by the
>> issuing RIR."
>
> I am unsure if I am being pedantic here, or if there is an intent
> to exclude legacy space.
>
> Legacy space was not issued by any of the current RIR's.  ARIN may
> be able to claim it is the decendant of the issuer (warning, can
> of worms), but for instance other RIR's had legacy space transferred
> to them years ago.
>
> It is entirely possible to read that sentence as excluding legacy
> space as a result, which I hope was not the intention.
> s/issuing/responsible/ would clear up any confusion, although I'm
> uncleaer why the sentence is needed at all.  Do we really need to
> state that IANA shouldn't accept back an APNIC block if RIPE is the
> one trying to return it?

I believe it would help if you looked at section 2 in its entirety, and 
not just the part that was changed.

----

2. Returning Address Space to the IANA
The IANA will accept into the Reclamation Pool all eligible IPv4 address 
space that are offered for return. Eligible address space includes 
addresses that are not designated as "special use" by an IETF RFC. 
Address space may only be returned by the issuing RIR. Legacy address 
holders may return address space directly to the IANA if they so choose.

----

When you read the section in its entirety, I believe it is clear that 
Legacy address space is included.

Further more, yes it is a can of worms but, I believe it is ARIN's 
position that ARIN is essentially the issuing RIR for Legacy address 
space within the ARIN region, as through contracts it is successor 
registry to the previous registries that made the Legacy allocations. 
Additionally, I it is my understanding that the other RIRs have much 
cleaner contractual relationships with their Legacy holders.

But, the final sentence in the section makes all that a moot point, as 
it explicitly gives Legacy holders of address space the ability to 
return address space to IANA directly, if the choose to.

-- 
===============================================
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 bicknell at ufp.org  Fri Oct 29 14:42:52 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 29 Oct 2010 11:42:52 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global
	Policy for IPv4 Allocations by the IANA Post Exhaustion -
	Last Call (text revised)
In-Reply-To: <C8F07F29.17B14%john.sweeting@twcable.com>
References: <20101029164738.GA49730@ussenterprise.ufp.org>
	<C8F07F29.17B14%john.sweeting@twcable.com>
Message-ID: <20101029184252.GA58774@ussenterprise.ufp.org>

In a message written on Fri, Oct 29, 2010 at 01:39:53PM -0400, Sweeting, John wrote:
> Eligible address space includes addresses that are not designated as "special use" by an IETF RFC.
> Address space may only be returned by the issuing RIR. Legacy address
> holders may return address space directly to the IANA if they so choose.

I don't believe this matches what has happened for the few blocks
that have been returned.  I believe the /8's returned so far went
to ARIN and then to IANA.

Also, I believe this requires IANA to provide a customer service
function they don't provide today.  IANA has "outsourced" all address
space interactions to the RIR's.  For instance it is my understanding
part of the legacy space transfer project of a few years ago was
to get any supporting documentation also transferred.  Thus the
party in a position to verify that the space in question can be
returned by the person returning it is the RIR, who holds the
paperwork.

Long story short, I'm really baffled by legacy needs to be treated
any differently for this policy.  While I am a strong proponent of
legacy space going back into the global free pool it seems to me
it should be returned to the RIR currently managing it, just like
any other returned block.  Said RIR should then return it to the
IANA free pool, just as has happened in the past.

The only way in which Legacy space should be treated differently
in my opinion is that the RIR should be required to return it to
IANA, rather than returning it to its own free pool.

Why are we creating two different processes?

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

From bill at herrin.us  Fri Oct 29 14:50:14 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 29 Oct 2010 14:50:14 -0400
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global
 Policy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (text
 revised)
In-Reply-To: <20101029184252.GA58774@ussenterprise.ufp.org>
References: <20101029164738.GA49730@ussenterprise.ufp.org>
	<C8F07F29.17B14%john.sweeting@twcable.com>
	<20101029184252.GA58774@ussenterprise.ufp.org>
Message-ID: <AANLkTi=UJV5GKAAZzKAC=7KWpvZqkZ4vrvJKyR1Mwrna@mail.gmail.com>

On Fri, Oct 29, 2010 at 2:42 PM, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Fri, Oct 29, 2010 at 01:39:53PM -0400, Sweeting, John wrote:
>> Legacy address
>> holders may return address space directly to the IANA if they so choose.
>
> I don't believe this matches what has happened for the few blocks
> that have been returned.

It doesn't. Is that a problem?

Given the politics in the situation, do we want to insist that legacy
registrants generous enough to return addresses give them first to
ARIN?

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 jcurran at arin.net  Fri Oct 29 15:51:07 2010
From: jcurran at arin.net (John Curran)
Date: Fri, 29 Oct 2010 15:51:07 -0400
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global
 Policy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (text
 revised)
In-Reply-To: <4CCB08F9.1030303@umn.edu>
References: <4CCAF8EA.7080109@arin.net>
	<20101029164738.GA49730@ussenterprise.ufp.org>
	<4CCB08F9.1030303@umn.edu>
Message-ID: <EE964CDF-FBF2-40C1-B666-DB0F2FF2E067@arin.net>

On Oct 29, 2010, at 1:48 PM, David Farmer wrote:

> Further more, yes it is a can of worms but, I believe it is ARIN's position that ARIN is essentially the issuing RIR for Legacy address space within the ARIN region, as through contracts it is successor registry to the previous registries that made the Legacy allocations. Additionally, I it is my understanding that the other RIRs have much cleaner contractual relationships with their Legacy holders.

That is correct: ARIN is the successor registry for legacy address space registrations within this region.  

While other regions had a very modest number of legacy assignments to be brought under clearer contractual relations, the quantity of legacy registrations in the ARIN region make this process much more challenging.  Current statistics on progress in this area may be found here: <https://www.arin.net/knowledge/statistics/legacy.html>

/John

John Curran
President and CEO
ARIN