<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">In general, I agree with your point. Perhaps “Customer must originate prefix(es) and announce them via a border routing protocol (e.g. BGP-4) to each of their upstreams."</div><div class=""><br class=""></div>In specific, I think it’s extremely unlikely that there will be any significant advances or changes in IPv4 routing protocols as the IETF has pretty thoroughly expressed a<div class="">desire to stop working on IPv4 except in furtherance of transition to IPv6.</div><div class=""><br class=""></div><div class="">Owen</div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 16, 2020, at 11:06 , John Santos <<a href="mailto:john@egh.com" class="">john@egh.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class="">
<div class="moz-cite-prefix">On 7/16/2020 11:39 AM, Kat Hunter
wrote:</div>
<div class="moz-cite-prefix">[...]<br class="">
</div>
<blockquote type="cite" cite="mid:CAC=UcieNzk9knpV0pmR-2PC8+p+t+rfsgHhx0XYNBjUuRDxpoA@mail.gmail.com" class="">
<meta http-equiv="content-type" content="text/html; charset=UTF-8" class="">
<div dir="ltr" class="">4.2.3.6 Original Text:<br class="">
<div class="">Under normal circumstances an ISP is required to determine
the prefix size of their reassignment to a downstream customer
according to the guidelines set forth in RFC 2050.
Specifically, a downstream customer justifies their
reassignment by demonstrating they have an immediate
requirement for 25% of the IP addresses being assigned, and
that they have a plan to utilize 50% of their assignment
within one year of its receipt. This policy allows a
downstream customer’s multihoming requirement to serve as
justification for a /24 reassignment from their upstream ISP,
regardless of host requirements. Downstream customers must
provide contact information for all of their upstream
providers to the ISP from whom they are requesting a /24. The
ISP will then verify the customer’s multihoming requirement
and may assign the customer a /24, based on this policy.
Customers may receive a /24 from only one of their upstream
providers under this policy without providing additional
justification. ISPs may demonstrate they have made an
assignment to a downstream customer under this policy by
supplying ARIN with the information they collected from the
customer, as described above, or by identifying the AS number
of the customer. This information may be requested by ARIN
staff when reviewing an ISP’s utilization during their request
for additional IP addresses space.<br class="">
<br class="">
</div>
</div>
</blockquote><p class="">New version of proposed 4.2.3.6 replacement:</p>
<blockquote type="cite" cite="mid:CAC=UcieNzk9knpV0pmR-2PC8+p+t+rfsgHhx0XYNBjUuRDxpoA@mail.gmail.com" class="">
<div dir="ltr" class="">
<div class="">4.3.2.6 New Text, replacing old:<br class="">
If a downstream customer has a requirement to multihome, that
requirement alone will serve as justification for a /24
allocation. Downstream customers must provide contact
information for all of their upstream providers to the ISP
from whom they are requesting a /24, and utilize BGP as the
routing protocol between the customer and the ISP. Customers
may receive a /24 from only one of their upstream providers
under this policy without providing additional justification.
ISPs may demonstrate they have made an assignment to a
downstream customer under this policy by supplying ARIN with
the information they collected from the customer, as described
above, or by identifying the AS number of the customer.<br class="">
<div class=""><br class="">
</div>
<div class="">-Kat Hunter</div>
</div>
</div>
[...]<br class="">
</blockquote>
Older version of proposed 4.2.3.6:<br class="">
<blockquote type="cite" cite="mid:CAC=UcieNzk9knpV0pmR-2PC8+p+t+rfsgHhx0XYNBjUuRDxpoA@mail.gmail.com" class="">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br class="">
4.2.3.6. Reassignments to Multihomed Downstream Customers<br class="">
<br class="">
If a downstream customer has a requirement to multihome, that
<br class="">
requirement alone will serve as justification for a /24
allocation. <br class="">
Downstream customers must provide contact information for all
of their <br class="">
upstream providers to the ISP from whom they are requesting a
/24, and <br class="">
utilize BGP as the routing protocol between the customer and
the ISP. <br class="">
Customers may receive a /24 from only one of their upstream
providers <br class="">
under this policy without providing additional justification.
ISPs may <br class="">
demonstrate they have made an assignment to a downstream
customer under <br class="">
this policy by supplying ARIN with the information they
collected from <br class="">
the customer, as described above, or by identifying the AS
number of the <br class="">
customer.<br class="">
<br class="">
Timetable for implementation: Immediate<br class="">
</blockquote>
</div>
</blockquote><p class="">I haven't digested this proposal sufficiently to have an opinion
one way or the other, but I do have a general and a specific
question. Doesn't ARIN attempt to avoid mandating particular
network technologies in policy, so as not to impede technological
advances?</p><p class="">I am particularly referring to BGP in both versions of the
proposed new policy. Would it be better to develop wording that
would suggest BGP until something better comes along, by not
specifically refer to it in the policy text? Or is BGP considered
to be as good as it's ever going to get, at least for IPv4
routing?<br class="">
</p><p class=""><br class="">
</p>
<pre class="moz-signature" cols="80">--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
</pre>
</div>
_______________________________________________<br class="">ARIN-PPML<br class="">You are receiving this message because you are subscribed to<br class="">the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" class="">ARIN-PPML@arin.net</a>).<br class="">Unsubscribe or manage your mailing list subscription at:<br class=""><a href="https://lists.arin.net/mailman/listinfo/arin-ppml" class="">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">Please contact info@arin.net if you experience any issues.<br class=""></div></blockquote></div><br class=""></div></body></html>