[ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested
Marshall Eubanks
tme at multicasttech.com
Fri Jan 26 11:21:14 EST 2007
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.)
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 ?
> (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
More information about the ARIN-PPML
mailing list