From bmanning at karoshi.com  Wed Aug  3 13:08:25 2005
From: bmanning at karoshi.com (Bill Manning)
Date: Wed, 3 Aug 2005 10:08:25 -0700
Subject: [ppml] Fwd: potpourri
Message-ID: <7ca072c83403fc8a459a5ce6de198c9f@karoshi.com>

interesting ideas from the IETF IPv6 WG....



Begin forwarded message:

> From: "Bound, Jim" <Jim.Bound at hp.com>
> Date: August 3, 2005 9:37:35 PDT
> To: "Tony Hain" <alh-ietf at tndh.net>, <ipv6 at ietf.org>
> Cc: Subject: RE: potpourri
>
> Tony, you said it all, and I for one have no more to say on this and we
> should take your mail to heart and do exactly what you state.
>
> Regarding making statements about deployment all the IETF can do is 
> make
> a statement of implementation state.  Further on that mission is in
> process in the market and in process that also will do verification and
> one of them is the IPv6 Forum Logo program, for part of what is
> required, and that is going to be expanded.  This will support equally
> both government and industry and world wide.
>
> thanks for your time to type all this in and thoughts,
>
> /jim
>
>> -----Original Message-----
>> From: ipv6-bounces at ietf.org [mailto:ipv6-bounces at ietf.org] On
>> Behalf Of Tony Hain
>> Sent: Wednesday, August 03, 2005 8:29 AM
>> To: ipv6 at ietf.org
>> Subject: potpourri
>>
>> Following up on the meeting session:
>>
>> As the IPv6 working group draws to a close the *only* proper
>> action is to
>> recommend to the IESG that all stable and eligible documents
>> be progressed
>> along the standards track. The IESG will do whatever it would
>> anyway, so it
>> does no good to try to fineness things by endless debates
>> about last minute
>> tweaks and the resulting potential to recycle in place. If
>> there are minor
>> clarifications to make, those should be done as independent
>> documents in the
>> context of addenda to the stable documents. IPv6 as the
>> components which
>> functionally replace RFC 791, 826, etc. is complete. Solving
>> problems that
>> are still unsolved in IPv4 remains as work for continuing or
>> future working
>> groups. That does not diminish the stability of the base
>> documents, so they
>> need to progress now.
>>
>> On the discussion about prefixes, we need to stop revisiting
>> decisions. The
>> IETF does need to make a statement because leaving this to the RIRs is
>> equivalent to leaving the fox in charge of access to the
>> chickens. The point
>> I was trying to make at the mic is that there are vocal
>> participants in the
>> RIR community that are stuck in the conservation mindset and
>> can't seem to
>> do basic math. They will agree with Thomas, Geoff, & Lea's
>> work that without
>> doing anything IPv6 will be sufficient for a number of
>> decades, but they
>> seem to loose context when the simple change of the HD from
>> .8 to .94 buys
>> an order of magnitude which results in IPv6 being sufficient
>> for a number of
>> *centuries*. That timeframe is substantially long enough that
>> it becomes
>> difficult to grasp so without a good grasp of the lifetime their
>> conservation mindset steps in claiming the need to curtail
>> wasted bits at
>> every turn. The whole /56 discussion is looking to take us
>> from centuries to
>> tens (or hundreds if combined with the HD change) of
>> millennia. What they
>> fail to recognize is that this is a zero sum game where we
>> currently have a
>> balance, and moving the efficiency toward allocation removes it from
>> operational deployment models that are different from the past. It is
>> extremely easy to overlook the fact that some deployment models don't
>> currently exist because they can't under the constraints of current
>> allocation policy. This leads to a false belief that they
>> will not appear
>> over the next several centuries because we have yet to see
>> them, when the
>> reality is that it is the limited perspective policies which
>> insure they
>> will not ever appear. The IETF has to take the position of
>> broad vision here
>> and flatly state that undue conservation is detrimental.
>>
>> The RIR members are basically a greedy bunch. For those who
>> have forgotten
>> history, the initial 64 bit proposal exceeded the IPv6 design
>> requirements
>> by 3 orders of magnitude. At the start of the dot com boom it
>> appeared there
>> would not be enough room for comfortable waste by the service
>> providers in
>> terms of hierarchy so the entire 64 bits was dedicated to
>> routing. Removing
>> the allocation needs of 10^15 hosts meant 'more than enough'
>> was now 'more
>> than more than enough', particularly in light of the bust and
>> consolidation.
>> Even so there are continuing complaints about the /64
>> boundary and demands
>> to relax that constraint because in historical deployment
>> terms that number
>> of bits per subnet is a waste. Never mind the issue that at
>> some point in
>> the lifetime of IPv6 the IEEE will be forced to move from 48 to 64 bit
>> EUI's... Fundamentally the RIR members just don't like being
>> told what to
>> do. If left alone they will constrain network deployments to
>> what has been
>> done in the past. It is up to the IPv6 WG to set the bar to
>> avoid the state
>> where people are forced to work around the restrictive policies of a
>> provider and/or LIR/RIR.
>>
>> Finally it takes extreme hubris to believe that IPv6 is 'THE'
>> protocol for
>> centuries or millennia to come. Technology moves on, and IPv6 will be
>> replaced long before the pool is exhausted. Those who point
>> to the phone
>> system as an example conveniently overlook the rolling evolution that
>> effectively reduces the window of applicability. While there
>> may be pockets
>> where things still work, in my experience equipment from 40
>> years ago is not
>> compatible with the current network so that example should be
>> measured in
>> decades rather than centuries. Even the numbering has
>> undergone periodic
>> change, so claiming we know enough to recognize allocation
>> waste centuries
>> before the person with a bright new idea is born is the
>> highest form of
>> arrogance. The /64 decision provides more than 'more than
>> enough' routing
>> space, and the /48 decision allows flexibility at the site
>> level without
>> significant impact on the service provider's ability to waste bits
>> themselves. Changing those values only makes it harder to
>> innovate in the
>> space of automated configuration of site networks and hosts,
>> and really
>> doesn't buy any useful time because we are talking about
>> adding time to the
>> point well beyond the useful lifetime of the protocol. As I said in
>> draft-hain-prefix-consider-00.txt there may be business
>> reasons to consider
>> other lengths, but there are no technical reasons. We need to
>> state that
>> clearly before the IPv6 WG closes.
>>
>> Tony
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6 at ietf.org
>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6 at ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 7150 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050803/f478fd7d/attachment.bin>

From randy at psg.com  Thu Aug  4 02:00:12 2005
From: randy at psg.com (Randy Bush)
Date: Wed, 3 Aug 2005 20:00:12 -1000
Subject: [ppml] Fwd: potpourri
References: <7ca072c83403fc8a459a5ce6de198c9f@karoshi.com>
Message-ID: <17137.44780.363389.220232@roam.psg.com>

>> IETF does need to make a statement because leaving this to the RIRs is
>> equivalent to leaving the fox in charge of access to the chickens.

and we're supposed to pay attention to what he says?  no thanks.

hostile ipv6 evangelist visionaries have demonstrated the lack of
their original v6 designs' deployability and have fought viciously
against every thing that has been done to fix it enough to get even
a wee bit off the ground.

randy




From william at elan.net  Thu Aug  4 02:11:12 2005
From: william at elan.net (william(at)elan.net)
Date: Wed, 3 Aug 2005 23:11:12 -0700 (PDT)
Subject: [ppml] Fwd: potpourri
In-Reply-To: <17137.44780.363389.220232@roam.psg.com>
References: <7ca072c83403fc8a459a5ce6de198c9f@karoshi.com>
	<17137.44780.363389.220232@roam.psg.com>
Message-ID: <Pine.LNX.4.62.0508032309390.20580@sokol.elan.net>


On Wed, 3 Aug 2005, Randy Bush wrote:

>>> IETF does need to make a statement because leaving this to the RIRs is
>>> equivalent to leaving the fox in charge of access to the chickens.
>
> and we're supposed to pay attention to what he says?  no thanks.
>
> hostile ipv6 evangelist visionaries have demonstrated the lack of
> their original v6 designs' deployability and have fought viciously
> against every thing that has been done to fix it enough to get even
> a wee bit off the ground.

I'm curious how can (does?) /48 boundary effect deployability?

-- 
William Leibzon
Elan Networks
william at elan.net


From bmanning at vacation.karoshi.com  Thu Aug  4 02:25:54 2005
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Thu, 4 Aug 2005 06:25:54 +0000
Subject: [ppml] Fwd: potpourri
In-Reply-To: <17137.44557.505903.9136@roam.psg.com>
References: <7ca072c83403fc8a459a5ce6de198c9f@karoshi.com>
	<17137.44557.505903.9136@roam.psg.com>
Message-ID: <20050804062554.GK13915@vacation.karoshi.com.>

On Wed, Aug 03, 2005 at 07:56:29PM -1000, Randy Bush wrote:
> >> IETF does need to make a statement because leaving this to the RIRs is
> >> equivalent to leaving the fox in charge of access to the chickens.
> 
> and we're supposed to pay attention to what he says?  no thanks.
> 
> hostile ipv6 evangelist visionaries have demonstrated the lack of
> their original v6 designs' deployability and have fought viciously
> against every thing that has been done to fix it enough to get even
> a wee bit off the ground.
> 
> randy

	if there is -supposed- to be a good relationship with
	the folks who develop protocols & by extention addressing plans,
	and the folks who are supposed to manage/maintain them, then
	I think that all is not well here.  Tony is casting the
	RIR community in a less than flattering light (which I found
	disturbing) and your characterization of some IETF folks as
	"hostile ipv6 evangelist visonaries" may not be seen as 
	entirely complimentary.  Is this the type of relationship 
	that we should be fostering?  

--bill


From david.conrad at nominum.com  Thu Aug  4 03:42:41 2005
From: david.conrad at nominum.com (David Conrad)
Date: Thu, 4 Aug 2005 00:42:41 -0700
Subject: [ppml] potpourri
In-Reply-To: <200508031229.IAA10942@ietf.org>
References: <200508031229.IAA10942@ietf.org>
Message-ID: <EC6C6BE2-7866-4A8E-9B22-8F04C049517C@nominum.com>

Tony,

I know I'm going to regret this since your post was so obviously  
flamebait preaching to the choir, but as the saying goes, you bring  
the flamethrower and I'll bring the marshmallows.

On Aug 3, 2005, at 5:28 AM, Tony Hain wrote:
> The IETF has to take the position of broad vision here
> and flatly state that undue conservation is detrimental.

Of course it is.  And water is wet.

The obvious point of contention is the definition of "undue".  Your  
definition differs from others due to the fact that there are  
different interpretations of possible future utilization trends.  The  
IETF's choice of a (relatively) small fixed number of bits guaranteed  
that this would be a problem, but hey, we sure showed those silly OSI  
fanatics and their obviously broken variable length addresses, didn't  
we?

> The RIR members are basically a greedy bunch.

No, no.  The correct, IETF sanctioned term is "Evil Greedy Bastard".   
Just checked the T-shirt I got back in '94 at the ALE meeting and  
that's definitely what it says.  Of course, I'm just one of the foxes  
in the henhouse now so I guess I need a different T-shirt.

> Even so there are continuing complaints about the /64 boundary and  
> demands
> to relax that constraint because in historical deployment terms  
> that number
> of bits per subnet is a waste.

Well, yes.  There are those who feel 18,446,744,073,709,551,616  
addresses is a bit much for any flat routed individual LAN, but those  
arguments are so passe these days.  Auto-configuration is indeed  
nice, at least in those environments that don't mind having arbitrary  
devices connect to the network and get valid IP addresses, but I  
guess I just have a wee bit of concern with arbitrary fixed  
boundaries since they worked so stunningly well in the past.  Must be  
a EGB flashback.  I'm sure I'll get over it.

> Never mind the issue that at some point in
> the lifetime of IPv6 the IEEE will be forced to move from 48 to 64 bit
> EUI's...

I suppose IPv6 will need to be revised so that the RFID addresses  
will fit.  Oh, wait...

> Fundamentally the RIR members just don't like being told what to do.

I guess this is accurate.  Perhaps, just maybe, the presumption that  
the IETF is qualified and/or appropriate to tell the RIR members what  
to do is where the dislike of being told what to do originates?

> If left alone they will constrain network deployments to what has been
> done in the past.

No.  If left alone, I would imagine they will constrain network  
deployments to what they believe will meet their business  
requirements.  At least the commercial ones.  If a particular RIR  
member believes what has been done in the past meets those  
requirements, that is probably what they will do.  If they believe  
deploying IPv6 will meet their requirements, guess what will happen?

> It is up to the IPv6 WG to set the bar to avoid the state
> where people are forced to work around the restrictive policies of a
> provider and/or LIR/RIR.

I would have thought it was the IPv6 WG's responsibility to  
standardize protocols that would address the issues that resulted in  
the restrictive policies.  The issue of address space limitations was  
sort-of addressed (in a sub-optimal way given this discussion).  But  
how about issues like transparent renumbering, multi-homing,  
separation of the end point identifier from the routing locator, and/ 
or other issues around routing system scalability?

For example, people are going to be forced to work around the  
restrictive policy that you have to renumber when you change  
providers.  I personally suspect they'll do that via NATv6.  If  
you're true to form, I'm sure you'll argue they'll do that by some  
variant of geographical addressing.  Since the EGBs you have such  
disdain for would have to play nicely together to go with your scheme  
and they don't have to do anything to support NATv6, I have a  
sneaking suspicion which approach will be deployed for the folks  
whose definition of the Internet is the World Wide Web and whose  
interpretation of "end-to-end" is something you find on those  
unmentionable web sites that, of course, they'd never go to (wink,  
wink, nudge, nudge).

Looking at the existing RIR databases, the "restrictive  
policies" (most of which were taken verbatim from the IETF holy  
texts) you deride have already resulted in /19s being allocated to  
single organizations (which, coincidentally, used to be the same  
prefix length RIPE-NCC used to allocate to LIRs when they initially  
requested space.  IPv4 /19s, of course).  And this is without  
governments requesting the space they feel they'll need for their  
national interests.  Governments like, oh say, China, India,  
Indonesia, etc.  If a /20 can be justified and allocated to Telstra  
or Telia, how much address space should (say) the People's Liberation  
Army of China get?

> Those who point to the phone
> system as an example conveniently overlook the rolling evolution that
> effectively reduces the window of applicability. While there may be  
> pockets
> where things still work, in my experience equipment from 40 years  
> ago is not
> compatible with the current network

My dad has a Stromberg-Carlson model 1212-A made in the 1930s.  I  
just spoke with him over it.  Seems to be compatible.  Not full  
featured by today's standards, but it does appear to do the function  
it was built for.  But perhaps you mean something else.

> Even the numbering has undergone periodic
> change, so claiming we know enough to recognize allocation waste  
> centuries
> before the person with a bright new idea is born is the highest  
> form of
> arrogance.

Alternatively, claiming we know enough to assume profligate waste  
will not cause the exact same arguments sometime within the  
foreseeable future could simply reiterate Hegel's quote "Those who  
cannot learn from history are doomed to repeat it".

I would however agree with you on one thing: there is a lot of  
arrogance here.

Rgds,
-drc



From alh-ietf at tndh.net  Thu Aug  4 13:33:32 2005
From: alh-ietf at tndh.net (Tony Hain)
Date: Thu, 4 Aug 2005 19:33:32 +0200
Subject: [ppml] potpourri
In-Reply-To: <EC6C6BE2-7866-4A8E-9B22-8F04C049517C@nominum.com>
Message-ID: <20050804173340.35B25144566@smtp2.arin.net>

David Conrad wrote:
> Tony,
> 
> I know I'm going to regret this since your post was so obviously
> flamebait preaching to the choir, but as the saying goes, you bring
> the flamethrower and I'll bring the marshmallows.
> 
> On Aug 3, 2005, at 5:28 AM, Tony Hain wrote:
> > The IETF has to take the position of broad vision here
> > and flatly state that undue conservation is detrimental.
> 
> Of course it is.  And water is wet.
> 
> The obvious point of contention is the definition of "undue".  Your
> definition differs from others due to the fact that there are
> different interpretations of possible future utilization trends.  The
> IETF's choice of a (relatively) small fixed number of bits guaranteed
> that this would be a problem, but hey, we sure showed those silly OSI
> fanatics and their obviously broken variable length addresses, didn't
> we?

To recall history, I was a proponent of TUBA (TCP over NSAPs), simply due to
getting things done quickly... That is irrelevant though as we now have what
we have. Yes we differ on the definition of 'undue'. My definition says that
we should have more than enough to last us until the replacement is
deployed. Three will be all kinds of reasons for that to happen before 2100,
not the least of which is that yet to be born researchers will be
continuously looking for the 'optimal' approaches to move bits around.
History shows that the definition of 'optimal' varies based on perspective
and the specific application at hand. Yes we should make sure that if no
better ideas come along before the end of the century that we can sustain
until that happens, but we don't need to make it last longer than recorded
history. 

> 
> > The RIR members are basically a greedy bunch.
> 
> No, no.  The correct, IETF sanctioned term is "Evil Greedy Bastard".
> Just checked the T-shirt I got back in '94 at the ALE meeting and
> that's definitely what it says.  Of course, I'm just one of the foxes
> in the henhouse now so I guess I need a different T-shirt.

I was not trying to create hostilities, just point out that complaining
about the other guy having too many when you already have more than 'more
than enough' can only be described as greed.

> 
> > Even so there are continuing complaints about the /64 boundary and
> > demands
> > to relax that constraint because in historical deployment terms
> > that number
> > of bits per subnet is a waste.
> 
> Well, yes.  There are those who feel 18,446,744,073,709,551,616
> addresses is a bit much for any flat routed individual LAN, but those
> arguments are so passe these days.  Auto-configuration is indeed
> nice, at least in those environments that don't mind having arbitrary
> devices connect to the network and get valid IP addresses, but I
> guess I just have a wee bit of concern with arbitrary fixed
> boundaries since they worked so stunningly well in the past.  Must be
> a EGB flashback.  I'm sure I'll get over it.
> 
> > Never mind the issue that at some point in
> > the lifetime of IPv6 the IEEE will be forced to move from 48 to 64 bit
> > EUI's...
> 
> I suppose IPv6 will need to be revised so that the RFID addresses
> will fit.  Oh, wait...
> 
> > Fundamentally the RIR members just don't like being told what to do.
> 
> I guess this is accurate.  Perhaps, just maybe, the presumption that
> the IETF is qualified and/or appropriate to tell the RIR members what
> to do is where the dislike of being told what to do originates?

The IETF can and should say what the technical issues and trade-off's are.
The policies about managing within those constraints is not the IETF's
business. 

> 
> > If left alone they will constrain network deployments to what has been
> > done in the past.
> 
> No.  If left alone, I would imagine they will constrain network
> deployments to what they believe will meet their business
> requirements.  

'Their business requirements' is the key here. Those without voice are left
to take what they can get, and will innovate with bypass technologies (like
skype) when they can't get what they really want. 

> At least the commercial ones.  If a particular RIR
> member believes what has been done in the past meets those
> requirements, that is probably what they will do.  If they believe
> deploying IPv6 will meet their requirements, guess what will happen?

History shows that their requirements end up being restrictions on what
their customers can do. Until there is true competition which allows people
to shop for service that meets their needs there will be bypass technologies
developed to get around the arbitrary restrictions. We don't need bypass
technologies for artificially restricted address allocations. 

> 
> > It is up to the IPv6 WG to set the bar to avoid the state
> > where people are forced to work around the restrictive policies of a
> > provider and/or LIR/RIR.
> 
> I would have thought it was the IPv6 WG's responsibility to
> standardize protocols that would address the issues that resulted in
> the restrictive policies.  The issue of address space limitations was
> sort-of addressed (in a sub-optimal way given this discussion).  But
> how about issues like transparent renumbering, multi-homing,
> separation of the end point identifier from the routing locator, and/
> or other issues around routing system scalability?

Those are interesting topics but they were/are not design requirements for
the packet transport protocol between networks. What the IPv6 WG has done is
define the pieces to replace those associated with IPv4 as packet transport
between networks. 

> 
> For example, people are going to be forced to work around the
> restrictive policy that you have to renumber when you change
> providers.  I personally suspect they'll do that via NATv6.  If
> you're true to form, I'm sure you'll argue they'll do that by some
> variant of geographical addressing. 

I don't care what form PI takes. My proposal is just one way that happens to
work with the existing BGP and has a managed degree of aggregation. I tried
to get a bof at this IETF to talk about the general issue of aggregating
approaches to PI but it was turned down because people are putting too much
faith in shim6. 

> Since the EGBs you have such
> disdain for would have to play nicely together to go with your scheme
> and they don't have to do anything to support NATv6, I have a
> sneaking suspicion which approach will be deployed for the folks
> whose definition of the Internet is the World Wide Web and whose
> interpretation of "end-to-end" is something you find on those
> unmentionable web sites that, of course, they'd never go to (wink,
> wink, nudge, nudge).

See draft-ietf-v6ops-nap-01.txt

> 
> Looking at the existing RIR databases, the "restrictive
> policies" (most of which were taken verbatim from the IETF holy
> texts) you deride have already resulted in /19s being allocated to
> single organizations (which, coincidentally, used to be the same
> prefix length RIPE-NCC used to allocate to LIRs when they initially
> requested space.  IPv4 /19s, of course).  And this is without
> governments requesting the space they feel they'll need for their
> national interests.  Governments like, oh say, China, India,
> Indonesia, etc.  If a /20 can be justified and allocated to Telstra
> or Telia, how much address space should (say) the People's Liberation
> Army of China get?

Misinterpretation of host measures as useful in allocating network prefixes
is not an IETF issue. Using the proposed measure of .94 would fix the basic
problem you raise. Not fixing that will result in the ITU helping answer
your last question.

> 
> > Those who point to the phone
> > system as an example conveniently overlook the rolling evolution that
> > effectively reduces the window of applicability. While there may be
> > pockets
> > where things still work, in my experience equipment from 40 years
> > ago is not
> > compatible with the current network
> 
> My dad has a Stromberg-Carlson model 1212-A made in the 1930s.  I
> just spoke with him over it.  Seems to be compatible.  Not full
> featured by today's standards, but it does appear to do the function
> it was built for.  But perhaps you mean something else.

My rotary dial model is able to receive but not place calls. Placing calls
is a fundamental requirement in my experience. YMMV ;)

> 
> > Even the numbering has undergone periodic
> > change, so claiming we know enough to recognize allocation waste
> > centuries
> > before the person with a bright new idea is born is the highest
> > form of
> > arrogance.
> 
> Alternatively, claiming we know enough to assume profligate waste
> will not cause the exact same arguments sometime within the
> foreseeable future could simply reiterate Hegel's quote "Those who
> cannot learn from history are doomed to repeat it".

Our difference is in the measure of 'waste'. Your claim is that there is
waste in allocating the same number of bits to the subnet as to routing. The
number of bits used by a subnet is completely irrelevant because that was
decided after the number of bits used for routing was decided to be more
than enough to meet the design goals. The discussion about /48 vs. /56 is
simply about the amount of cushion in routing bits that will be 'wasted'
after IPv6 is replaced. If we knew the date that cool new innovations would
drive a replacement for IPv6 we could optimize allocations to exactly meet
the need. The best we can do is target a lifetime, and several centuries
that are the result of /48's with an HD of .94 is likely to be more than
long enough. 

Tony

> 
> I would however agree with you on one thing: there is a lot of
> arrogance here.
> 
> Rgds,
> -drc



From memsvcs at arin.net  Wed Aug 10 11:30:21 2005
From: memsvcs at arin.net (Member Services)
Date: Wed, 10 Aug 2005 11:30:21 -0400
Subject: [ppml] Proposed Policy: IPv4 Micro-allocations for anycast services
Message-ID: <42FA1D8D.900@arin.net>

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

The ARIN Advisory Council (AC) will review the proposal and within ten
working days may decide to:
1)  Support the proposal as is,
2)  Work with the author to clarify, divide or combine one or more
policy proposals, or
3)  Not support the policy proposal.

If the AC supports the proposal or reaches an agreement to work with the
author, then the proposal will be posted as a formal policy proposal to
the Public Policy Mailing List and it will be presented at the Public
Policy Meeting. If the AC does not support the proposal, then the author
may elect to use the petition process to advance the proposal. If the
author elects not to petition or the petition fails, then the proposed
policy will be considered closed.

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

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)

### * ###

Policy Proposal Name: IPv4 Micro-allocations for anycast services

Author: David Williamson

Policy term: permanent

Policy statement:

In the NRPM IPv4 section, renumber 4.4 to 4.4.1, and add:

4.4.2 Micro-allocations for anycast services - ARIN will make
micro-allocations to organizations wishing to deploy anycast based
services, provided they meet the following criteria:

     * All of the criteria normally required to receive IPv4 space, AND
     * The organization must have multiple (at least two) discrete
	multi-homed networks.
     * The organization must identify which networks, ASNs, or sites
	will host the new service.
     * The organization must provide a description of the anycast service.

Micro-allocations for anycast services will be no longer than a /24.
These allocations will be made out of blocks reserved for
micro-allocation purposes.  ISPs and other organizations receiving these
micro-allocations will be charged under the ISP fee schedule, while
end-users will be charged under the fee schedule for end-users.

Rationale:

There are an increasing number of anycast-based applications being
offered by service providers and other organizations.  Indeed, many
basic infrastructure services (like the DNS root servers) are already
anycast based.  (See RFC 1546 for an authoritative discussion of anycast
services.)

Deployment of new services is hampered, however, by current IPv4
allocation policies.  For organizations that do not have legacy IP
space, justifying a /22 to serve a handful of addresses is effectively
impossible.  As many ISPs also filter routes longer than /22, it is
impractical to use a longer mask for any netblock that is utilized for
an anycast service.  This situation is also generally unfavorable to
younger organizations, while giving older organizations that do have a
surplus of legacy space a competitive advantage.

In light of this, some organizations may simply lie about their
addressing needs in order to convince an RIR that a /22 is required,
when a much smaller network would suffice.  This is not a behavior that
should be encouraged by policy.

The obvious answer is that a micro-allocation scheme needs to be created
to allow organizations deploying anycast services to acquire a network
of more appropriate size.

It is also clear that a micro-allocation policy that makes it easier for
organizations to acquire small netblocks may lead to additional improper
allocations to organizations that simply wish to acquire additional
small blocks of space.  This policy proposal attempts to address that by
requiring more stringent requirements for such allocations.

Timetable for implementation: immediate




From owen at delong.com  Wed Aug 10 14:31:31 2005
From: owen at delong.com (Owen DeLong)
Date: Wed, 10 Aug 2005 11:31:31 -0700
Subject: [ppml] Proposed Policy: IPv4 Micro-allocations for anycast
 services
In-Reply-To: <42FA1D8D.900@arin.net>
References: <42FA1D8D.900@arin.net>
Message-ID: <78F669F5345BD889F6A34228@imac-en0.delong.sj.ca.us>

I fully support this policy.  There are a number of advantages to making
these
microallocations and I think they are every bit as legitimate as the EP /24s
that are already authorized.

Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050810/f57bee03/attachment.sig>

From matt.pounsett at cira.ca  Wed Aug 10 19:01:29 2005
From: matt.pounsett at cira.ca (Matt Pounsett)
Date: Wed, 10 Aug 2005 19:01:29 -0400
Subject: [ppml] Proposed Policy: IPv4 Micro-allocations for anycast
	services
In-Reply-To: <42FA1D8D.900@arin.net>
References: <42FA1D8D.900@arin.net>
Message-ID: <59F1DD26-1F18-4800-83DD-34CB978E55B8@cira.ca>

In principal, I support this proposal.  However, wouldn't it make  
sense to incorporate it into the existing 4.4 as just another  
justification?

If not, then I'd like to see this text expanded slightly to be more  
in line with the current 4.4 text; for example, reference v4 and v6  
allocations.

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

From bicknell at ufp.org  Wed Aug 10 22:47:47 2005
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 10 Aug 2005 22:47:47 -0400
Subject: [ppml] Proposed Policy: IPv4 Micro-allocations for anycast
	services
In-Reply-To: <42FA1D8D.900@arin.net>
References: <42FA1D8D.900@arin.net>
Message-ID: <20050811024747.GA18996@ussenterprise.ufp.org>


I like the concept behind this policy, that is to say we shouldn't
make it hard to deploy anycast services.

My concern though is does the policy as written open up the floodgates
and/or create loopholes with great abound.  Meeting the requirements
as listed is not hard.  What happens if people end up not using
these blocks for anycast services, but rather just as unicast blocks?
Does the community really want to open up anycast to a wide spectrum
of people, when the technique is full of pitfalls (for instance,
TCP applications don't always work so well)?  If someone has multiple
services out of the same POP's, can each service have any anycast block,
or only one per company?

I haven't yet formed a full opinion one way or the other, but I do
think some tigher controls would make me much happer, personally.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050810/f86c9be8/attachment.sig>

From owen at delong.com  Thu Aug 11 02:57:21 2005
From: owen at delong.com (Owen DeLong)
Date: Wed, 10 Aug 2005 23:57:21 -0700
Subject: [ppml] Proposed Policy: IPv4 Micro-allocations for
 anycast	services
In-Reply-To: <20050811024747.GA18996@ussenterprise.ufp.org>
References: <42FA1D8D.900@arin.net>
	<20050811024747.GA18996@ussenterprise.ufp.org>
Message-ID: <558CCAB2E00D4A7FA48F2D95@l1-local.netli.net>

I would expect that each ORG should be limited to a single Anycast block 
until they
can show sufficient service density to justify additional 
allocation/assignment.
For example, if an ORG receives a /24, then, when they have 200+ anycast 
services
deployed, they might be able to justify an additional block.

Not sure how to codify that into policy, but, I think that would address 
your
concerns.

As to the pitfall issues, I think it would be good to put some "Is
Anycast what you really want to do?" information up on the ARIN education 
pages
and refer applicants to them, but, in general, the internet is a loaded 
weapon,
and, like a handgun, requires no special training to purchase.  As such, I 
think
it is not ARINs role to prevent people from shooting themselves in the foot.

Owen

--On August 10, 2005 10:47:47 PM -0400 Leo Bicknell <bicknell at ufp.org> 
wrote:

>
> I like the concept behind this policy, that is to say we shouldn't
> make it hard to deploy anycast services.
>
> My concern though is does the policy as written open up the floodgates
> and/or create loopholes with great abound.  Meeting the requirements
> as listed is not hard.  What happens if people end up not using
> these blocks for anycast services, but rather just as unicast blocks?
> Does the community really want to open up anycast to a wide spectrum
> of people, when the technique is full of pitfalls (for instance,
> TCP applications don't always work so well)?  If someone has multiple
> services out of the same POP's, can each service have any anycast block,
> or only one per company?
>
> I haven't yet formed a full opinion one way or the other, but I do
> think some tigher controls would make me much happer, personally.



-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050810/1306683c/attachment.sig>

From marla_azinger at eli.net  Thu Aug 11 12:30:23 2005
From: marla_azinger at eli.net (Azinger, Marla)
Date: Thu, 11 Aug 2005 09:30:23 -0700
Subject: [ppml] Proposed Policy: IPv4 Micro-allocations for anycast
	services
Message-ID: <10ECB7F03C568F48B9213EF9E7F790D202100BFB@wava00s2ke2k01.corp.pvt>

David, here are my questions and comments~

1. I assume their is a routing reason behind this but just so everyone is clear, can you provide the reasoning behind the decision to make these allocations come from a "reserved block"?

2. Does this policy really help anything by allowing /24's as a microallocation if you are sincere with the statement below?  Or am I misinterpreting it?  Or is this part of a routing rational?
	"As many ISPs also filter routes longer than /22, it is
	impractical to use a longer mask for any netblock that is utilized for
	an anycast service."


Thank you for your time
Marla Azinger
Electric Lightwave
Frontier Communications
IP Engineer

-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
Member Services
Sent: Wednesday, August 10, 2005 8:30 AM
To: ppml at arin.net
Subject: [ppml] Proposed Policy: IPv4 Micro-allocations for anycast
services


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

The ARIN Advisory Council (AC) will review the proposal and within ten
working days may decide to:
1)  Support the proposal as is,
2)  Work with the author to clarify, divide or combine one or more
policy proposals, or
3)  Not support the policy proposal.

If the AC supports the proposal or reaches an agreement to work with the
author, then the proposal will be posted as a formal policy proposal to
the Public Policy Mailing List and it will be presented at the Public
Policy Meeting. If the AC does not support the proposal, then the author
may elect to use the petition process to advance the proposal. If the
author elects not to petition or the petition fails, then the proposed
policy will be considered closed.

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

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)

### * ###

Policy Proposal Name: IPv4 Micro-allocations for anycast services

Author: David Williamson

Policy term: permanent

Policy statement:

In the NRPM IPv4 section, renumber 4.4 to 4.4.1, and add:

4.4.2 Micro-allocations for anycast services - ARIN will make
micro-allocations to organizations wishing to deploy anycast based
services, provided they meet the following criteria:

     * All of the criteria normally required to receive IPv4 space, AND
     * The organization must have multiple (at least two) discrete
	multi-homed networks.
     * The organization must identify which networks, ASNs, or sites
	will host the new service.
     * The organization must provide a description of the anycast service.

Micro-allocations for anycast services will be no longer than a /24.
These allocations will be made out of blocks reserved for
micro-allocation purposes.  ISPs and other organizations receiving these
micro-allocations will be charged under the ISP fee schedule, while
end-users will be charged under the fee schedule for end-users.

Rationale:

There are an increasing number of anycast-based applications being
offered by service providers and other organizations.  Indeed, many
basic infrastructure services (like the DNS root servers) are already
anycast based.  (See RFC 1546 for an authoritative discussion of anycast
services.)

Deployment of new services is hampered, however, by current IPv4
allocation policies.  For organizations that do not have legacy IP
space, justifying a /22 to serve a handful of addresses is effectively
impossible.  As many ISPs also filter routes longer than /22, it is
impractical to use a longer mask for any netblock that is utilized for
an anycast service.  This situation is also generally unfavorable to
younger organizations, while giving older organizations that do have a
surplus of legacy space a competitive advantage.

In light of this, some organizations may simply lie about their
addressing needs in order to convince an RIR that a /22 is required,
when a much smaller network would suffice.  This is not a behavior that
should be encouraged by policy.

The obvious answer is that a micro-allocation scheme needs to be created
to allow organizations deploying anycast services to acquire a network
of more appropriate size.

It is also clear that a micro-allocation policy that makes it easier for
organizations to acquire small netblocks may lead to additional improper
allocations to organizations that simply wish to acquire additional
small blocks of space.  This policy proposal attempts to address that by
requiring more stringent requirements for such allocations.

Timetable for implementation: immediate


_______________________________________________
PPML mailing list
PPML at arin.net
http://lists.arin.net/mailman/listinfo/ppml


From marla_azinger at eli.net  Thu Aug 11 12:37:05 2005
From: marla_azinger at eli.net (Azinger, Marla)
Date: Thu, 11 Aug 2005 09:37:05 -0700
Subject: [ppml] Proposed Policy: IPv4 Micro-allocations for
	anycastservices
Message-ID: <10ECB7F03C568F48B9213EF9E7F790D201512453@wava00s2ke2k01.corp.pvt>

This policy only refers to V4 when mentioning /24 and /22's.  What would your suggestion be to make it applicable to V6?

Marla
ELI and Frontier IP Engineer

-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
Matt Pounsett
Sent: Wednesday, August 10, 2005 4:01 PM
To: ppml at arin.net
Subject: Re: [ppml] Proposed Policy: IPv4 Micro-allocations for
anycastservices


In principal, I support this proposal.  However, wouldn't it make  
sense to incorporate it into the existing 4.4 as just another  
justification?

If not, then I'd like to see this text expanded slightly to be more  
in line with the current 4.4 text; for example, reference v4 and v6  
allocations.

Matt


From matt.pounsett at cira.ca  Thu Aug 11 12:46:20 2005
From: matt.pounsett at cira.ca (Matt Pounsett)
Date: Thu, 11 Aug 2005 12:46:20 -0400
Subject: [ppml] Proposed Policy: IPv4 Micro-allocations for
	anycastservices
In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D201512453@wava00s2ke2k01.corp.pvt>
References: <10ECB7F03C568F48B9213EF9E7F790D201512453@wava00s2ke2k01.corp.pvt>
Message-ID: <9EB690F7-EF47-4C00-AD28-3A8B8F87FDBA@cira.ca>


On 11-Aug-2005, at 12:37 , Azinger, Marla wrote:

> This policy only refers to V4 when mentioning /24 and /22's.  What  
> would your suggestion be to make it applicable to V6?

The current 4.4 text refers to micro-allocations of v4 addresses (no  
longer than a /24) and v6 (no longer than a /28).  Whether the same  
mask lengths are used is perhaps up for debate, but I think any new  
policy should refer to v4 and v6 when applicable.. and I think it's  
applicable in this case.

Matt

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

From ahp at hilander.com  Thu Aug 11 12:48:46 2005
From: ahp at hilander.com (Alec H. Peterson)
Date: Thu, 11 Aug 2005 10:48:46 -0600
Subject: [ppml] Proposed Policy: IPv4 Micro-allocations
 for	anycastservices
In-Reply-To: <9EB690F7-EF47-4C00-AD28-3A8B8F87FDBA@cira.ca>
References: <10ECB7F03C568F48B9213EF9E7F790D201512453@wava00s2ke2k01.corp.pvt
	> <9EB690F7-EF47-4C00-AD28-3A8B8F87FDBA@cira.ca>
Message-ID: <120C5F35DF2B89A194882992@Alec-Petersons-Computer.local>

--On August 11, 2005 12:46:20 -0400 Matt Pounsett <matt.pounsett at cira.ca> 
wrote:

>
> The current 4.4 text refers to micro-allocations of v4 addresses (no
> longer than a /24) and v6 (no longer than a /28).  Whether the same  mask
> lengths are used is perhaps up for debate, but I think any new  policy
> should refer to v4 and v6 when applicable.. and I think it's  applicable
> in this case.

I think that's a /48 for IPv6 (I hope it is anyway :-)

Alec






From matt.pounsett at cira.ca  Thu Aug 11 12:54:53 2005
From: matt.pounsett at cira.ca (Matt Pounsett)
Date: Thu, 11 Aug 2005 12:54:53 -0400
Subject: [ppml] Proposed Policy: IPv4 Micro-allocations
	for	anycastservices
In-Reply-To: <120C5F35DF2B89A194882992@Alec-Petersons-Computer.local>
References: <10ECB7F03C568F48B9213EF9E7F790D201512453@wava00s2ke2k01.corp.pvt
	> <9EB690F7-EF47-4C00-AD28-3A8B8F87FDBA@cira.ca>
	<120C5F35DF2B89A194882992@Alec-Petersons-Computer.local>
Message-ID: <43E3E027-D9C6-4683-AA88-14934EB9F92F@cira.ca>


On 11-Aug-2005, at 12:48 , Alec H. Peterson wrote:

> --On August 11, 2005 12:46:20 -0400 Matt Pounsett  
> <matt.pounsett at cira.ca> wrote:
>
>
>>
>> The current 4.4 text refers to micro-allocations of v4 addresses (no
>> longer than a /24) and v6 (no longer than a /28).  Whether the  
>> same  mask
>> lengths are used is perhaps up for debate, but I think any new   
>> policy
>> should refer to v4 and v6 when applicable.. and I think it's   
>> applicable
>> in this case.
>>
>
> I think that's a /48 for IPv6 (I hope it is anyway :-)

Yeah, you're right.  That was a typo on my part. :)


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

From owen at delong.com  Thu Aug 11 13:00:46 2005
From: owen at delong.com (Owen DeLong)
Date: Thu, 11 Aug 2005 10:00:46 -0700
Subject: [ppml] Proposed Policy: IPv4 Micro-allocations for
 anycast	services
In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100BFB@wava00s2ke2k01.corp.pvt>
References: <10ECB7F03C568F48B9213EF9E7F790D202100BFB@wava00s2ke2k01.corp.pv t>
Message-ID: <75C2B48F4FE3B13D4EDCF982@imac-en0.delong.sj.ca.us>



--On August 11, 2005 9:30:23 AM -0700 "Azinger, Marla"
<marla_azinger at eli.net> wrote:

> David, here are my questions and comments~
> 
> 1. I assume their is a routing reason behind this but just so everyone is
> clear, can you provide the reasoning behind the decision to make these
> allocations come from a "reserved block"?
> 
I can't speak to David's reasons, but, I know I would want them in a
reserved
block so that people filtering on prefix length could allow these blocks to
be
advertised with a minimum of filter wizardry required.

> 2. Does this policy really help anything by allowing /24's as a
> microallocation if you are sincere with the statement below?  Or am I
> misinterpreting it?  Or is this part of a routing rational?
> 	"As many ISPs also filter routes longer than /22, it is
> 	impractical to use a longer mask for any netblock that is utilized for
> 	an anycast service."
> 
I think the belief is that ISPs tend to follow ARIN policy in terms of
filtration
on prefix length.  While ARIN can't and doesn't set routing policy or
guarantee
routability of any prefix, the reality is that ISPs do tend to base prefix
length
filters on RIR policy for the most part.  As such, yes, having /24 prefixes
called out in ARIN policy would most likely help this situation.

Owen

-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050811/747053c8/attachment.sig>

From andrew.dul at quark.net  Thu Aug 11 13:32:11 2005
From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=)
Date: Thu, 11 Aug 2005 17:32:11 +0000
Subject: [ppml] Proposed Policy: IPv4 Micro-allocations for anycast
	services
Message-ID: <20050811173211.10852.qmail@hoster908.com>

While, I believe that there may be a need for this policy, I'd like to understand the "new services" that are envisioned to thrive under this service.  I certainly don't want ARIN to be in the position of inhibiting the growth of real services.

I think the requirements to obtain an address block under the proposed text of the policy are not rigid enough.  I'm not sure yet how we could rework this to make it more rigid.
  


>  4.4.2 Micro-allocations for anycast services - ARIN will make
>  micro-allocations to organizations wishing to deploy anycast based
>  services, provided they meet the following criteria:
>  
>       * All of the criteria normally required to receive IPv4 space, AND

Hi, I have two offices, we have 68 IP devices in one office and 73 IP devices in the other office.

>       * The organization must have multiple (at least two) discrete
>  multi-homed networks.

The offices are in two different buildings, have a T1 between them, and a T1 to the internet from both locations...we currently are allocated a /24 from our ISP.

>       * The organization must identify which networks, ASNs, or sites
>  will host the new service.

Office A located at 123 my street, my town, 
Office B located at 234 your street, their town,

Both are announced from bgp via ASXXXXX

>       * The organization must provide a description of the anycast service.

We have anycast DNS servers already deployed in both locations.

May I please have a /24.

Thank you...

That seems too easy to me...

Andrew
ARIN AC


From gih at apnic.net  Thu Aug 11 16:16:51 2005
From: gih at apnic.net (Geoff Huston)
Date: Fri, 12 Aug 2005 06:16:51 +1000
Subject: [ppml] Proposed Policy: IPv4 Micro-allocations
 for	anycastservices
In-Reply-To: <120C5F35DF2B89A194882992@Alec-Petersons-Computer.local>
References: <10ECB7F03C568F48B9213EF9E7F790D201512453@wava00s2ke2k01.corp.pvt >
	<9EB690F7-EF47-4C00-AD28-3A8B8F87FDBA@cira.ca>
	<120C5F35DF2B89A194882992@Alec-Petersons-Computer.local>
Message-ID: <6.2.0.14.2.20050812061413.026a73a0@kahuna.telstra.net>

At 02:48 AM 12/08/2005, Alec H. Peterson wrote:
>--On August 11, 2005 12:46:20 -0400 Matt Pounsett <matt.pounsett at cira.ca>
>wrote:
>
> >
> > The current 4.4 text refers to micro-allocations of v4 addresses (no
> > longer than a /24) and v6 (no longer than a /28).  Whether the same  mask
> > lengths are used is perhaps up for debate, but I think any new  policy
> > should refer to v4 and v6 when applicable.. and I think it's  applicable
> > in this case.
>
>I think that's a /48 for IPv6 (I hope it is anyway :-)


or a /56

i.e. are you referring to the smallest subnet-capable network allocation 
under prevailing V6 allocation policies at the time, or do you consider a 
micro allocation in the V6 context to refer to a single network, in which 
case this would be analogous to a /64 allocation?

regards,

    Geoff







From matt.pounsett at cira.ca  Fri Aug 12 10:54:59 2005
From: matt.pounsett at cira.ca (Matt Pounsett)
Date: Fri, 12 Aug 2005 10:54:59 -0400
Subject: [ppml] Proposed Policy: IPv4 Micro-allocations for
	anycastservices
In-Reply-To: <20050811174430.GE21512@shell01.corp.tellme.com>
References: <10ECB7F03C568F48B9213EF9E7F790D201512453@wava00s2ke2k01.corp.pvt>
	<9EB690F7-EF47-4C00-AD28-3A8B8F87FDBA@cira.ca>
	<20050811174430.GE21512@shell01.corp.tellme.com>
Message-ID: <3FCBDB73-C900-48EB-855B-FB1CFA89121C@cira.ca>


On 2005-Aug-11, at 13:44 , David Williamson wrote:

> While I would normally agree that any new policy should address both
> ipv4 and ipv6, I think that the technologies behind anycast are
> sufficiently different between the two to justify separate policies,
> and I didn't attempt to define anything beyond a policy for ipv4.

Ah, okay.  This makes much sense, and I think your answer resolves  
the concerns I raised.
Thanks David.

Matt


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

From matt.pounsett at cira.ca  Fri Aug 12 10:59:45 2005
From: matt.pounsett at cira.ca (Matt Pounsett)
Date: Fri, 12 Aug 2005 10:59:45 -0400
Subject: [ppml] Proposed Policy: IPv4 Micro-allocations
	for	anycastservices
In-Reply-To: <6.2.0.14.2.20050812061413.026a73a0@kahuna.telstra.net>
References: <10ECB7F03C568F48B9213EF9E7F790D201512453@wava00s2ke2k01.corp.pvt
	> <9EB690F7-EF47-4C00-AD28-3A8B8F87FDBA@cira.ca>
	<120C5F35DF2B89A194882992@Alec-Petersons-Computer.local>
	<6.2.0.14.2.20050812061413.026a73a0@kahuna.telstra.net>
Message-ID: <DFFF2FE1-969A-4775-A27A-ED6D3450932A@cira.ca>


On 2005-Aug-11, at 16:16 , Geoff Huston wrote:

> At 02:48 AM 12/08/2005, Alec H. Peterson wrote:
>
>> --On August 11, 2005 12:46:20 -0400 Matt Pounsett  
>> <matt.pounsett at cira.ca>
>> wrote:
>>
>> >
>> > The current 4.4 text refers to micro-allocations of v4 addresses  
>> (no
>> > longer than a /24) and v6 (no longer than a /28).  Whether the  
>> same  mask
>> > lengths are used is perhaps up for debate, but I think any new   
>> policy
>> > should refer to v4 and v6 when applicable.. and I think it's   
>> applicable
>> > in this case.
>>
>> I think that's a /48 for IPv6 (I hope it is anyway :-)
>>
>
>
> or a /56
>
> i.e. are you referring to the smallest subnet-capable network  
> allocation under prevailing V6 allocation policies at the time, or  
> do you consider a micro allocation in the V6 context to refer to a  
> single network, in which case this would be analogous to a /64  
> allocation?

We were talking specifically about the current section 4.4, which  
states that a /48 is the longest v6 allocation that should be made  
using that section of the policy.

David has already responded to the question of including v6 in this  
proposed policy, and I think (unless I've missed something) cleared  
up any perceived need to include v6 in this text.

Matt


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

From dlw+arin at tellme.com  Fri Aug 12 11:29:40 2005
From: dlw+arin at tellme.com (David Williamson)
Date: Fri, 12 Aug 2005 08:29:40 -0700
Subject: [ppml] Proposed Policy: IPv4 Micro-allocations for anycast
	services
In-Reply-To: <20050811173211.10852.qmail@hoster908.com>
References: <20050811173211.10852.qmail@hoster908.com>
Message-ID: <20050812152940.GO21512@shell01.corp.tellme.com>

First things first: I've sent a couple of replies that didn't show up
on the list.  That's due to being a bonehead and not sending them from
the address I used to subscribe.  Other than this issue, I believe the
other questions have been adequately answered.

On Thu, Aug 11, 2005 at 05:32:11PM +0000, Andrew Dul wrote:
> I think the requirements to obtain an address block under the proposed 
> text of the policy are not rigid enough.  I'm not sure yet how we could 
> rework this to make it more rigid.

In writing this policy, I struggled for some time with how tight the
requirements should be.  I'm open to suggestions, although I'm mostly
happy with the current set.  Making the requirements much stricter will
impose significant restrictions on the ability of legitimate requestors
to receive space.  On the other hand, I don't want every small office
in ARIN's jurisdiction claiming to have an anycast DNS server.

Balance is the key, and finding the right balance has thus far been
hard.  I suspect that relatively few companies have a real need for
an anycast service.  (I happen to work for one.)  Most of those will
have a handful, at most, of such services.  Allowing them to get a
microallocation is clearly the right thing to do, versus wasting a
much larger block to announce a couple of addresses.


From davidu at everydns.net  Fri Aug 12 11:40:43 2005
From: davidu at everydns.net (David Ulevitch)
Date: Fri, 12 Aug 2005 08:40:43 -0700
Subject: [ppml] Proposed Policy: IPv4 Micro-allocations for anycast
	services
In-Reply-To: <20050812152940.GO21512@shell01.corp.tellme.com>
References: <20050811173211.10852.qmail@hoster908.com>
	<20050812152940.GO21512@shell01.corp.tellme.com>
Message-ID: <E472398F-B30C-4E69-B3EE-7497396975FA@everydns.net>


On Aug 12, 2005, at 8:29 AM, David Williamson wrote:

> Making the requirements much stricter will
> impose significant restrictions on the ability of legitimate  
> requestors
> to receive space.  On the other hand, I don't want every small office
> in ARIN's jurisdiction claiming to have an anycast DNS server.

But it's so trendy! :-)  This is my concern.  The concerns are  
similar, although in my mind more real, as they were for the /22's  
for multihoming policy. I don't know if that's been "abused" at all.   
If it hasn't then there isn't much reason to believe this will be.   
The only problem is that there is no real recourse against someone  
just turning it into their own /24 to use for non-anycast purposes as  
I understand ARIN policies.

> I suspect that relatively few companies have a real need for
> an anycast service.  (I happen to work for one.)

As do I -- and that's the problem.  I worry about all of ARIN  
membership all of the sudden realizing that they too have a "real  
need" for anycast services.  I think people have this impression that  
anycast == higher uptime.  If anything that is probably not the case  
as it can easily be executed/deployed improperly and/or poorly.

Thanks,
David Ulevitch



From ahp at hilander.com  Fri Aug 12 11:47:59 2005
From: ahp at hilander.com (Alec H. Peterson)
Date: Fri, 12 Aug 2005 09:47:59 -0600
Subject: [ppml] Proposed Policy: IPv4 Micro-allocations for
 anycast	services
In-Reply-To: <E472398F-B30C-4E69-B3EE-7497396975FA@everydns.net>
References: <20050811173211.10852.qmail@hoster908.com>
	<20050812152940.GO21512@shell01.corp.tellme.com>
	<E472398F-B30C-4E69-B3EE-7497396975FA@everydns.net>
Message-ID: <1B6E0B2A5B0D7BC99A4582F6@Alec-Petersons-Computer.local>

Hi David,

--On August 12, 2005 8:40:43 -0700 David Ulevitch <davidu at everydns.net> 
wrote:

>
> As do I -- and that's the problem.  I worry about all of ARIN
> membership all of the sudden realizing that they too have a "real
> need" for anycast services.  I think people have this impression that
> anycast == higher uptime.  If anything that is probably not the case
> as it can easily be executed/deployed improperly and/or poorly.

That's like saying that the impression that multihoming == higher uptime is 
a fallacy because it can easily be deployed poorly.  Anycast does increase 
uptime when done intelligently.

However, that notwithstanding, I think the concerns about potential abuse 
of this policy are justified, but instead of claiming that anycast is too 
hard we really should try to craft the policy such that abuse is not 
practical.

For example, the issue has less to do with an entity not being able to 
justify enough space for their entire enterprise and more to do with the 
fact that they cannot carve a /24 out of their space for fear of having it 
filtered.  What if an org was required to already have an ARIN allocation 
under the normal criteria to qualify for an anycast block?

Alec




From davidu at everydns.net  Fri Aug 12 12:23:36 2005
From: davidu at everydns.net (David Ulevitch)
Date: Fri, 12 Aug 2005 09:23:36 -0700
Subject: [ppml] Proposed Policy: IPv4 Micro-allocations for
	anycast	services
In-Reply-To: <1B6E0B2A5B0D7BC99A4582F6@Alec-Petersons-Computer.local>
References: <20050811173211.10852.qmail@hoster908.com>
	<20050812152940.GO21512@shell01.corp.tellme.com>
	<E472398F-B30C-4E69-B3EE-7497396975FA@everydns.net>
	<1B6E0B2A5B0D7BC99A4582F6@Alec-Petersons-Computer.local>
Message-ID: <2297072B-02CF-4507-B71D-3596C244622A@everydns.net>

On Aug 12, 2005, at 8:47 AM, Alec H. Peterson wrote:

Hi Alec,

> For example, the issue has less to do with an entity not being able  
> to justify enough space for their entire enterprise and more to do  
> with the fact that they cannot carve a /24 out of their space for  
> fear of having it filtered.  What if an org was required to already  
> have an ARIN allocation under the normal criteria to qualify for an  
> anycast block?

I'm not sure that's the right idea.  For example, I can multihome  
just fine with my ISP assigned block but I can't deploy an inter-as  
anycast system with it.  Why should I abuse the micro-allocation or / 
22 end-user multihoming policy just to meet an anycast /24 policy?

Or perhaps I misunderstood you.

Thanks,
David Ulevitch


From ahp at hilander.com  Fri Aug 12 12:26:14 2005
From: ahp at hilander.com (Alec H. Peterson)
Date: Fri, 12 Aug 2005 10:26:14 -0600
Subject: [ppml] Proposed Policy: IPv4 Micro-allocations for
 anycast	services
In-Reply-To: <2297072B-02CF-4507-B71D-3596C244622A@everydns.net>
References: <20050811173211.10852.qmail@hoster908.com>
	<20050812152940.GO21512@shell01.corp.tellme.com>
	<E472398F-B30C-4E69-B3EE-7497396975FA@everydns.net>
	<1B6E0B2A5B0D7BC99A4582F6@Alec-Petersons-Computer.local>
	<2297072B-02CF-4507-B71D-3596C244622A@everydns.net>
Message-ID: <50612EDC39F0EB07E62273F7@Alec-Petersons-Computer.local>

--On August 12, 2005 9:23:36 -0700 David Ulevitch <davidu at everydns.net> 
wrote:

>
> I'm not sure that's the right idea.  For example, I can multihome  just
> fine with my ISP assigned block but I can't deploy an inter-as  anycast
> system with it.  Why should I abuse the micro-allocation or / 22 end-user
> multihoming policy just to meet an anycast /24 policy?

I am not suggesting you abuse anything.  I am trying to make suggestions 
for a policy that will help the largest number of people possible while 
minimizing abuse.

This was just a straw man, not exactly a proposal of anything.

Alec





From John.Sweeting at teleglobe.com  Fri Aug 12 12:39:37 2005
From: John.Sweeting at teleglobe.com (Sweeting, John)
Date: Fri, 12 Aug 2005 12:39:37 -0400
Subject: [ppml] Proposed Policy: IPv4 Micro-allocations for
	anycast	se	rvices
Message-ID: <1797AB680DD0D2118987009027178032183D944B@camtmms01.ad.teleglobe.com>

Hi David,

This proposed policy is now in the 10 day initial review period by the ARIN
AC and we are very interested in what discussion happens on the PPML. At
this point in time we are looking for whether there is support for this
proposal as well as how it could be reworded to be more acceptable. Most of
the ideas thrown out are for the purpose of receiving input that will help
us in determining whether this policy should be forwarded on in the process
or not. Thanks for you participation, we truly appreciate it.

*-----Original Message-----
*From: David Ulevitch [mailto:davidu at everydns.net]
*Sent: 12 ao?t 2005 12:24
*To: Alec H.Peterson
*Cc: ppml at arin.net
*Subject: Re: [ppml] Proposed Policy: IPv4 Micro-allocations for anycast
*services
*
*
*On Aug 12, 2005, at 8:47 AM, Alec H. Peterson wrote:
*
*Hi Alec,
*
*> For example, the issue has less to do with an entity not being able  
*> to justify enough space for their entire enterprise and more to do  
*> with the fact that they cannot carve a /24 out of their space for  
*> fear of having it filtered.  What if an org was required to already  
*> have an ARIN allocation under the normal criteria to qualify for an  
*> anycast block?
*
*I'm not sure that's the right idea.  For example, I can multihome  
*just fine with my ISP assigned block but I can't deploy an inter-as  
*anycast system with it.  Why should I abuse the micro-allocation or / 
*22 end-user multihoming policy just to meet an anycast /24 policy?
*
*Or perhaps I misunderstood you.
*
*Thanks,
*David Ulevitch
*_______________________________________________
*PPML mailing list
*PPML at arin.net
*http://lists.arin.net/mailman/listinfo/ppml
*


From davidu at everydns.net  Fri Aug 12 13:15:53 2005
From: davidu at everydns.net (David Ulevitch)
Date: Fri, 12 Aug 2005 10:15:53 -0700
Subject: [ppml] Proposed Policy: IPv4 Micro-allocations for
	anycast	services
In-Reply-To: <50612EDC39F0EB07E62273F7@Alec-Petersons-Computer.local>
References: <20050811173211.10852.qmail@hoster908.com>
	<20050812152940.GO21512@shell01.corp.tellme.com>
	<E472398F-B30C-4E69-B3EE-7497396975FA@everydns.net>
	<1B6E0B2A5B0D7BC99A4582F6@Alec-Petersons-Computer.local>
	<2297072B-02CF-4507-B71D-3596C244622A@everydns.net>
	<50612EDC39F0EB07E62273F7@Alec-Petersons-Computer.local>
Message-ID: <8EF4B4E3-5BAE-42BB-9C1F-BB3E798AF43A@everydns.net>

On Aug 12, 2005, at 9:26 AM, Alec H. Peterson wrote:

> --On August 12, 2005 9:23:36 -0700 David Ulevitch  
> <davidu at everydns.net> wrote:
>>
>> I'm not sure that's the right idea.  For example, I can multihome   
>> just
>> fine with my ISP assigned block but I can't deploy an inter-as   
>> anycast
>> system with it.  Why should I abuse the micro-allocation or / 22  
>> end-user
>> multihoming policy just to meet an anycast /24 policy?
>>
>
> I am not suggesting you abuse anything.

Of course.

> I am trying to make suggestions for a policy that will help the  
> largest number of people possible while minimizing abuse.

This is what we all want.  And to be clear, I think the policy is  
good and should move forward by the AC.

Specifically because the policy proposal specifically requires two  
discrete multihomed networks.  That the policy "may lead to  
additional improper allocations to organizations that simply wish to  
acquire additional small blocks of space" doesn't seem so serious a  
concern to me as these organizations already have many avenues in  
which to apply for allocations under the existing ARIN policies.  I  
think DW has taken enough care to make this proposed micro-allocation  
policy no easier than any of the others.

I believe and hope that this proposal will open doors to the right  
organizations who have a need to anycast a service on their network.

-David


From owen at delong.com  Fri Aug 12 14:48:02 2005
From: owen at delong.com (Owen DeLong)
Date: Fri, 12 Aug 2005 11:48:02 -0700
Subject: [ppml] Proposed Policy: IPv4 Micro-allocations
 for	anycast	services
In-Reply-To: <2297072B-02CF-4507-B71D-3596C244622A@everydns.net>
References: <20050811173211.10852.qmail@hoster908.com>
	<20050812152940.GO21512@shell01.corp.tellme.com>
	<E472398F-B30C-4E69-B3EE-7497396975FA@everydns.net>
	<1B6E0B2A5B0D7BC99A4582F6@Alec-Petersons-Computer.local>
	<2297072B-02CF-4507-B71D-3596C244622A@everydns.net>
Message-ID: <DA4E4A150479E0255D576E7A@imac-en0.delong.sj.ca.us>

Perhaps requiring the requestor to prove that they qualify for an
independent allocation
under ARIN policies rather than requiring them to actually possess one
would be
a reasonable alternative.  If you are actually multihomed with an ISP
assigned
block and have a legitimate need for multicast, I can't imagine that you
don't
meet the criteria for an ARIN issued /22 whether you need it or not.

Thoughts?

Owen


--On August 12, 2005 9:23:36 AM -0700 David Ulevitch <davidu at everydns.net>
wrote:

> On Aug 12, 2005, at 8:47 AM, Alec H. Peterson wrote:
> 
> Hi Alec,
> 
>> For example, the issue has less to do with an entity not being able  
>> to justify enough space for their entire enterprise and more to do  
>> with the fact that they cannot carve a /24 out of their space for  
>> fear of having it filtered.  What if an org was required to already  
>> have an ARIN allocation under the normal criteria to qualify for an  
>> anycast block?
> 
> I'm not sure that's the right idea.  For example, I can multihome  
> just fine with my ISP assigned block but I can't deploy an inter-as  
> anycast system with it.  Why should I abuse the micro-allocation or / 
> 22 end-user multihoming policy just to meet an anycast /24 policy?
> 
> Or perhaps I misunderstood you.
> 
> Thanks,
> David Ulevitch
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml



-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050812/aa6bf5be/attachment.sig>

From davidu at everydns.net  Fri Aug 12 15:17:56 2005
From: davidu at everydns.net (David Ulevitch)
Date: Fri, 12 Aug 2005 12:17:56 -0700
Subject: [ppml] Proposed Policy: IPv4 Micro-allocations
	for	anycast	services
In-Reply-To: <DA4E4A150479E0255D576E7A@imac-en0.delong.sj.ca.us>
References: <20050811173211.10852.qmail@hoster908.com>
	<20050812152940.GO21512@shell01.corp.tellme.com>
	<E472398F-B30C-4E69-B3EE-7497396975FA@everydns.net>
	<1B6E0B2A5B0D7BC99A4582F6@Alec-Petersons-Computer.local>
	<2297072B-02CF-4507-B71D-3596C244622A@everydns.net>
	<DA4E4A150479E0255D576E7A@imac-en0.delong.sj.ca.us>
Message-ID: <0DBDA4C6-C74E-40CF-9B3C-60F2204589BE@everydns.net>

On Aug 12, 2005, at 11:48 AM, Owen DeLong wrote:

> If you are actually multihomed with an ISP assigned block and have  
> a legitimate need for multicast, I can't imagine that you don't  
> meet the criteria for an ARIN issued /22 whether you need it or not.

Exactly.  If one were required to have an allocation first, it'd be  
easy to get -- justified or not.  In fact, to qualify for the anycast  
allocation as its currently proposed one would already meet the  
requirements for the /22 multihoming requirements.

I don't think anyone is suggesting that the proposal be modified to  
add that.   As Alec pointed out, it was just a comment in discussion,  
not a suggested proposal change.

Thanks,
David Ulevitch


>
>
> --On August 12, 2005 9:23:36 AM -0700 David Ulevitch  
> <davidu at everydns.net>
> wrote:
>
>
>> On Aug 12, 2005, at 8:47 AM, Alec H. Peterson wrote:
>>
>> Hi Alec,
>>
>>
>>> For example, the issue has less to do with an entity not being able
>>> to justify enough space for their entire enterprise and more to do
>>> with the fact that they cannot carve a /24 out of their space for
>>> fear of having it filtered.  What if an org was required to already
>>> have an ARIN allocation under the normal criteria to qualify for an
>>> anycast block?
>>>
>>
>> I'm not sure that's the right idea.  For example, I can multihome
>> just fine with my ISP assigned block but I can't deploy an inter-as
>> anycast system with it.  Why should I abuse the micro-allocation or /
>> 22 end-user multihoming policy just to meet an anycast /24 policy?
>>
>> Or perhaps I misunderstood you.
>>
>> Thanks,
>> David Ulevitch
>> _______________________________________________
>> PPML mailing list
>> PPML at arin.net
>> http://lists.arin.net/mailman/listinfo/ppml
>>
>
>
>
> -- 
> If it wasn't crypto-signed, it probably didn't come from me.
> !DSPAM:42fceeed109732110434741!



From kittu_bbc at yahoo.co.in  Mon Aug 15 06:23:10 2005
From: kittu_bbc at yahoo.co.in (kishore bomma)
Date: Mon, 15 Aug 2005 11:23:10 +0100 (BST)
Subject: [ppml] my email address
Message-ID: <20050815102310.35019.qmail@web8505.mail.in.yahoo.com>

kittu_bbc at yahoo.co.in


	

	
		
____________________________________________________
Send a rakhi to your brother, buy gifts and win
attractive prizes. Log on to http://in.promos.yahoo.com/rakhi/index.html


	

	
		
____________________________________________________
Send a rakhi to your brother, buy gifts and win attractive prizes. Log on to http://in.promos.yahoo.com/rakhi/index.html


From matt.pounsett at cira.ca  Tue Aug 16 17:32:43 2005
From: matt.pounsett at cira.ca (Matt Pounsett)
Date: Tue, 16 Aug 2005 17:32:43 -0400
Subject: [ppml] OT: What's with rwhois?
Message-ID: <DC5D8971-5E28-4372-B430-ED7022722A9F@cira.ca>

While I think this email is probably relevant to a lot of people  
here, I recognize it's far from on-topic for this list.  So, I  
apologize for the noise, and would ask that any responses please be  
directed to me personally, not to the list.


On this list, at public policy meetings, and in private conversation  
I see a lot of frustration directed at rwhois.  Considering all this  
frustration, I'm a but surprised that I don't really see a lot of  
effort being put into easing the situation in the short term.   
There's the work on CRISP/IRIS of course, but I'm not sure I see that  
work producing something that can be widely implemented for a while  
yet.. maybe I'm wrong on that, and I'm certainly willing to have my  
understanding of the state of that work corrected, if that's the case.

What I'm really wondering about, though, is where the bulk of this  
frustration is really directed.  Is it at the rwhois protocol itself,  
or at specific implementations?  I have my own ideas about a lot of  
this of course, but I'd like to take an informal survey, if I can.

Hypothetically speaking (and assuming for the moment that most  
people's problems are with the implementations of rwhoisd and not the  
protocol), if there were a lightweight implementation that didn't, as  
one person put it, "require a time investment from engineering equal  
to a second mortgage," would people use it?  Or are people using  
alternate implementations already?  I know ARIN has an implementation  
out there (though from the looks of the FTP site, it hasn't been  
maintained in a while).  I've seen references in old mailing list  
archives to a RIPE implementation, but their web site and FTP server  
no longer have references to it, that I can see.

If something new were produced, what is the absolute minimum  
functionality (directives and queries) it would have to support for  
you to use it?
What problems with the current implementation you're using would need  
to be fixed?
What sort of data back-end would you want/need to see: the current  
NSI layout, XML files, SQL, or something else?

Or, do I have it all wrong, and people are actually mostly happy with  
rwhois as it stands?

I'm really curious what people's thoughts are on this.
Again, please direct responses to me personally.  If there's  
sufficient interest, I'll summarize back to the list.

Thanks everyone,
   Matt

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

From memsvcs at arin.net  Mon Aug 22 12:37:08 2005
From: memsvcs at arin.net (Member Services)
Date: Mon, 22 Aug 2005 12:37:08 -0400
Subject: [ppml] Deadline for Policy Proposals - August 27
Message-ID: <4309FF34.2030104@arin.net>

The ARIN XVI Public Policy Meeting will take place October 26-27, 2005,
in Los Angeles, California. New policy proposals must be submitted by
23:59 EST, August 27, 2005, in order to be considered by the ARIN
Advisory Council for possible inclusion on the ARIN XVI agenda. This is
in accordance with ARIN's Internet Resource Policy Evaluation Process,
which indicates that proposed policies must be submitted at least 60
days prior to the meeting.

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

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

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

Regards,

Member Services Department
American Registry for Internet Numbers










From memsvcs at arin.net  Mon Aug 22 12:46:20 2005
From: memsvcs at arin.net (Member Services)
Date: Mon, 22 Aug 2005 12:46:20 -0400
Subject: [ppml] Policy Proposal 2005-6: Micro-allocations for Anycast
	Services
Message-ID: <430A015C.10104@arin.net>

On August 18, 2005, the ARIN Advisory Council (AC) concluded its review
of proposed policy 'Micro-allocations for Anycast Services' and agreed
to forward it as a formal proposal for discussion by the community. This
proposal is designated 2005-6: Micro-allocations for Anycast Services.
The policy proposal text is below and can be found at:
http://www.arin.net/policy/proposals/2005_6.html

All persons in the community are encouraged to discuss Policy Proposal
2005-6 in the weeks leading to the ARIN Public Policy Meeting in Los
Angeles, CA, scheduled for October 26-27. Both the discussion on the
PPML and at the public policy meeting will be used to determine the
community consensus regarding this policy proposal.

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

ARIN's Policy Proposal Archive can be found at:
http://www.arin.net/policy/proposal_archive.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)

### * ###

Policy Proposal 2005-6: Micro-allocations for Anycast Services

Author: David Williamson

Policy term: permanent

Policy statement: In the NRPM IPv4 section, renumber 4.4 to 4.4.1, and add:

4.4.2 Micro-allocations for anycast services - ARIN will make
micro-allocations to organizations wishing to deploy anycast based
services, provided they meet the following criteria:

     * All of the criteria normally required to receive IPv4 space, AND
     * The organization must have multiple (at least two) discrete
multi-homed networks.
     * The organization must identify which networks, ASNs, or sites
will host the new service.
     * The organization must provide a description of the anycast service.

Micro-allocations for anycast services will be no longer than a /24.
These allocations will be made out of blocks reserved for
micro-allocation purposes. ISPs and other organizations receiving these
micro-allocations will be charged under the ISP fee schedule, while
end-users will be charged under the fee schedule for end-users.

Rationale:

There are an increasing number of anycast-based applications being
offered by service providers and other organizations. Indeed, many basic
infrastructure services (like the DNS root servers) are already anycast
based. (See RFC 1546 for an authoritative discussion of anycast services.)

Deployment of new services is hampered, however, by current IPv4
allocation policies. For organizations that do not have legacy IP space,
justifying a /22 to serve a handful of addresses is effectively
impossible. As many ISPs also filter routes longer than /22, it is
impractical to use a longer mask for any netblock that is utilized for
an anycast service. This situation is also generally unfavorable to
younger organizations, while giving older organizations that do have a
surplus of legacy space a competitive advantage.

In light of this, some organizations may simply lie about their
addressing needs in order to convince an RIR that a /22 is required,
when a much smaller network would suffice. This is not a behavior that
should be encouraged by policy.

The obvious answer is that a micro-allocation scheme needs to be created
to allow organizations deploying anycast services to acquire a network
of more appropriate size.

It is also clear that a micro-allocation policy that makes it easier for
organizations to acquire small netblocks may lead to additional improper
allocations to organizations that simply wish to acquire additional
small blocks of space. This policy proposal attempts to address that by
requiring more stringent requirements for such allocations.

Timetable for implementation: immediate










From memsvcs at arin.net  Wed Aug 24 10:41:11 2005
From: memsvcs at arin.net (Member Services)
Date: Wed, 24 Aug 2005 10:41:11 -0400
Subject: [ppml] Proposed Policy: Rationalize Multi-Homing Definition and
	Requirement
Message-ID: <430C8707.9010201@arin.net>

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

The ARIN Advisory Council (AC) will review the proposal and within ten
working days may decide to:
1)  Support the proposal as is,
2)  Work with the author to clarify, divide or combine one or more
policy proposals, or
3)  Not support the policy proposal.

If the AC supports the proposal or reaches an agreement to work with the
author, then the proposal will be posted as a formal policy proposal to
the Public Policy Mailing List and it will be presented at the Public
Policy Meeting. If the AC does not support the proposal, then the author
may elect to use the petition process to advance the proposal. If the
author elects not to petition or the petition fails, then the proposed
policy will be considered closed.

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

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)

### * ###

Policy Proposal Name: Rationalize Multi-Homing Definition and Requirement

Author: Robert Seastrom

Policy term: permanent

Policy statement: In existing policy 4.2.2.2, replace the phrase
      "multi-homed organizations must:" with the phrase "organizations
      applying under the multi-homed policy must:"  In existing policy
      4.2.2.2.2, replace "Provide information showing that the requested
      IP address space will be utilized within three months." with
      "Provide information showing that the requested IP address space
      will be utilized within three months and demonstrating an intent to
      announce the requested space in a multi-homed fasion."

Rationale: Presently, organizations wishing to apply for their first
      address space under the multi-homed policy must demonstrate that
      they have ALREADY announced a DIFFERENT address block via
      multi-homing, while simultaneously promising to renumber out of
      that same block. This creates needless make-work for ISPs which are
      planning to multi-home, related to old resources which they're
      already trying to get out of.  Likewise, it creates needless work
      for both of their upstream providers, who have to temporarily
      announce a prefix which DOESN'T NEED to be multi-homed, solely to
      demonstrate to ARIN analysts that the applying ISP is multi-homed.
      However, this same criterion can be demonstrated just as
      effectively by the applying ISP showing the analyst contracts with
      multiple ISPs under which the newly-applied-for block WILL BE
      multi-homed, and this more accurately reflects the intent of the
      original policy, while removing needless make-work at a time when
      the applicant is surely already quite busy with the real
      requirements of their change-over.

Timetable for implementation: immediate





From owen at delong.com  Wed Aug 24 14:42:47 2005
From: owen at delong.com (Owen DeLong)
Date: Wed, 24 Aug 2005 11:42:47 -0700
Subject: [ppml] Proposed Policy: Rationalize Multi-Homing Definition
 and	Requirement
In-Reply-To: <430C8707.9010201@arin.net>
References: <430C8707.9010201@arin.net>
Message-ID: <ECF6DB106BB969E42027A47B@imac-en0.delong.sj.ca.us>

I support this policy.  To me, it is a reasonable clarification of the
intent
of existing policy.

Owen

>### * ###
> 
> Policy Proposal Name: Rationalize Multi-Homing Definition and Requirement
> 
> Author: Robert Seastrom
> 
> Policy term: permanent
> 
> Policy statement: In existing policy 4.2.2.2, replace the phrase
>       "multi-homed organizations must:" with the phrase "organizations
>       applying under the multi-homed policy must:"  In existing policy
>       4.2.2.2.2, replace "Provide information showing that the requested
>       IP address space will be utilized within three months." with
>       "Provide information showing that the requested IP address space
>       will be utilized within three months and demonstrating an intent to
>       announce the requested space in a multi-homed fasion."
> 
> Rationale: Presently, organizations wishing to apply for their first
>       address space under the multi-homed policy must demonstrate that
>       they have ALREADY announced a DIFFERENT address block via
>       multi-homing, while simultaneously promising to renumber out of
>       that same block. This creates needless make-work for ISPs which are
>       planning to multi-home, related to old resources which they're
>       already trying to get out of.  Likewise, it creates needless work
>       for both of their upstream providers, who have to temporarily
>       announce a prefix which DOESN'T NEED to be multi-homed, solely to
>       demonstrate to ARIN analysts that the applying ISP is multi-homed.
>       However, this same criterion can be demonstrated just as
>       effectively by the applying ISP showing the analyst contracts with
>       multiple ISPs under which the newly-applied-for block WILL BE
>       multi-homed, and this more accurately reflects the intent of the
>       original policy, while removing needless make-work at a time when
>       the applicant is surely already quite busy with the real
>       requirements of their change-over.
> 
> Timetable for implementation: immediate
> 
> 
> 
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml



-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050824/ac10bc85/attachment.sig>

From josmon at rigozsaurus.com  Wed Aug 24 14:38:26 2005
From: josmon at rigozsaurus.com (John Osmon)
Date: Wed, 24 Aug 2005 12:38:26 -0600
Subject: [ppml] Proposed Policy: Rationalize Multi-Homing Definition and
	Requirement
In-Reply-To: <430C8707.9010201@arin.net>
References: <430C8707.9010201@arin.net>
Message-ID: <20050824183825.GA15839@jeeves.rigozsaurus.com>

On Wed, Aug 24, 2005 at 10:41:11AM -0400, Member Services wrote:
[...]
> ### * ###
> 
> Policy Proposal Name: Rationalize Multi-Homing Definition and Requirement
> 
> Author: Robert Seastrom
> 
> Policy term: permanent
[...]

I support the intent of this policy.

-- 
John


From memsvcs at arin.net  Mon Aug 29 10:17:11 2005
From: memsvcs at arin.net (Member Services)
Date: Mon, 29 Aug 2005 10:17:11 -0400
Subject: [ppml] Proposed Policy: IPv6 Direct assignments to end sites
Message-ID: <431318E7.80306@arin.net>

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

The ARIN Advisory Council (AC) will review the proposal and within ten
working days may decide to:
1)  Support the proposal as is,
2)  Work with the author to clarify, divide or combine one or more
policy proposals, or
3)  Not support the policy proposal.

If the AC supports the proposal or reaches an agreement to work with the
author, then the proposal will be posted as a formal policy proposal to
the Public Policy Mailing List and it will be presented at the Public
Policy Meeting. If the AC does not support the proposal, then the author
may elect to use the petition process to advance the proposal. If the
author elects not to petition or the petition fails, then the proposed
policy will be considered closed.

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

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)

### * ###

Policy Proposal Name: IPv6 Direct assignments to end sites

Author: Kevin Loch

Policy Statement:

Changes to NRPM section 6:

add new section 6.5.8:

6.5.8. Direct assignments to end sites.

         6.5.8.1. To qualify for a direct end site assignment, an
                  organization must:

                  a) not be an LIR;

                  b) be an end site;

                  c) be currently multi-homed using IPv6 to two or more
                     separate LIR's. native connections or statically
                     configured tunnels may be used to satisfy this
                     requirement.

                  d) The prefix(es) used by the end site to demonstrate
                     multihoming must be visible in the ARIN whois
                     databse or via rwhois as being assigned to the
                     requesting organization.

         6.5.8.2. Direct assignment size to end sites

                  Organizations that meet the direct end site assignment
                  criteria are eligible to receive a direct assignment of
                  /48

         6.5.8.3. Subsequent direct assignments to end sites

                  Only one direct assignment may be made to an end site
                  organization.

                  End sites that require more than 65536 subnets should
                  request space from an LIR or consider becoming
                  an LIR.

         6.5.8.4. Migration from end site to LIR

                  A direct end site assignment shall not
                  disqualify an organization from becoming an LIR and
                  ceasing to be an end site if it otherwise meets the
                  requirements for an initial allocation.

                  Organizations receiving an LIR allocation must
                  renumber into that allocation and return any direct
                  assignments within 1 year.  Micro allocations made
                  under section 6.10 are not subject to this requirement.

                  An LIR allocation shall disqualify an organization from
                  receiving a direct end site assignment unless it
                  agrees to return all LIR allocations within 1 year.
                  Micro allocations made under section 6.10 are not
                  subject to this requirement.

Rationale:

        The lack of provider independent direct assignments is a
        significant impediment to adoption of IPv6 by enterprises and
        large content sites. This policy proposal defines clear
        verifiable requirements for receiving a direct assignment.

        Current IPv6 multi-homing was chosen as the key requirement for
        the following reasons:

        a) it is reasonable to expect that those reqesting provider
           independence would be connecting to two or more providers.

        b) the requirement of demonstrating current multi-homing will
           promote active deployment of IPv6 by those seeking direct
           assignments.

        It is possible that future technology developments will render
        this policy unnecessary. At this time there are no viable
        alternatives for IPv6 provider independence, other than becoming
        an LIR.

        It is likely that this will help conserve IPv6 address space
        as most organizations requiring provider independence could
        easily qualify for an LIR allocation under current policy.
        Allowing them to apply for the more appropriate /48 is
        responsible resource management.

        This policy can easily be adapted to increase requirements for
        direct assignments if future conditions warrant.  For example,
        the multihoming demonstration requirement could be increased
        to three or four separate LIR's.  Additional verification
        of active current multihoming could be used.  Or, as native
        connectivity becomes widespread the option of tunnel based
        connections for justification could be removed.

        It is extremely unlikely that this will result in a "land rush"
        of direct assignments.  The requirements in this policy require
        more effort than the current requirements for a /32.
        Alternatively, a large number of applications would be a
        good sign of sincere IPv6 deployment due to the requirement
        to be currently multihomed.

Timetable for implementation: Immediately







From memsvcs at arin.net  Mon Aug 29 10:17:29 2005
From: memsvcs at arin.net (Member Services)
Date: Mon, 29 Aug 2005 10:17:29 -0400
Subject: [ppml] Proposed Policy: Proposal to amend ARIN IPv6 assignment and
 utilisation requirement
Message-ID: <431318F9.8060604@arin.net>

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

The ARIN Advisory Council (AC) will review the proposal and within ten
working days may decide to:
1)  Support the proposal as is,
2)  Work with the author to clarify, divide or combine one or more
policy proposals, or
3)  Not support the policy proposal.

If the AC supports the proposal or reaches an agreement to work with the
author, then the proposal will be posted as a formal policy proposal to
the Public Policy Mailing List and it will be presented at the Public
Policy Meeting. If the AC does not support the proposal, then the author
may elect to use the petition process to advance the proposal. If the
author elects not to petition or the petition fails, then the proposed
policy will be considered closed.

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

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)

### * ###

Policy Proposal Name: Proposal to amend ARIN IPv6 assignment and
utilisation requirement (Section 6 of ARIN Number Resource Policy Manual)

Author: Thomas Narten and Lea Roberts

Policy term: permanent

Policy statement:

It is proposed to make the following changes to the existing ARIN IPv6
policy:

1. Define an additional end site assignment size of /56. This /56
assignment should be considered the general case, intended for small
office, household, and personal networks, and other small and
medium-sized deployments where the number of potential subnets exceeds
1, but is not expected to exceed 256.

2. Amend the existing policy regarding /48 end-site assignments to refer
specifically to assignments to large enterprise and corporate end-site
environments where there is a requirement for more than 255 subnets at
the end site.

3. Amend the evaluation threshold calculation to be based on a default
tnd site assignment size of a /56. Further end-site assignment
information should be provided to ARIN in order to use a different
average end-site assignment size for HD-ratio calculation purposes.

Rationale:

The key benefit of IPv6 is its large address space, and a fundamental
assumption motivating its adoption is that with IPv6, sufficient address
space will always be available to ensure that users can obtain sufficent
public address space for their needs.  Projections for IPv6 address
consumption over the next 50-100 years indicate that there are scenarios
(depending on one's assumptions) in which a signficant percentage of the
total IPv6 address space could be handed out, raising the possibility
that address allocation policies will then need to be revised to become
significantly more conservative to ensure that the IPv6 address space
does not become exhausted. Given the IPv4 experience, in which early
adopters were able to acquire large amounts of address space easily, but
later adopters were not, and the resultant problems this has caused, it
would be preferable to take steps now to signficantly reduce the
likelyhood of ever needing to make such a change, especially if changes
can be made with minimal impact.

The RIR communities adopted address allocation policies in 2002 in which
the default assignment to end sites was assumed to be a /48 in many
cases. For SOHO users (e.g., home users and small businesses), being
given enough address space to number 65,536 subnets seems excessive
given their anticipated needs. Changing the default assignment size to a
/56 allows for numbering 256 subnets, still a large number. Making such
a change would save roughly two orders of magnitude of address space.
That is, for any projection made assuming a /48 assignment, assigning
/56s instead would result in roughly 100 times less total consumption.

The goal of this policy proposal is not to make it impossible for end
sites to obtain a /48. Rather, it is intended to make the default
assignment size a /56 in the vast number of cases where a /48 seems
profligate. In those cases where the end site can argue that it has a
need for more than 256 subnets, a /48 should be given out.

Background information:

"Issues Related to the Management of IPv6 Address Space", by Thomas Narten.
http://www.ietf.org/internet-drafts/draft-narten-iana-rir-ipv6-considerations-00.txt

Similar policy proposal submitted to APNIC (includes detailed background
and pointers to more background information than is included here).
http://www.apnic.net/docs/policy/discussions/prop-031-v001.txt

State of related discussion in other RIRs: See section "Situation in
other RIRs" in
http://www.apnic.net/docs/policy/discussions/prop-031-v001.txt

IETF revisitation of RFC 3177 "IAB/IESG Recommendations on IPv6 Address
Allocations to Sites", the document in which the case for assigning /48s
was made.
http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary-00.txt
(note: this document was adopted as a WG item by the IPv6 WG at IETF
63 in August.)

Timetable for implementation: Immediate (upon approval)




From andy at hxr.us  Mon Aug 29 12:15:37 2005
From: andy at hxr.us (Andrew Newton)
Date: Mon, 29 Aug 2005 12:15:37 -0400
Subject: [ppml] What's with CRISP/IRIS? ( was Re: OT: What's with rwhois? )
In-Reply-To: <DC5D8971-5E28-4372-B430-ED7022722A9F@cira.ca>
References: <DC5D8971-5E28-4372-B430-ED7022722A9F@cira.ca>
Message-ID: <83A38213-6F26-4D78-9E4F-A2032B8A280D@hxr.us>


On Aug 16, 2005, at 5:32 PM, Matt Pounsett wrote:

> There's the work on CRISP/IRIS of course, but I'm not sure I see  
> that work producing something that can be widely implemented for a  
> while yet.. maybe I'm wrong on that, and I'm certainly willing to  
> have my understanding of the state of that work corrected, if  
> that's the case.

Matt,

Here's an update of what is going on in this space.

 From the standardization point of view:

- the AREG draft went through a number of revisions and finally  
passed working group last call at revision -12.  It is in the hands  
of the IESG now.

- two transfer protocols have been in the works to replace BEEP.   
These are LWZ (UDP) and XPC (TCP).  Both should be much, much easier  
to implement than BEEP.

Of course, drafts and RFCs are not much use by themselves, so from  
the implementation point of view:

- At RIPE 48 last year, I demoed IRISServ and Pimmit (a client)  
running AREG -06.  I've been waiting for the AREG spec to settle down  
before updating them to the latest.  I have been intending to demo  
this software at a NANOG meeting, but the timing never seems to work  
out.

- At this past IETF, I had discussions with the RIPE NCC engineers  
regarding re-use of either IRISServ or Flowerbed (both are servers,  
they just have different architectures) for their systems.  Their  
long-term strategy is to build something complete from the ground up,  
but they wanted something they could use in the near-term as a  
prototype.

- Also at this past IETF, I spent a couple of hours with the LACNIC  
engineers doing some interoperability testing.  I just spent the last  
week putting my code in a more useable state to further that work.

Regarding the main thrust of your message about back-ends and formats  
and so forth, I understand your concern about the time-investment to  
get a small server up and running.  That was the motivation for the  
creation of Flowerbed (as it turns out, IRISServ with HSQLDB is just  
as easy).  I'm not really sure that focusing on the back-end  
technology is all that important, as it seems the data entry is far  
more of problem.  Doing hand-entry of data in SQL, XML, or whatever  
has got to be grueling and time consuming.  I've been thinking about  
a simple wizard like application to generate the XML, but I just  
haven't had time to explore it yet.

-andy


From owen at delong.com  Mon Aug 29 16:09:49 2005
From: owen at delong.com (Owen DeLong)
Date: Mon, 29 Aug 2005 13:09:49 -0700
Subject: [ppml] Proposed Policy: IPv6 Direct assignments to end sites
In-Reply-To: <431318E7.80306@arin.net>
References: <431318E7.80306@arin.net>
Message-ID: <8B41C9964C2DACBF5B94554D@imac-en0.delong.sj.ca.us>

1.	This policy is in line with my original intent of 2005-1.
2.	I support this policy, generally.
3.	I believe that instead of specifically exempting 6.10, we should state
	that the only direct assignments limited by this policy are those made
	under this policy in section 6.8.

	(There may be, for example, an anycast microassignment policy or such in
	the future which should also be exmpted)

4.	If the advisory council and Mr. Loch are amenable, I am not opposed to
	merging 2005-1 and this policy proposal into a single proposal to simplify
	things for everyone.

Owen
>### * ###
> 
> Policy Proposal Name: IPv6 Direct assignments to end sites
> 
> Author: Kevin Loch
> 
> Policy Statement:
> 
> Changes to NRPM section 6:
> 
> add new section 6.5.8:
> 
> 6.5.8. Direct assignments to end sites.
...

-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050829/d26053e6/attachment.sig>

From Lee.Howard at stanleyassociates.com  Mon Aug 29 17:02:58 2005
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Mon, 29 Aug 2005 17:02:58 -0400
Subject: [ppml] Proposed Policy: IPv6 Direct assignments to end sites
Message-ID: <3F05EE24A82C0B42811178EFB8820C3F465050@AX-S-EX-1.stanleyassociates.com>


> ### * ###
> Policy Proposal Name: IPv6 Direct assignments to end sites
> Author: Kevin Loch
> Policy Statement:
> Changes to NRPM section 6:
> add new section 6.5.8:
> 6.5.8. Direct assignments to end sites.
>          6.5.8.1. To qualify for a direct end site assignment, an
>                   organization must:
>                   a) not be an LIR;

Have we agreed that in IPv6 we'll use the term "LIR"?  We inherited
this from RIPE and APNIC, and accepted it so we could have a 
harmonized IPv6 policy, but most IPv4 policies refer to "ISPs."
That's interesting, since "ISP" is not defined in the NRPM, but
"LIR" is (even in the IPv4 section).

>          6.5.8.3. Subsequent direct assignments to end sites
>                   Only one direct assignment may be made to 
> 			an end site organization.
> 
>                   End sites that require more than 65536 
> subnets should request space from an LIR or consider becoming
>                   an LIR.

So NRPM 6.2.4, would define "the users of the network services that
it [the LIR] provides" as intra-company departments, to whom it
would have to SWIP or equivalent?  Is that unusual?  


>                   Organizations receiving an LIR allocation must
>                   renumber into that allocation and return any direct
>                   assignments within 1 year.  Micro allocations made
>                   under section 6.10 are not subject to this 
> requirement.
> 
>                   An LIR allocation shall disqualify an 
> organization from
>                   receiving a direct end site assignment unless it
>                   agrees to return all LIR allocations within 1 year.
>                   Micro allocations made under section 6.10 are not
>                   subject to this requirement.

Do we have any teeth to the "return within 1 year" policy?  In the
past, the enforcement has been, "or you won't get any more address
space," which isn't much incentive in IPv6.


> Rationale:
> 
>         The lack of provider independent direct assignments is a
>         significant impediment to adoption of IPv6 by enterprises and
>         large content sites. 

In what way does the lack of PI assignments inhibit enterprise adoption?
Is multi-homing harder, is it less reliable, or is it fear of commitment
to an ISP?

For large content sites (web hosting providers?), is there any guidance 
on how they should assign IPv6 addresses?  Should each web server get a 
/48, or a /64, or a /128?  Or does each server get a /64 (per interface)

and each virtual host gets a /128?



> This policy proposal defines clear
>         verifiable requirements for receiving a direct assignment.
> 
>         Current IPv6 multi-homing was chosen as the key 
> requirement for the following reasons:
> 
>         a) it is reasonable to expect that those reqesting provider
>            independence would be connecting to two or more providers.
> 
>         b) the requirement of demonstrating current multi-homing will
>            promote active deployment of IPv6 by those seeking direct
>            assignments.
> 
>         It is possible that future technology developments will render
>         this policy unnecessary. At this time there are no viable
>         alternatives for IPv6 provider independence, other 
> than becoming an LIR.

I admit I haven't been following shim6, but would that be one of the
future technology developments that would render this policy
unnecessary?
If endpoint and network identifiers are abstracted, then provider
independent space actually muddies the routing table.

At this time, multi-homing in IPv6 isn't fully baked.  Does this 
proposed policy help?


> 
>         It is likely that this will help conserve IPv6 address space
>         as most organizations requiring provider independence could
>         easily qualify for an LIR allocation under current policy.
>         Allowing them to apply for the more appropriate /48 is
>         responsible resource management.

If most organizations could easily qualify for an LIR allocation, then
how is the lack of this proposed policy hindering adoption?

 
>         This policy can easily be adapted to increase requirements for
>         direct assignments if future conditions warrant.  For example,
>         the multihoming demonstration requirement could be increased
>         to three or four separate LIR's.  Additional verification
>         of active current multihoming could be used.  Or, as native
>         connectivity becomes widespread the option of tunnel based
>         connections for justification could be removed.
> 
>         It is extremely unlikely that this will result in a 
> "land rush"
>         of direct assignments.  The requirements in this 
> policy require
>         more effort than the current requirements for a /32.

If most organizations qualify as an LIR, and it's harder to qualify as
an end site, how will this proposal promote adoption?

Lee



From tme at multicasttech.com  Mon Aug 29 20:03:48 2005
From: tme at multicasttech.com (Marshall Eubanks)
Date: Mon, 29 Aug 2005 20:03:48 -0400
Subject: [ppml] Proposed Policy: IPv6 Direct assignments to end sites
In-Reply-To: <8B41C9964C2DACBF5B94554D@imac-en0.delong.sj.ca.us>
References: <431318E7.80306@arin.net>
	<8B41C9964C2DACBF5B94554D@imac-en0.delong.sj.ca.us>
Message-ID: <b2a34feb5c50821b77fbaf0c10544c7b@multicasttech.com>

I support both this policy and 2005-1, and would also suggest that they 
be
merged.

Regards
Marshall Eubanks

On Aug 29, 2005, at 4:09 PM, Owen DeLong wrote:

> 1.	This policy is in line with my original intent of 2005-1.
> 2.	I support this policy, generally.
> 3.	I believe that instead of specifically exempting 6.10, we should 
> state
> 	that the only direct assignments limited by this policy are those made
> 	under this policy in section 6.8.
>
> 	(There may be, for example, an anycast microassignment policy or such 
> in
> 	the future which should also be exmpted)
>
> 4.	If the advisory council and Mr. Loch are amenable, I am not opposed 
> to
> 	merging 2005-1 and this policy proposal into a single proposal to 
> simplify
> 	things for everyone.
>
> Owen
>> ### * ###
>>
>> Policy Proposal Name: IPv6 Direct assignments to end sites
>>
>> Author: Kevin Loch
>>
>> Policy Statement:
>>
>> Changes to NRPM section 6:
>>
>> add new section 6.5.8:
>>
>> 6.5.8. Direct assignments to end sites.
> ...
>
> -- 
> If it wasn't crypto-signed, it probably didn't come from me.
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
>



From marcelo at it.uc3m.es  Tue Aug 30 08:56:40 2005
From: marcelo at it.uc3m.es (marcelo bagnulo braun)
Date: Tue, 30 Aug 2005 14:56:40 +0200
Subject: [ppml] Proposed Policy: IPv6 Direct assignments to end sites
In-Reply-To: <431318E7.80306@arin.net>
References: <431318E7.80306@arin.net>
Message-ID: <8ce3063b54f1def4353016593ccdb777@it.uc3m.es>

Hi,

El 29/08/2005, a las 16:17, Member Services escribi?:

>
...
> 6.5.8. Direct assignments to end sites.
>
>          6.5.8.1. To qualify for a direct end site assignment, an
>                   organization must:
>
>                   a) not be an LIR;
>
>                   b) be an end site;
>
>                   c) be currently multi-homed using IPv6 to two or more
>                      separate LIR's. native connections or statically
>                      configured tunnels may be used to satisfy this
>                      requirement.
>

Having two tunnels configured with different tunnels providers through 
a single dsl line would fulfill this requirement?
I guess this would allow any IPv6 fan to have their own PI prefix 
fairly easily, so i would argue for stronger requirements than this...
At least to be really multihomed, i.e. two different ISPs providing 
different physical connectivity to the end site, similar to IPv4, i 
guess

However, i would even argue to reserve this type of PI based 
multihoming only "big" sites (the problem here would be to define what 
a big site is i am afraid)

regards, marcelo


>                   d) The prefix(es) used by the end site to demonstrate
>                      multihoming must be visible in the ARIN whois
>                      databse or via rwhois as being assigned to the
>                      requesting organization.
>
>          6.5.8.2. Direct assignment size to end sites
>
>                   Organizations that meet the direct end site 
> assignment
>                   criteria are eligible to receive a direct assignment 
> of
>                   /48
>
>          6.5.8.3. Subsequent direct assignments to end sites
>
>                   Only one direct assignment may be made to an end site
>                   organization.
>
>                   End sites that require more than 65536 subnets should
>                   request space from an LIR or consider becoming
>                   an LIR.
>
>          6.5.8.4. Migration from end site to LIR
>
>                   A direct end site assignment shall not
>                   disqualify an organization from becoming an LIR and
>                   ceasing to be an end site if it otherwise meets the
>                   requirements for an initial allocation.
>
>                   Organizations receiving an LIR allocation must
>                   renumber into that allocation and return any direct
>                   assignments within 1 year.  Micro allocations made
>                   under section 6.10 are not subject to this 
> requirement.
>
>                   An LIR allocation shall disqualify an organization 
> from
>                   receiving a direct end site assignment unless it
>                   agrees to return all LIR allocations within 1 year.
>                   Micro allocations made under section 6.10 are not
>                   subject to this requirement.
>
> Rationale:
>
>         The lack of provider independent direct assignments is a
>         significant impediment to adoption of IPv6 by enterprises and
>         large content sites. This policy proposal defines clear
>         verifiable requirements for receiving a direct assignment.
>
>         Current IPv6 multi-homing was chosen as the key requirement for
>         the following reasons:
>
>         a) it is reasonable to expect that those reqesting provider
>            independence would be connecting to two or more providers.
>
>         b) the requirement of demonstrating current multi-homing will
>            promote active deployment of IPv6 by those seeking direct
>            assignments.
>
>         It is possible that future technology developments will render
>         this policy unnecessary. At this time there are no viable
>         alternatives for IPv6 provider independence, other than 
> becoming
>         an LIR.
>
>         It is likely that this will help conserve IPv6 address space
>         as most organizations requiring provider independence could
>         easily qualify for an LIR allocation under current policy.
>         Allowing them to apply for the more appropriate /48 is
>         responsible resource management.
>
>         This policy can easily be adapted to increase requirements for
>         direct assignments if future conditions warrant.  For example,
>         the multihoming demonstration requirement could be increased
>         to three or four separate LIR's.  Additional verification
>         of active current multihoming could be used.  Or, as native
>         connectivity becomes widespread the option of tunnel based
>         connections for justification could be removed.
>
>         It is extremely unlikely that this will result in a "land rush"
>         of direct assignments.  The requirements in this policy require
>         more effort than the current requirements for a /32.
>         Alternatively, a large number of applications would be a
>         good sign of sincere IPv6 deployment due to the requirement
>         to be currently multihomed.
>
> Timetable for implementation: Immediately
>
>
>
>
>
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
>



From kurtis at kurtis.pp.se  Tue Aug 30 06:46:15 2005
From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist)
Date: Tue, 30 Aug 2005 12:46:15 +0200
Subject: [ppml] Proposed Policy: IPv6 Direct assignments to end sites
In-Reply-To: <431318E7.80306@arin.net>
References: <431318E7.80306@arin.net>
Message-ID: <1E0D982B-11F2-4D38-9DE5-BEA4A79350F2@kurtis.pp.se>


On 29 aug 2005, at 16.17, Member Services wrote:

[Proposal deleted]

You might want to note that there is no guarantee that this  
assignment will actually get routed. Just as in some RIR regions you  
will get less than a /24 v4 space as PI space, and you won't get very  
far...

>         6.5.8.1. To qualify for a direct end site assignment, an
>                   organization must:
>
>                   a) not be an LIR;
>
>                   b) be an end site;
>
>                   c) be currently multi-homed using IPv6 to two or  
> more
>                      separate LIR's. native connections or statically
>                      configured tunnels may be used to satisfy this
>                      requirement.


What's a "statically configured tunnel" ? Does MPLS count? I would  
not call that a statically configured tunnel. So most L2VPN services  
are out of the question...

- kurtis -


From andrew.dul at quark.net  Tue Aug 30 10:11:19 2005
From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=)
Date: Tue, 30 Aug 2005 14:11:19 +0000
Subject: [ppml] Proposed Policy: IPv6 Direct assignments to end sites
Message-ID: <20050830141119.13992.qmail@hoster908.com>

-------Original Message-------
> From: marcelo bagnulo braun <marcelo at it.uc3m.es>
> Subject: Re: [ppml] Proposed Policy: IPv6 Direct assignments to end sites
> Sent: 30 Aug '05 04:56
> 
>  Hi,
>  
>  El 29/08/2005, a las 16:17, Member Services escribi?:
>  
>  >
>  ...
>  > 6.5.8. Direct assignments to end sites.
>  >
>  >          6.5.8.1. To qualify for a direct end site assignment, an
>  >                   organization must:
>  >
>  >                   a) not be an LIR;
>  >
>  >                   b) be an end site;
>  >
>  >                   c) be currently multi-homed using IPv6 to two or more
>  >                      separate LIR's. native connections or statically
>  >                      configured tunnels may be used to satisfy this
>  >                      requirement.
>  >
>  
>  Having two tunnels configured with different tunnels providers through
>  a single dsl line would fulfill this requirement?
>  I guess this would allow any IPv6 fan to have their own PI prefix
>  fairly easily, so i would argue for stronger requirements than this...
>  At least to be really multihomed, i.e. two different ISPs providing
>  different physical connectivity to the end site, similar to IPv4, i
>  guess
>  
>  However, i would even argue to reserve this type of PI based
>  multihoming only "big" sites (the problem here would be to define what
>  a big site is i am afraid)
>  

What would people think about making one of the requirements to have an existing v4 end-site allocation from ARIN?  

Andrew


From memsvcs at arin.net  Tue Aug 30 11:34:08 2005
From: memsvcs at arin.net (Member Services)
Date: Tue, 30 Aug 2005 11:34:08 -0400
Subject: [ppml] ARIN XVI and NANOG 35 Registration Now Open
Message-ID: <20050830153402.A26351FF2E@mercury.arin.net>

NANOG and ARIN are pleased to invite you to attend their back-to-back meetings this fall in Los Angeles, California. NANOG 35 will be held from October 23-25, 2005, and ARIN XVI will immediately follow, taking place from October 26-28. The meetings will be held at the Hilton Los Angeles/Universal City.

Previous back-to-back meetings have proven to be excellent opportunities for involvement in both organizations and we look forward to even greater success and participation this fall.

Meeting Registration and Hotel Information:

You may register for the meeting by visiting the ARIN XVI home page, available at:

http://www.arin.net/ARIN-XVI/

Registration and additional information for NANOG 35 is available at:

http://www.nanog.org

Information about the hotel, travel, and how to make a room reservation is available at:

http://www.arin.net/ARIN-XVI/hotel.html

As rooms are limited, make sure to reserve your hotel room now.

ARIN XVI Overview

    * Sunday, Oct. 23 - NANOG and ARIN are excited to jointly offer "Getting Started with IPv6," a workshop focusing on providing hands-on experience using IPv6

    * Tuesday, Oct. 25 - From 1:00PM - 1:30PM, a "Getting to Know ARIN" session during the NANOG lunch break, evening ARIN Tutorial and ARIN
      Birds-of-a-Feather session, evening ARIN Tutorial and ARIN Birds-of-a-Feather session

    * Wednesday, Oct. 26 - ARIN Public Policy Meeting, Day 1, evening ARIN Social

    * Thursday, Oct. 27 - ARIN Public Policy Meeting, Day 2

    * Friday, Oct. 28 - ARIN Members Meeting (open to all ARIN XVI attendees)

Additional agenda details and more information about ARIN XVI and NANOG 35 will be posted to our websites as we get closer to the meetings, so check back often!

Regards,

Member Services Department
American Registry for Internet Numbers




From kloch at hotnic.net  Tue Aug 30 12:34:16 2005
From: kloch at hotnic.net (Kevin Loch)
Date: Tue, 30 Aug 2005 12:34:16 -0400
Subject: [ppml] Proposed Policy: IPv6 Direct assignments to end sites
In-Reply-To: <8B41C9964C2DACBF5B94554D@imac-en0.delong.sj.ca.us>
References: <431318E7.80306@arin.net>
	<8B41C9964C2DACBF5B94554D@imac-en0.delong.sj.ca.us>
Message-ID: <43148A88.6010204@hotnic.net>

Owen DeLong wrote:
> 4.	If the advisory council and Mr. Loch are amenable, I am not opposed to
> 	merging 2005-1 and this policy proposal into a single proposal to simplify
> 	things for everyone.

I am not opposed to merging it with 2005-1 if it would simplify
things.  I'll leave it up to the AC to decide which is best.

- Kevin


From kloch at hotnic.net  Tue Aug 30 13:00:17 2005
From: kloch at hotnic.net (Kevin Loch)
Date: Tue, 30 Aug 2005 13:00:17 -0400
Subject: [ppml] Proposed Policy: IPv6 Direct assignments to end sites
In-Reply-To: <3F05EE24A82C0B42811178EFB8820C3F465050@AX-S-EX-1.stanleyassociates.com>
References: <3F05EE24A82C0B42811178EFB8820C3F465050@AX-S-EX-1.stanleyassociates.com>
Message-ID: <431490A1.9090809@hotnic.net>

Howard, W. Lee wrote:
> Have we agreed that in IPv6 we'll use the term "LIR"? 

I tried to use language similar to the rest of section
6.  It's my understanding that "LIR" is the subset of
ISP's that qualify for an allocation from an RIR.

In the ARIN reigon they are essentially the same today but
those semantics are not within the scope of this proposal.

> 
>>          6.5.8.3. Subsequent direct assignments to end sites
>>                   Only one direct assignment may be made to 
>> 			an end site organization.
>>
>>                   End sites that require more than 65536 
>> subnets should request space from an LIR or consider becoming
>>                   an LIR.
> 
> So NRPM 6.2.4, would define "the users of the network services that
> it [the LIR] provides" as intra-company departments, to whom it
> would have to SWIP or equivalent?  Is that unusual?

This doesn't change the definition of an LIR, it merely
suggests that becoming one is a solution to needing more
space.  They would still have to meet the requirements
for an allocation.  If that second paragraph is bothersome
it can be deleted.

> Do we have any teeth to the "return within 1 year" policy?  In the
> past, the enforcement has been, "or you won't get any more address
> space," which isn't much incentive in IPv6.

This bothers me too, I would like to hear suggestions
on how we could enforce this.  In the worst case scenario
they end up with a /48 and a /32 which is not the end
of the world.  I wanted the policy to at least say
you shouldn't do that.

> In what way does the lack of PI assignments inhibit enterprise adoption?
> Is multi-homing harder, is it less reliable, or is it fear of commitment
> to an ISP?

This proposal is primarily about provider independence and multihoming
as a secondary effect.  We have heard on this list and others in
the past from enterprises and content sites that this is a big deal.
Hopefully they will reiterate their position on this proposal.

> 
> is there any guidance 
> on how they should assign IPv6 addresses?  Should each web server get a 
> /48, or a /64, or a /128?  Or does each server get a /64 (per interface)
> 
> and each virtual host gets a /128?

No guidance is given for how to utilize direct assignments other
than you only get a PI /48 to work with.  If you need more,
get a non-PI /48 from an upstream or become an LIR (which most
large hosting companies would qualify for under current rules anyway).

> If most organizations could easily qualify for an LIR allocation, then
> how is the lack of this proposed policy hindering adoption?

Perhaps they feel applying for a /32 would be wasteful?
Or they fear that they would not comply with future tightening of
the rules?  U would like to hear from those who are waiting for a
direct assignment policy so we don't have to guess.

- Kevin


From kloch at hotnic.net  Tue Aug 30 13:06:53 2005
From: kloch at hotnic.net (Kevin Loch)
Date: Tue, 30 Aug 2005 13:06:53 -0400
Subject: [ppml] Proposed Policy: IPv6 Direct assignments to end sites
In-Reply-To: <1E0D982B-11F2-4D38-9DE5-BEA4A79350F2@kurtis.pp.se>
References: <431318E7.80306@arin.net>
	<1E0D982B-11F2-4D38-9DE5-BEA4A79350F2@kurtis.pp.se>
Message-ID: <4314922D.6040908@hotnic.net>

Kurt Erik Lindqvist wrote:
> What's a "statically configured tunnel" ? Does MPLS count? I would  
> not call that a statically configured tunnel. So most L2VPN services  
> are out of the question...

The intent was to explicitly allow statically configured IPv6 over IPv4
tunnels, not to regulate things L2 or below.  Should it be reworded
to clarify that?

- Kevin


From kloch at hotnic.net  Tue Aug 30 13:33:27 2005
From: kloch at hotnic.net (Kevin Loch)
Date: Tue, 30 Aug 2005 13:33:27 -0400
Subject: [ppml] Proposed Policy: IPv6 Direct assignments to end sites
In-Reply-To: <8ce3063b54f1def4353016593ccdb777@it.uc3m.es>
References: <431318E7.80306@arin.net>
	<8ce3063b54f1def4353016593ccdb777@it.uc3m.es>
Message-ID: <43149867.3000708@hotnic.net>

marcelo bagnulo braun wrote:
> Having two tunnels configured with different tunnels providers through 
> a single dsl line would fulfill this requirement?

The tunnel language was included because there is not enough
deployment of native IPv6 throughout the ARIN reigon yet.

There is at least one large provider that offers v6 everywhere
but the chances of a typical enterprise or large content site
getting native v6 over their current v4 providers is fairly slim.

The tunnel requirement is consistent with the way many applicants
would actually use IPv6 in the near term.

> I guess this would allow any IPv6 fan to have their own PI prefix 
> fairly easily, so i would argue for stronger requirements than this...
> At least to be really multihomed, i.e. two different ISPs providing 
> different physical connectivity to the end site, similar to IPv4, i 
> guess

The current v4 policy just says "multi-homed".  It doesn't say anything
about separate physical connections or the speed of the lines.

- Kevin


From tme at multicasttech.com  Tue Aug 30 13:33:27 2005
From: tme at multicasttech.com (Marshall Eubanks)
Date: Tue, 30 Aug 2005 13:33:27 -0400
Subject: [ppml] Proposed Policy: IPv6 Direct assignments to end  sites
In-Reply-To: <1E0D982B-11F2-4D38-9DE5-BEA4A79350F2@kurtis.pp.se>
Message-ID: <web-2955545@multicasttech.com>

On Tue, 30 Aug 2005 12:46:15 +0200
 Kurt Erik Lindqvist <kurtis at kurtis.pp.se> wrote:
> 
> On 29 aug 2005, at 16.17, Member Services wrote:
> 
> [Proposal deleted]
> 
> You might want to note that there is no guarantee that this  
> assignment will actually get routed. Just as in some RIR regions you  
> will get less than a /24 v4 space as PI space, and you won't get very  
> far...

Dear Kurtis;

There is no guarantee that an IPv4 /24 will get routed either, nor the
/23's assigned by 2002-3. (I see this as basically the  IPv6 analogue of  2002-3.)

However, having officially assigned address block does certainly help.

What the current proposal really does is set a new expectation of
IPv6 /56's as becoming standard. I would feel more comfortable hearing from a critical mass of IPv6
vendors or SP's that this would not cause problems (it shouldn't, of course, but...). Unless it
does, I see no reason not to support this.


> 
> >         6.5.8.1. To qualify for a direct end site assignment, an
> >                   organization must:
> >
> >                   a) not be an LIR;
> >
> >                   b) be an end site;
> >
> >                   c) be currently multi-homed using IPv6 to two or  
> > more
> >                      separate LIR's. native connections or statically
> >                      configured tunnels may be used to satisfy this
> >                      requirement.
> 
> 
> What's a "statically configured tunnel" ? Does MPLS count? I would  
> not call that a statically configured tunnel. So most L2VPN services  
> are out of the question...
> 

I do not know, but  I suspect that he was trying to include the many sites that
get IPv6 through some sort of quasi-permanent tunnel, which  seems reasonable to me,
at least at this state of deployment. This is a tricky  issue (one could always order
2 T1's for a few months and get an ASN, all to get a 2002-3 address block, and 
then remove them, but that seems like a lot of work and cash
for a v4 /23 if you don't really need it. Now, if I can just set up two tunnels to somewhere, maybe
for free, and then take them down once I get a /48, maybe that is not a high enough barrier to
abuse. 

Here is a suggestion : tunnels (of any sort) should count for multi-homing if you are already IPv4
multi-homed or have IPv4 address blocks assigned to you (though 2002-3 or otherwise), but otherwise
you need direct IPv6 connections. (I.e., if you  are .v4 multihomed, you get a certain presumption
of being truly .v6 multihomed.)

> - kurtis -

Regards
Marshall

> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml



From tme at multicasttech.com  Tue Aug 30 13:47:42 2005
From: tme at multicasttech.com (Marshall Eubanks)
Date: Tue, 30 Aug 2005 13:47:42 -0400
Subject: [ppml] Proposed Policy: IPv6 Direct assignments to end  sites
In-Reply-To: <20050830141119.13992.qmail@hoster908.com>
Message-ID: <web-2955573@multicasttech.com>

On Tue, 30 Aug 2005 14:11:19 +0000
 "Andrew Dul" <andrew.dul at quark.net> wrote:
> -------Original Message-------
> > From: marcelo bagnulo braun <marcelo at it.uc3m.es>
> > Subject: Re: [ppml] Proposed Policy: IPv6 Direct assignments to end sites
> > Sent: 30 Aug '05 04:56
> > 
> >  Hi,
> >  
> >  El 29/08/2005, a las 16:17, Member Services escribi?:
> >  
> >  >
> >  ...
> >  > 6.5.8. Direct assignments to end sites.
> >  >
> >  >          6.5.8.1. To qualify for a direct end site assignment, an
> >  >                   organization must:
> >  >
> >  >                   a) not be an LIR;
> >  >
> >  >                   b) be an end site;
> >  >
> >  >                   c) be currently multi-homed using IPv6 to two or more
> >  >                      separate LIR's. native connections or statically
> >  >                      configured tunnels may be used to satisfy this
> >  >                      requirement.
> >  >
> >  
> >  Having two tunnels configured with different tunnels providers through
> >  a single dsl line would fulfill this requirement?
> >  I guess this would allow any IPv6 fan to have their own PI prefix
> >  fairly easily, so i would argue for stronger requirements than this...
> >  At least to be really multihomed, i.e. two different ISPs providing
> >  different physical connectivity to the end site, similar to IPv4, i
> >  guess
> >  
> >  However, i would even argue to reserve this type of PI based
> >  multihoming only "big" sites (the problem here would be to define what
> >  a big site is i am afraid)
> >  
> 
> What would people think about making one of the requirements to have an existing v4 end-site
> allocation from ARIN?  
> 

As a means of relaxing the criteria, sure.

However, if some all v6 organization comes to ARIN, they shouldn't be turned away. 

Regards
Marshall 


> Andrew
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml



From plzak at arin.net  Tue Aug 30 14:22:36 2005
From: plzak at arin.net (Ray Plzak)
Date: Tue, 30 Aug 2005 14:22:36 -0400
Subject: [ppml] Proposed Policy: IPv6 Direct assignments to end sites
In-Reply-To: <1E0D982B-11F2-4D38-9DE5-BEA4A79350F2@kurtis.pp.se>
Message-ID: <20050830182239.413511FF2B@mercury.arin.net>

I must point out that none of the RIRs guarantee routability.

Ray

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of
> Kurt Erik Lindqvist
> Sent: Tuesday, August 30, 2005 6:46 AM
> To: Member Services
> Cc: ppml at arin.net
> Subject: Re: [ppml] Proposed Policy: IPv6 Direct assignments to end sites
> 
> 
> On 29 aug 2005, at 16.17, Member Services wrote:
> 
> [Proposal deleted]
> 
> You might want to note that there is no guarantee that this
> assignment will actually get routed. Just as in some RIR regions you
> will get less than a /24 v4 space as PI space, and you won't get very
> far...
> 
> >         6.5.8.1. To qualify for a direct end site assignment, an
> >                   organization must:
> >
> >                   a) not be an LIR;
> >
> >                   b) be an end site;
> >
> >                   c) be currently multi-homed using IPv6 to two or
> > more
> >                      separate LIR's. native connections or statically
> >                      configured tunnels may be used to satisfy this
> >                      requirement.
> 
> 
> What's a "statically configured tunnel" ? Does MPLS count? I would
> not call that a statically configured tunnel. So most L2VPN services
> are out of the question...
> 
> - kurtis -
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml





From marcelo at it.uc3m.es  Tue Aug 30 14:55:10 2005
From: marcelo at it.uc3m.es (marcelo bagnulo braun)
Date: Tue, 30 Aug 2005 20:55:10 +0200
Subject: [ppml] Proposed Policy: IPv6 Direct assignments to end sites
In-Reply-To: <43149867.3000708@hotnic.net>
References: <431318E7.80306@arin.net>
	<8ce3063b54f1def4353016593ccdb777@it.uc3m.es>
	<43149867.3000708@hotnic.net>
Message-ID: <f3e64c78504f972125702ce17d42ce4c@it.uc3m.es>


El 30/08/2005, a las 19:33, Kevin Loch escribi?:

> marcelo bagnulo braun wrote:
>> Having two tunnels configured with different tunnels providers through
>> a single dsl line would fulfill this requirement?
>
> The tunnel language was included because there is not enough
> deployment of native IPv6 throughout the ARIN reigon yet.
>

i can see this point

> There is at least one large provider that offers v6 everywhere
> but the chances of a typical enterprise or large content site
> getting native v6 over their current v4 providers is fairly slim.
>

agree

> The tunnel requirement is consistent with the way many applicants
> would actually use IPv6 in the near term.
>

right, but i guess that there is a difference between actually 
obtaining connectivity through two different ISPs than getting 
connectivity through one ISP and setting up two tunnels over a dsl line


I mean if a site is obtaining connectivity through two differnet 
providers an those don't provide native v6 connectivity, so a tunnel 
must be set up, i agree that this is a multihomed site. OTOH, if a site 
has a single dsl line and is setting two v6 tunnels to some tunnels 
servers around the globe, i must say that they shouldn't qualify for a 
PI block imho

>> I guess this would allow any IPv6 fan to have their own PI prefix
>> fairly easily, so i would argue for stronger requirements than this...
>> At least to be really multihomed, i.e. two different ISPs providing
>> different physical connectivity to the end site, similar to IPv4, i
>> guess
>
> The current v4 policy just says "multi-homed".  It doesn't say anything
> about separate physical connections or the speed of the lines.
>

arin v4 policy defines

2.7. Multi-homed - An organization is multi-homed if it receives 
full-time connectivity from more than one ISP and has one or more 
routing prefixes announced by at least two of its upstream ISPs.

i think this is conceptually different from a site with a dsl line and 
two tunnels, imho

regards, marcelo


> - Kevin
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
>



From william at elan.net  Tue Aug 30 16:33:03 2005
From: william at elan.net (william(at)elan.net)
Date: Tue, 30 Aug 2005 13:33:03 -0700 (PDT)
Subject: [ppml] Proposed Policy: IPv6 Direct assignments to end sites
In-Reply-To: <4314922D.6040908@hotnic.net>
References: <431318E7.80306@arin.net>
	<1E0D982B-11F2-4D38-9DE5-BEA4A79350F2@kurtis.pp.se>
	<4314922D.6040908@hotnic.net>
Message-ID: <Pine.LNX.4.62.0508301329030.14154@sokol.elan.net>


On Tue, 30 Aug 2005, Kevin Loch wrote:

> Kurt Erik Lindqvist wrote:
>> What's a "statically configured tunnel" ? Does MPLS count? I would
>> not call that a statically configured tunnel. So most L2VPN services
>> are out of the question...
>
> The intent was to explicitly allow statically configured IPv6 over IPv4
> tunnels, not to regulate things L2 or below.  Should it be reworded
> to clarify that?

It shouldn't be there at all. You can do IPv4 over IPv4 tunnel, you can
do IPv4 over IPv6 tunnel, you could do IPv4 over MPLS and some could argue
(depending how MPLS network is designed) its also form of tunnel, etc.
How the ip routing is achieved is beyond scope of ARIN policy, what is 
important is that you have ipv6 connectivity from two distinct providers.

-- 
William Leibzon
Elan Networks
william at elan.net


From owen at delong.com  Tue Aug 30 17:46:21 2005
From: owen at delong.com (Owen DeLong)
Date: Tue, 30 Aug 2005 14:46:21 -0700
Subject: [ppml] Proposed Policy: IPv6 Direct assignments to end sites
In-Reply-To: <web-2955545@multicasttech.com>
References: <web-2955545@multicasttech.com>
Message-ID: <B547025574AAEB372A37254C@imac-en0.delong.sj.ca.us>

Small correction... 2002-3 allows for /22s, not /23s.

Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050830/060e0f0e/attachment.sig>

From Lee.Howard at stanleyassociates.com  Tue Aug 30 21:30:03 2005
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Tue, 30 Aug 2005 21:30:03 -0400
Subject: [ppml] Proposed Policy: IPv6 Direct assignments to end sites
Message-ID: <3F05EE24A82C0B42811178EFB8820C3F4652C7@AX-S-EX-1.stanleyassociates.com>

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Kurt Erik Lindqvist
> Sent: Tuesday, August 30, 2005 6:46 AM
> To: Member Services
> Cc: ppml at arin.net
> Subject: Re: [ppml] Proposed Policy: IPv6 Direct assignments 
> to end sites
> 
> 
> On 29 aug 2005, at 16.17, Member Services wrote:
> 
> [Proposal deleted]
> 
> You might want to note that there is no guarantee that this  
> assignment will actually get routed. Just as in some RIR regions you  
> will get less than a /24 v4 space as PI space, and you won't 
> get very far...

See section 6.4.2 of the Number Resource Policy Manual.
http://www.arin.net/policy/nrpm.html#six42

While you're there, read section 6.3; we're definitely changing
that.

> - kurtis -


Lee