[arin-ppml] Are we an ISP or an End-User? Can our designation change at a later time?
fhfrediani at gmail.com
Wed Jan 4 14:52:08 EST 2023
Interesting this topic. Generally speaking I always found a bit strange
(not only in ARIN) to have this distinction between ISP and End-user. In
practice things should not differ much. Only thing that would possible
remain slightly different are the details of justifications that must be
provided and the size of the block to be allocated.
Another thing that I wanted to understand better is the reasoning to
allocate a significant smaller IPv6 block to a said end-user
organization given it is not so scarce resource. At least a /40 should
be minimal default for a end-user (not a /48) and a /32 for any size of
ISP. For now my personal impression is to create some artificial
scarcity in order to have different levels of Service Category.
If anyone can shed a light on it would help to understand better for
this to exist this way now a days.
Em 03/01/2023 19:18, Matthew Petach escreveu:
> Hi Jamie,
> As someone who faced a similar challenge many years ago, I'll chime in
> with my thoughts on the matter...
> On Mon, Jan 2, 2023 at 11:32 PM Jamie Nelson
> <nelsonjamie508 at gmail.com> wrote:
> ARIN newbie here.
> 1.) From our reading of the NRPM, it seems like we currently fall
> within the definition of an ISP, but what happens if this changes
> subsequent to our initial allocation? (*) Likewise, what happens if
> an organization that was directly assigned resources as an end-user
> begins offering Internet services to other organizations? The NRPM
> does not appear to address these scenarios.
> You're providing services to people who are not directly employees,
> contractors, or otherwise immediately affiliated with your organization.
> I was in a similar boat, and after looking carefully at how law
> approached ISPs for information versus end-users, we made a decision
> to apply for resources as an ISP, as we provided services to people who
> were not directly under our umbrella.
> Once your resources are granted under the ISP rules, they remain that
> way, even if your ISP business ceases to exist--though, the idea of an
> ISP 'ceasing to exist' is a questionable one, since in almost every case,
> a successor entity takes over the business, and the number resources
> that go with the ISP business follow the customers to the new owner.
> See for example the Sprint wireline ISP network being sold to Cogent;
> the number resources don't stay with T-mobile, they go with the Sprint
> customers currently using them over to Cogent. If you eventually sell
> colocation business to someone else, you'll have to wrestle with how the
> number resources are to be handled. As such, I would strongly recommend
> you allocate your number resources accordingly; if you think the ISP
> may continue to grow, it may be worth registering 2 different ORG-IDs,
> for your (end-user-like) corporate network, and a separate one for the
> colocation business, so that if in the future you decide to divest the
> ISP side
> of the business, you can do so without having to perform massive surgery
> on your network. Just a thought on saving some potential renumbering
> pain down the road. ^_^;
> 3.) Is conversion from ISP to End User (and vice versa) possible if
> the nature of an organization's business changes? Is it necessary?
> Lisa already answered this; I would note that there's no secret police
> come after you if your business changes form down the road, it's really
> your decision if you feel a better set of policies would apply if you
> were to
> reclassify your business.
> 4.) Is ISP/end-user status recorded in ARIN's database on a per-prefix
> basis, or is it per-organization? How does one currently determine
> this status from Whois? I tried to find examples of organizations
> that would typically be seen as end-users, but there were no clues in
> their organizational Whois results, and Whois queries on their
> prefixes all indicate "NetType: Direct Allocation", just like ISPs, as
> opposed to "NetType: Direct Assignment". This would be consistent
> with a clue I found in the problem statement of Draft Policy
> ARIN-2022-12, which indicates that "direct assignments are no longer
> being utilized in ARIN databases", but does this then imply that the
> ISP/end-user distinction has been eliminated entirely?
> Functionally, the distinction is really about checking to see which
> your organization falls under when looking at your utilization to see
> if you
> qualify for additional blocks; you should definitely read through
> to get a good understanding of the distinction. So, it's not that a
> block is a direct assignment versus a direct allocation, it's that your
> ORG-ID falls under utilization requirements for ISPs versus end users;
> and because that can change all at once if you request a reclassification
> of your organization, trying to identify block-by-block which rules
> they fall
> under becomes a nearly pointless exercise.
> 5.) Now that ISPs and end-users share the same fee schedule and voting
> privileges, what distinctions remain, other than differences in
> allocation rules and the obligation for ISPs to register
> As noted in the URL above, even end users aren't immune to the
> to track assignment of number resources. As an ISP, you can punt the
> tracking requirement for the number resources to your downstream
> or do it yourself; as an end-user, there's nobody else to punt the
> tracking to,
> it's all in your hands. But either way, the number resources have to
> be tracked,
> either through your own Rwhois server, or through the SWIP system.
> * It can be assumed for the above questions that our organization type
> (whether ISP or end-user) will not impact the size of the IPv6 prefix
> that we qualify for and request, which we anticipate being /40. In
> the hypothetical scenario where we would want to convert from ISP to
> end-user (assuming it's even possible), we wouldn't face the issue of
> not qualifying for an IPv6 block as large as the one that we were
> initially allocated as an ISP. We have > 13 sites in our WAN. I
> would be curious, however, to understand what might happen if an ISP
> were to have a larger allocation than that which it would qualify for
> once becoming an end user.
> To my point above--to simplify the situation, if it were me, I would
> create two different ORG-IDs; one for your corporate network environment,
> and one for your ISP business. I would request number resources
> appropriate to each. I would make the corporate network a downstream
> customer of the ISP network, but also get a second backup link so that
> your corporate network stays functional even if the colocation side of
> business has a spectacular meltdown. Thus, you would end up with two
> different entities; a multihomed ISP network providing colocation
> to customers, and a multihomed end-user corporate network, which happens
> to buy services from the ISP network as one of its upstreams.
> That way, in the future, if you grow the ISP business, your number
> utilization will be based on the customer growth, and not be hampered
> by the
> relatively unchanging corporate network side. You can request and add
> number resources to the ISP ORG-ID unimpeded by the corporate
> network. And,
> if you eventually decide you want to divest the ISP side of the
> business, you can
> transfer the ORG-ID and associated number resources to the purchaser
> of the
> business with relatively little impact to your end-user corporate network.
> It's a little more initial work, setting up the two different ORG-IDs
> for the two
> different portions of the business, but it will simplify tracking
> number resources,
> requesting additional resources, and potentially selling off the ISP
> business in
> the future should you decide to do so.
> Thanks in advance for any insight.
> Best of luck!
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> Please contactinfo at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ARIN-PPML