Hi Andrew,


Unfortunately, the only way to have redundancy in your upstream while
keeping connectivity to your network address is to be an ISP by this
definition, even if you offer no network services to other organizations.
This is because an AS is required to perform BGP, which is critical to
maintaining connectivity to a multi-homed network through outage of
one or more connected circuits.


ARIN's definition of ISP/end-user is related to the services ARIN offers
to an organization and may not be specifically tied to a "classic"
definition of an ISP.

Precisely what I was trying, if failing, to express. David's post clarified the delineation. I see from the NRPM that there is a minor difference in fee schedule too. For example, an end user with a /44 or /48 of v6, a /24 of v4, and an ASN would pay approximately $200/year more than a 3x-small, and $50 less than a 2x-small.

This applies, however, only to those who do not subscribe to the Registration Services Plan, if I understand correctly, as subscribing to said plan converts one from End User to ISP automatically. Needless to say, there are organizations that are end users by functional definition here, but subscribe to the service plan, and/or choose to be an ISP for other reasons.





An end-user organization who would be eligible to obtain an /48 under
6.5.8 of the NRPM.  

https://www.arin.net/participate/policy/nrpm/#6-5-8-direct-assignments-from-arin-to-end-user-organizations


True, but I was referring to protocol version agnostic multi-homing. Would an end user also qualify for 4.10 v4 space by requesting a /44 or /48 directly from ARIN?


This draft policy ARIN-2020-3 is specifically related to ISPs.

I believe you are making a misclassification here.  Once these
organizations have AS and/or address resources, they are considered an
ISP for these purposes, despite their end use case.

I disagree, others feel free to correct me. 

You are right.  Pardon my confusion.

Scott








Andrew

On 10/12/2020 12:26 PM, [email protected] wrote:
Hi Chris,

I wonder what percentage of 2x-small Resource holders have a /24 of
v4, and would otherwise qualify for 3x-small status but for their v6
allocations, and what percentage of all ASs registered with ARIN that
represents.  This represents the the total who could "downgrade" to a
nano-allocation, were that a option.  It would be easy to derive from
that the maximum effect on ARIN's finances, if they all chose to take
that option.

Scott

On Mon, 12 Oct 2020, Chris Woodfield wrote:

Agreed. To be clear, I did not intend for my question to imply that
the goal of keeping the proposal revenue-neutral was in any way
dishonorable - ARIN’s financial stability is obviously in the
community’s best interests. But we should have informed consent
as to
how that stability is achieved, and as such, clarifying the
intention
of the clause is helpful.




Thanks,

-C

On Oct 12, 2020, at 11:06 AM, [email protected] wrote:

Hi Chris,

Indeed.  To be fair, I think the price is fair for value received,
speaking as a 2x-small ISP with a /36.  I was able to lower my
recurring costs and increase my available address pool by bringing
up an AS at the 2x-small rate.  Allowing the smallest ISPs to
implement IPv6 without additional financial cost seems a prudent
way
to overcome barriers to adoption.

Scott

On Sun, 11 Oct 2020, Chris Woodfield wrote:

Thanks Andrew, and good catch - both Scott and I missed that
clause, obviously. It appears that this is in place in order to
meet the stated goal of this proposal being revenue-neutral for
ARIN? If so, it would be great to clarify so that community
members
can make a more informed evaluation as to whether or not to
support
the clause. If there are other justifications for the clause’s
presence, I’d be interested to hear them.
2~>
Thanks,

-C

On Oct 11, 2020, at 10:24 AM, Andrew Dul <[email protected]>
wrote:

The current draft policy text disallows returns to lower than a
/36, so
I would say that organization which took a /36 would not be
permitted to
go down to a /40.

"Partial returns of any IPv6 allocation that results in less than
a /36
of holding are not permitted regardless of the ISP’s current or
former
IPv4 number resource holdings."

Andrew

On 10/9/2020 2:04 PM, Chris Woodfield wrote:
Hi Scott,

Given that ARIN utilizes a sparse allocation strategy for IPv6
resources (in my organization’s case, we could go from a /32
to a
/25 without renumbering), IMO it would not be unreasonable for
the allocation to be adjusted down simply by changing the mask
and keeping the /36 or /32 unallocated until the sparse
allocations are exhausted. Any resources numbered outside the
new
/40 would need to be renumbered, to be sure, but that’s most
likely less work than a complete renumbering.

That said, I’ll leave it up to Registration Services to
provide a
definitive answer.

-C

On Fri, 9 Oct 2020, [email protected] wrote:

Hi All,

I am in favor of this draft, and am curious as to how resource
holders who were not dissuaded by the fee increase will be
impacted by the policy change. While they indeed have more
address space than /40, they may also not need the additional
address space.  Some might prefer the nano-allocation given
the
lower cost.  Will they be required to change allocations, and
renumber, in order to return to 3x-small status and associated
rate?

Scott Johnson
SolarNetOne, Inc.
AS32639
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.

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

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










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

Reply via email to