[ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested

Fri Jan 26 17:52:38 EST 2007

Hi Marshall,

See below, in-line.

Regards,
Jordi

> De: Marshall Eubanks <tme at multicasttech.com>
> Responder a: <tme at multicasttech.com>
> Fecha: Fri, 26 Jan 2007 11:21:14 -0500
> Para: <jordi.palet at consulintel.es>
> CC: <ppml at arin.net>
> Asunto: Re: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested
> changes-InputRequested
> 
> Hello;
> 
> On Jan 26, 2007, at 7:50 AM, JORDI PALET MARTINEZ wrote:
> 
>> Hi Andrew,
>> 
>> See below, in-line.
>> 
>> Regards,
>> Jordi
>> 
>> 
>> 
>> 
>>> De: Andrew Dul <andrew.dul at quark.net>
>>> Responder a: <ppml-bounces at arin.net>
>>> Fecha: Thu, 25 Jan 2007 14:56:53 -0800
>>> Para: <ppml at arin.net>
>>> Asunto: Re: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested
>>> changes-InputRequested
>>> 
>>> First I don't necessarily see the need to change the existing
>>> policy.  I'd
>>> don't see the 200 /48s plan as a real hinderance to a legitimate LIR.
>> 
>> So do you think is not possible an ISP to have a few customer and make
>> profitable business ?
>> 
>> Do you think is reasonable to stop people that are willing or
>> already doing
>> business this way ?
>> 
>> In fact, when I introduced my idea about this possible policy
>> proposal at
>> the last meeting, I recall at least a couple of people in the room
>> being in
>> this situation, so is something real.
>> 
>>> 
>>> I generally only support change #1
>> 
>> The only trouble I see with this is that may be to obtain an ASN is
>> mandated
>> that the ISP is multihomed ? Is this the case in ARIN ?
> 
> Not every entity which is multi-homed is an ISP. (My company is and
> isn't, respectively.)

No, I'm not trying to mean that ... Sorry not having been clear enough.

What I want to say is that there are ISPs which aren't multihomed (they have
a single upstream provider). Those ISPs also have the right to receive an
IPv6 allocation.

In some regions, to receive an ASN you need to be multihomed. So if that's
the case, then we are creating an artificial restriction for those
single-homed ISPs.

I'm not sure if this is the case of ARIN according to section 5 of the NRPM
(I was traveling and off-line before, so couldn't check it before sending my
previous email).

My reading of this section is that to be assigned an ASN the organization
must either have a unique routing policy or be multihomed. That's seems
clear, but then it says that "an organization should request an ASN only
when it is already multihomed or will become immediately". Is this meaning
that the previous text (having a unique routing policy) is not enough ?

> 
> Look at 4.3, 4.4 and 4.5 in
> 
> http://www.arin.net/policy/nrpm.html#two7
> 
> Clearly, being multi-homed is one way. But there are others :
> 
> 4.5.2
> The organization must have compelling criteria for creating discrete
> networks. Examples of a discrete network might include:
> Regulatory restrictions for data transmission,
> Geographic distance and diversity between networks,
> Autonomous multihomed discrete networks.
> 
> 
>> 
>> My view is that there may be small ISPs that aren't multihomed, but
>> still
>> need PA space in order to avoid depending on its upstream
>> addressing space
> 
> Do you mean PI ?

No, my view is that they need Provider space, because they are ISP providing
service to other organizations. It is not a PI case.

> 
>> (avoid renumbering all customer networks, etc.).
>> 
> 
> I think (and more importantly, there is clearly consensus that) there
> should be some filter for
> these assignments; the current mix seems reasonable to me.
> 
> Regards
> Marshall
> 
>>> 
>>> Change #2 would allow almost any organization to qualify as a LIR,
>> 
>> Only if they plan to provide service to others, and I read that as
>> perfectly
>> valid for an ISP, not "any organization".
> 
>> 
>>> Change #3 while having a good intent seems oddly worded. I'm not
>>> sure if
>>> the intent is for requirements a-c to still apply and for there to
>>> be an OR
>>> between d/e?  If that is the intent I would make it clear that a-c
>>> are
>>> still required and then you can choose either d/e to qualify.  I
>>> also worry
>>> #3 opens the option for non-LIR entities (endsites) to claim to be
>>> LIRs to
>>> qualify under these LIR rules.
>> 
>> The idea is to keep existing policy and add as OR in between d/e. Same
>> comment regarding is intended for ISPs (providing service to other
>> organizations).
>> 
>>> 
>>> 
>>> At 11:52 AM 1/23/2007 -0500, Azinger, Marla wrote:
>>>> Hello-  The deadline for proposal submissions is getting close
>>>> (Feb 22nd).
>>>> 
>>>> In order to help Jordi decide just how he will modify his previously
>>> proposed policy 2006-7 IPV6 Initial Allocation, I am asking for
>>> one more
>>> round of feedback.  Below is the same email that went out back in
>>> November.
>>>  Within it are the modifications currently being considered.  A
>>> few people
>>> responded back in November, and Thank you to those who did.  Now
>>> we are
>>> looking for more input from anyone who hasnt yet voiced their
>>> opinion.
>>>> 
>>>> Thank you for your time
>>>> Marla Azinger
>>>> 
>>>> -----Original Message-----
>>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On
>>>> Behalf Of
>>>> Azinger, Marla
>>>> Sent: Monday, November 13, 2006 11:00 AM
>>>> To: ppml at arin.net
>>>> Subject: [ppml] 2006-7 IPV6 Initial Allocation suggested changes-
>>>> InputRequested
>>>> 
>>>> 
>>>> Hello-  In an effort to work with the community on changes to Policy
>>> Proposal 2006-7 Changes to IPV6 Initial Allocation Criteria, three
>>> different suggested revisions are in this email.  We would like the
>>> communities input on three separate suggested revisions.  What do
>>> you like
>>> about them, or what do you not like about them? Do you prefer one
>>> suggestion over the other?  I have given each suggestion a
>>> different color
>>> to make it easier to tell when one suggestion ands and another
>>> begins.
>>> When reviewing the three suggested changes please note the following
>>> assumptions:
>>>> 
>>>> - New organizations who do not want to use IPv4 at all and start
>>>> off using
>>> IPv6 addresses only, need a policy that gives them permission to
>>> do so.
>>> This is also valid for existing companies that may or may not have
>>> assigned
>>> IPv4 addresses and now want to start offering IPv6 services. These
>>> organizations may also wish to request IPv4 at the same time.
>>>> - One year is given as the sufficient time frame to actually
>>>> implement
>>> usage of the IPv6 address space and reveal if the 'said
>>> organization' is
>>> truly using the IPv6 space granted.
>>>> -Every means of documentation that can reveal 'true intent of
>>>> use' is not
>>> listed as this can be a very long list and should be left to the
>>> discretion
>>> of the RIR staff.
>>>> - Organization in this is defined as a Corporation, ISP, LLC et al.
>>>> 
>>>> 
>>>> Suggested Change #1 (deletes and replaces current text of item d and
>>> requires ASN)
>>>> Replace line item d. to 6.5.1.1 with the following:
>>>> 'To qualify for an initial allocation of IPV6 address space, an
>>> organization must':
>>>> d. be an existing, known ISP in the ARIN region OR be an
>>>> organization which
>>>> can justify intent to announce the requested IPv6 address space
>>>> within one
>>>> year and have/obtain and AS Number.
>>>> 
>>>> Rationale for ASN:
>>>> Someone providing this kind of service needs to run BGP.
>>>> 
>>>> 
>>>> Suggested Change #2 (deletes and replaces current text of item d
>>>> but does
>>> not require ASN)
>>>> Replace line item d. to 6.5.1.1 with the following:
>>>> 'To qualify for an initial allocation of IPv6 address space, an
>>>> organization
>>>> must':
>>>> d. be an existing, known ISP in the ARIN region OR be an
>>>> organization which
>>>> can justify intent to announce the requested IPv6 address space
>>>> within one
>>>> year.
>>>> 
>>>> Rationale for no asn:
>>>> We should not require an ASN if they really don't need one? As
>>>> long as
>>> they are statically routed to an upstream and don't want to run
>>> bgp/announce directly to the Internet, they don't need an ASN,
>>> therefore we
>>> shouldn't create policy that would contribute to ASN bloat.
>>>> 
>>>> 
>>>> Suggested Change #3 (leaves item d in place with the 200 /48 text
>>>> and adds
>>> a new item e but does not require ASN)
>>>> Insert line item e. to 6.5.1.1 with the following:
>>>> 'To qualify for an initial allocation of IPV6 address space, an
>>> organization must':
>>>> e.  OR be an organization new to providing internet services, and
>>>> can
>>> justify intent to announce the requested IPV6 address space within
>>> one
>>> year, through records such as contracts, inventory and/or other
>>> applicable
>>> documentation.
>>>> 
>>>> Rationale for no asn:
>>>> We should not require an ASN if they really don't need one? As
>>>> long as
>>> they are statically routed to an upstream and don't want to run
>>> bgp/announce directly to the Internet, they don't need an ASN,
>>> therefore we
>>> shouldn't create policy that would contribute to ASN bloat.
>>>> 
>>>> Thank you for your time
>>>> Marla (ARIN AC) and Jordi (Proposal Author)
>>>> 
>>>> _______________________________________________
>>>> PPML mailing list
>>>> PPML at arin.net
>>>> http://lists.arin.net/mailman/listinfo/ppml
>>>> _______________________________________________
>>>> PPML mailing list
>>>> PPML at arin.net
>>>> http://lists.arin.net/mailman/listinfo/ppml
>>>> 
>>> _______________________________________________
>>> PPML mailing list
>>> PPML at arin.net
>>> http://lists.arin.net/mailman/listinfo/ppml
>> 
>> 
>> 
>> 
>> **********************************************
>> The IPv6 Portal: http://www.ipv6tf.org
>> 
>> Bye 6Bone. Hi, IPv6 !
>> http://www.ipv6day.org
>> 
>> This electronic message contains information which may be
>> privileged or confidential. The information is intended to be for
>> the use of the individual(s) named above. If you are not the
>> intended recipient be aware that any disclosure, copying,
>> distribution or use of the contents of this information, including
>> attached files, is prohibited.
>> 
>> 
>> 
>> _______________________________________________
>> PPML mailing list
>> PPML at arin.net
>> http://lists.arin.net/mailman/listinfo/ppml
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.