<div dir="ltr"><div>In my opinion, this policy is saying that people can't grow their IPv4 network unless they can demonstrate IPv6 capabilities. If you need to grow your IPv4 network, this policy seems somewhat coercive, at least to me. Yes, you can decide not to grow your IPv4 network, in that technical sense it's optional.  However, if you need to grow your IPv4 network, doing so doesn't usually seem all that optional, and neither is complying with this policy if you need to grow your IPv4 network and the policy is adopted. So, if you need to grow your IPv4 network, saying this policy forces you to do IPv6 doesn't seem completely out of line.</div><div><br></div><div>Yes, this is a valid policy proposal and threats to sue over it should be ignored at least at this point. Further along in the process, ARIN will provide a Staff and Legal Review which will analyze any legal risk. If there is any legal risk called out, that will need to be considered carefully, but we are not at that point yet.</div><div><br></div><div>The questions at hand are whether or not this policy;</div><ol><li>Enables Fair and Impartial Number Resource Administration</li><li>Is Technically Sound</li><li>And, is Supported by the Community</li></ol><div><div>In short, is this a good policy? You provided some reasons why you think it is a good policy, others, including me, have provided reasons why they think it is not a good policy. </div><div><br></div><div>Let's continue the discussion.</div><div><br></div>Thanks.</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 7, 2019 at 4:40 PM Fernando Frediani <<a href="mailto:fhfrediani@gmail.com">fhfrediani@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"><div dir="auto"><div>I wanted to kindly request AC members attention to all objections based on the argument that "ARIN is forcing someone to do something on their own network".</div><div dir="auto"><br></div><div dir="auto">This is NOT true at all and not the propose of this proposal therefore I believe these kind of objections have been refuted multiple times already.</div><div dir="auto"><br></div><div dir="auto">With regards the proposal this community has the right to estabilish whatever conditions for the RIR registration related stuff it finds better for the RIR and the Internet to continue working healthy in the region.</div><div dir="auto"><br></div><div dir="auto">For example the increasing cost imposed to all others by those who wishes to remain in the past and the growing conflicts due to the current scenario are good point for this community to evaluate.</div><div dir="auto"><br></div><div dir="auto">Also I am finding some people having trouble with the mechanism to validate IPv6 is operational and would really like to hear other points of view about more effective way that process can be validaded and be more effective in their point of view.</div><div dir="auto"><br></div><div dir="auto">Regards</div><div dir="auto">Fernando</div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Thu, 7 Nov 2019 16:06 Brett Frankenberger, <<a href="mailto:rbf%2Barin-ppml@panix.com" target="_blank">rbf+arin-ppml@panix.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">On Wed, Nov 06, 2019 at 12:55:50PM -0500, ARIN wrote:<br>
> On 1 November 2019, the ARIN Advisory Council (AC) accepted "ARIN-prop-278:<br>
> Require IPv6 Before Receiving Section 8 IPv4 Transfers" as a Draft Policy.<br>
> <br>
> Draft Policy ARIN-2019-19 is below and can be found at:<br>
> <br>
> Policy statement:<br>
> <br>
> In section 8.5.2, add the following language to the end of the paragraph<br>
> entitled “Operational Use”:<br>
> <br>
> Such operational network must at minimum include an allocation or assignment<br>
> by ARIN of IPv6 address space under the same Org ID receiving the<br>
> transferred IPv4 space. Such Org must be able to prove this IPv6 space is<br>
> being routed by using it to communicate with ARIN.<br>
> <br>
> In the event the receiver provides a written statement from its upstream<br>
> that IPv6 connectivity is unavailable, the IPv6 requirement may be waived.<br>
<br>
Opposed for multiple reasons.<br>
<br>
First, it should not be ARINs role to dictate the manner in which<br>
networks are operated.  We have routinely resisted the notion that, for<br>
example, spammers should have resources revoked.  Now we're proposing<br>
to deny resources to networks that decide not to operate IPv6.<br>
<br>
Second, the proposal is premised on the idea that IP addresses are<br>
solely allocated for the purpose of operation on the public network,<br>
despite policy being clear that that's not the case.  While that's<br>
certainly the predominate use case, there is nothing that prevents a<br>
private interconnected network from operating on<br>
ARIN-assigned/allocated public space without connecting to the<br>
Internet.  Are we proposing to deny any future transfers for such<br>
networks?  They would by their nature be unable to prove IPv6<br>
connectivity to ARIN (except as a stunt -- see below) and would be<br>
unable to get a statement from their upstream (since they would have<br>
none) as to the availability of IPv6 connectivity.<br>
<br>
Third, this encourages meaningless stunts.  A network that does not<br>
desire to opreate V6 is not going to reconsider that decision as a<br>
result of this policy.  At best, they will get an IPv6 allocation or<br>
assignment from ARIN, route it to one subnet, put a device on it long<br>
enough to perform whatever ceremony ARIN requires to prove IPV6<br>
connectivity, get their transfer, and then shut it down (or maybe leave<br>
it there in case they have to reperform the ceremony should they<br>
transfer additional addresses in the future).  More likely, this will<br>
cause the creation of a new industry: organizations needing to complete<br>
an IPv6 connectivity validation to get a IPv4 transfer processed will<br>
sign a LOA granting their Ceremony Consultant the right to announce<br>
their IPv6 allocation/assignment long enough to complete the ceremony,<br>
and their consultant will do all the work necessary to get the required<br>
box checked in ARIN's systesm.<br>
<br>
This will not drive IPv6 adoption.  I oppose the use of ARIN or<br>
community resources on stunts, and I oppose the creation of a "IPv6<br>
Ceremony Consultant" industry.<br>
<br>
     -- Brett<br>
_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" rel="noreferrer" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" rel="noreferrer" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div></div></div>
_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">===============================================<br>David Farmer               <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota   <br>2218 University Ave SE        Phone: 612-626-0815<br>Minneapolis, MN 55414-3029   Cell: 612-812-9952<br>=============================================== </div></div></div>