[arin-ppml] Draft Policy ARIN-2019-19: Require IPv6 Before Receiving Section 8 IPv4 Transfers

Thu Nov 7 20:05:42 EST 2019

David posted the main issues about the policy:
>The questions at hand are whether or not this policy;
> 1. Enables Fair and Impartial Number Resource Administration
My take from the discussion so far is no.
> 3. And, is Supported by the Community
Apparently not.
> In short, is this a good policy?
It really does not matter if there is no substantial community support.

José R. de la Cruz
jrdelacruz at acm.org

On Thu, Nov 7, 2019 at 8:17 PM David Farmer <farmer at umn.edu> wrote:

> 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.
>
> 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.
>
> The questions at hand are whether or not this policy;
>
>    1. Enables Fair and Impartial Number Resource Administration
>    2. Is Technically Sound
>    3. And, is Supported by the Community
>
> 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.
>
> Let's continue the discussion.
>
> Thanks.
>
> On Thu, Nov 7, 2019 at 4:40 PM Fernando Frediani <fhfrediani at gmail.com>
> wrote:
>
>> 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".
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> Regards
>> Fernando
>>
>> On Thu, 7 Nov 2019 16:06 Brett Frankenberger, <rbf+arin-ppml at panix.com>
>> wrote:
>>
>>> On Wed, Nov 06, 2019 at 12:55:50PM -0500, ARIN wrote:
>>> > On 1 November 2019, the ARIN Advisory Council (AC) accepted
>>> "ARIN-prop-278:
>>> > Require IPv6 Before Receiving Section 8 IPv4 Transfers" as a Draft
>>> Policy.
>>> >
>>> > Draft Policy ARIN-2019-19 is below and can be found at:
>>> >
>>> > Policy statement:
>>> >
>>> > In section 8.5.2, add the following language to the end of the
>>> paragraph
>>> > entitled “Operational Use”:
>>> >
>>> > Such operational network must at minimum include an allocation or
>>> assignment
>>> > by ARIN of IPv6 address space under the same Org ID receiving the
>>> > transferred IPv4 space. Such Org must be able to prove this IPv6 space
>>> is
>>> > being routed by using it to communicate with ARIN.
>>> >
>>> > In the event the receiver provides a written statement from its
>>> upstream
>>> > that IPv6 connectivity is unavailable, the IPv6 requirement may be
>>> waived.
>>>
>>> Opposed for multiple reasons.
>>>
>>> First, it should not be ARINs role to dictate the manner in which
>>> networks are operated.  We have routinely resisted the notion that, for
>>> example, spammers should have resources revoked.  Now we're proposing
>>> to deny resources to networks that decide not to operate IPv6.
>>>
>>> Second, the proposal is premised on the idea that IP addresses are
>>> solely allocated for the purpose of operation on the public network,
>>> despite policy being clear that that's not the case.  While that's
>>> certainly the predominate use case, there is nothing that prevents a
>>> private interconnected network from operating on
>>> ARIN-assigned/allocated public space without connecting to the
>>> Internet.  Are we proposing to deny any future transfers for such
>>> networks?  They would by their nature be unable to prove IPv6
>>> connectivity to ARIN (except as a stunt -- see below) and would be
>>> unable to get a statement from their upstream (since they would have
>>> none) as to the availability of IPv6 connectivity.
>>>
>>> Third, this encourages meaningless stunts.  A network that does not
>>> desire to opreate V6 is not going to reconsider that decision as a
>>> result of this policy.  At best, they will get an IPv6 allocation or
>>> assignment from ARIN, route it to one subnet, put a device on it long
>>> enough to perform whatever ceremony ARIN requires to prove IPV6
>>> connectivity, get their transfer, and then shut it down (or maybe leave
>>> it there in case they have to reperform the ceremony should they
>>> transfer additional addresses in the future).  More likely, this will
>>> cause the creation of a new industry: organizations needing to complete
>>> an IPv6 connectivity validation to get a IPv4 transfer processed will
>>> sign a LOA granting their Ceremony Consultant the right to announce
>>> their IPv6 allocation/assignment long enough to complete the ceremony,
>>> and their consultant will do all the work necessary to get the required
>>> box checked in ARIN's systesm.
>>>
>>> This will not drive IPv6 adoption.  I oppose the use of ARIN or
>>> community resources on stunts, and I oppose the creation of a "IPv6
>>> Ceremony Consultant" industry.
>>>
>>>      -- Brett
>>> _______________________________________________
>>> ARIN-PPML
>>> 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:
>>> https://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>>
>> _______________________________________________
>> ARIN-PPML
>> 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:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>
>
> --
> ===============================================
> David Farmer               Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> _______________________________________________
> ARIN-PPML
> 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:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20191107/52a05ef0/attachment.htm>