<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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.</p>
<p>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.<br>
</p>
<p>If anyone can shed a light on it would help to understand better
for this to exist this way now a days.<br>
Thanks<br>
Fernando<br>
</p>
<div class="moz-cite-prefix">Em 03/01/2023 19:18, Matthew Petach
escreveu:<br>
</div>
<blockquote type="cite"
cite="mid:CAEmG1=qKhHzgKgoR27pLm1nrdKOyOER5L0qNzghNAMwyS4tFSw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><br>
<div>Hi Jamie,</div>
<div><br>
</div>
<div>As someone who faced a similar challenge many years ago,
I'll chime in with my thoughts on the matter...</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Jan 2, 2023 at 11:32
PM Jamie Nelson <<a
href="mailto:nelsonjamie508@gmail.com"
moz-do-not-send="true" class="moz-txt-link-freetext">nelsonjamie508@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">ARIN newbie here. <br>
</blockquote>
<div>[...] </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<br>
Questions:<br>
1.) From our reading of the NRPM, it seems like we currently
fall<br>
within the definition of an ISP, but what happens if this
changes<br>
subsequent to our initial allocation? (*) Likewise, what
happens if<br>
an organization that was directly assigned resources as an
end-user<br>
begins offering Internet services to other organizations?
The NRPM<br>
does not appear to address these scenarios.<br>
</blockquote>
<div><br>
</div>
<div>You're providing services to people who are not directly
employees, </div>
<div>contractors, or otherwise immediately affiliated with
your organization.</div>
<div>I was in a similar boat, and after looking carefully at
how law enforcement </div>
<div>approached ISPs for information versus end-users, we made
a decision </div>
<div>to apply for resources as an ISP, as we provided services
to people who </div>
<div>were not directly under our umbrella.</div>
<div><br>
</div>
<div>Once your resources are granted under the ISP rules, they
remain that </div>
<div>way, even if your ISP business ceases to exist--though,
the idea of an </div>
<div>ISP 'ceasing to exist' is a questionable one, since in
almost every case, </div>
<div>a successor entity takes over the business, and the
number resources </div>
<div>that go with the ISP business follow the customers to the
new owner.</div>
<div>See for example the Sprint wireline ISP network being
sold to Cogent; </div>
<div>the number resources don't stay with T-mobile, they go
with the Sprint </div>
<div>customers currently using them over to Cogent. If you
eventually sell the </div>
<div>colocation business to someone else, you'll have to
wrestle with how the </div>
<div>number resources are to be handled. As such, I would
strongly recommend </div>
<div>you allocate your number resources accordingly; if you
think the ISP business </div>
<div>may continue to grow, it may be worth registering 2
different ORG-IDs, one </div>
<div>for your (end-user-like) corporate network, and a
separate one for the (isp-like)</div>
<div>colocation business, so that if in the future you decide
to divest the ISP side </div>
<div>of the business, you can do so without having to perform
massive surgery </div>
<div>on your network. Just a thought on saving some potential
renumbering </div>
<div>pain down the road. ^_^;</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
3.) Is conversion from ISP to End User (and vice versa)
possible if<br>
the nature of an organization's business changes? Is it
necessary?<br>
</blockquote>
<div><br>
</div>
<div>Lisa already answered this; I would note that there's no
secret police that </div>
<div>come after you if your business changes form down the
road, it's really </div>
<div>your decision if you feel a better set of policies would
apply if you were to</div>
<div>reclassify your business.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
4.) Is ISP/end-user status recorded in ARIN's database on a
per-prefix<br>
basis, or is it per-organization? How does one currently
determine<br>
this status from Whois? I tried to find examples of
organizations<br>
that would typically be seen as end-users, but there were no
clues in<br>
their organizational Whois results, and Whois queries on
their<br>
prefixes all indicate "NetType: Direct Allocation", just
like ISPs, as<br>
opposed to "NetType: Direct Assignment". This would be
consistent<br>
with a clue I found in the problem statement of Draft Policy<br>
ARIN-2022-12, which indicates that "direct assignments are
no longer<br>
being utilized in ARIN databases", but does this then imply
that the<br>
ISP/end-user distinction has been eliminated entirely?<br>
</blockquote>
<div><br>
</div>
<div>Functionally, the distinction is really about checking to
see which policies </div>
<div>your organization falls under when looking at your
utilization to see if you</div>
<div>qualify for additional blocks; you should definitely read
through</div>
<div><a
href="https://www.arin.net/resources/registry/reassignments/"
moz-do-not-send="true" class="moz-txt-link-freetext">https://www.arin.net/resources/registry/reassignments/</a><br>
</div>
<div>to get a good understanding of the distinction. So, it's
not that a specific </div>
<div>block is a direct assignment versus a direct allocation,
it's that your </div>
<div>ORG-ID falls under utilization requirements for ISPs
versus end users;</div>
<div>and because that can change all at once if you request a
reclassification </div>
<div>of your organization, trying to identify block-by-block
which rules they fall </div>
<div>under becomes a nearly pointless exercise.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
5.) Now that ISPs and end-users share the same fee schedule
and voting<br>
privileges, what distinctions remain, other than differences
in<br>
allocation rules and the obligation for ISPs to register<br>
reassignments/reallocations?<br>
</blockquote>
<div><br>
</div>
<div>As noted in the URL above, even end users aren't immune
to the requirement </div>
<div>to track assignment of number resources. As an ISP, you
can punt the </div>
<div>tracking requirement for the number resources to your
downstream customer, </div>
<div>or do it yourself; as an end-user, there's nobody else to
punt the tracking to,</div>
<div>it's all in your hands. But either way, the number
resources have to be tracked, </div>
<div>either through your own Rwhois server, or through the
SWIP system.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
* It can be assumed for the above questions that our
organization type<br>
(whether ISP or end-user) will not impact the size of the
IPv6 prefix<br>
that we qualify for and request, which we anticipate being
/40. In<br>
the hypothetical scenario where we would want to convert
from ISP to<br>
end-user (assuming it's even possible), we wouldn't face the
issue of<br>
not qualifying for an IPv6 block as large as the one that we
were<br>
initially allocated as an ISP. We have > 13 sites in our
WAN. I<br>
would be curious, however, to understand what might happen
if an ISP<br>
were to have a larger allocation than that which it would
qualify for<br>
once becoming an end user.<br>
</blockquote>
<div><br>
</div>
<div>To my point above--to simplify the situation, if it were
me, I would </div>
<div>create two different ORG-IDs; one for your corporate
network environment, </div>
<div>and one for your ISP business. I would request number
resources </div>
<div>appropriate to each. I would make the corporate network
a downstream </div>
<div>customer of the ISP network, but also get a second backup
link so that </div>
<div>your corporate network stays functional even if the
colocation side of the </div>
<div>business has a spectacular meltdown. Thus, you would end
up with two </div>
<div>different entities; a multihomed ISP network providing
colocation services </div>
<div>to customers, and a multihomed end-user corporate
network, which happens </div>
<div>to buy services from the ISP network as one of its
upstreams.</div>
<div>That way, in the future, if you grow the ISP business,
your number resource</div>
<div>utilization will be based on the customer growth, and not
be hampered by the </div>
<div>relatively unchanging corporate network side. You can
request and add additional </div>
<div>number resources to the ISP ORG-ID unimpeded by the
corporate network. And, </div>
<div>if you eventually decide you want to divest the ISP side
of the business, you can </div>
<div>transfer the ORG-ID and associated number resources to
the purchaser of the </div>
<div>business with relatively little impact to your end-user
corporate network.</div>
<div><br>
</div>
<div>It's a little more initial work, setting up the two
different ORG-IDs for the two </div>
<div>different portions of the business, but it will simplify
tracking number resources,</div>
<div>requesting additional resources, and potentially selling
off the ISP business in </div>
<div>the future should you decide to do so.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
Thanks in advance for any insight.<br>
</blockquote>
<div><br>
</div>
<div>Best of luck!</div>
<div><br>
</div>
<div>Thanks!</div>
<div><br>
</div>
<div>Matt</div>
<div> </div>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
</pre>
</blockquote>
</body>
</html>