[arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

Wed Apr 15 09:38:27 EDT 2020

Hi Lisa,

Thank you.
So a single organization can do multiple swaps within 12 months.

In practice we sometimes see /16 sellers who need to keep some of their block, but in doing so will lose money as the per-address price is higher for contiguous /16s. Many times they want to keep just a /24 and that atomizes the rest of the /16.
They could do the separate ORG workaround and purchase a /24, but if the buyer has other blocks, that buyer could offer a /24  to the /16 seller in a swap, and buy the contiguous /16. 

Might be rare, but nice to know about, thanks again.

Regards,
Mike

-----Original Message-----
From: Lisa Liedel <lliedel at arin.net> 
Sent: Wednesday, April 15, 2020 9:05 AM
To: Mike Burns <mike at iptrading.com>; John Sweeting <jsweeting at arin.net>; arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

Hi Mike,

The 12 month waiting period is not imposed at the time of the block swap. However, any policy restrictions the organizations previously had will still be applicable if a block swap is approved. 

One additional note for clarification, the 12 month waiting period is when a Recipient of a transfer must wait for 12 months before they can transfer anything out, or become a Source. However, an organization can receive multiple transfers in a 12 month period.

Regards,

Lisa

On 4/15/20, 8:05 AM, "ARIN-PPML on behalf of Mike Burns" <arin-ppml-bounces at arin.net on behalf of mike at iptrading.com> wrote:

    Hi John,

    Thank you.
    Are they both then subject to the 12 month waiting period before another receipt?

    Regards,
    Mike

    -----Original Message-----
    From: John Sweeting <jsweeting at arin.net> 
    Sent: Tuesday, April 14, 2020 6:36 PM
    To: Mike Burns <mike at iptrading.com>; arin-ppml at arin.net
    Subject: Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

    Sure Mike, they are approved on a case-by-case basis as described below:

    Blocks swaps are conducted via 8.3 Specified Recipient Transfer process. Both parties need to submit two tickets each; a Source ticket to release a block and a Recipient to receive the other block. All four tickets need to be submitted and reviewed by the Director of RSD before approval. It is strongly recommended notation is made in each ticket that it is related to a block swap.

    Note that their cannot be a net gain for either organization. 

    On 4/14/20, 5:43 PM, "Mike Burns" <mike at iptrading.com> wrote:

        Hi John,

        Thanks for sharing the policy report.
        How do we do a block swap?
        Can you provide some more details on that process and its requirements?

        Regards,
        Mike

        -----Original Message-----
        From: ARIN-PPML <arin-ppml-bounces at arin.net> On Behalf Of John Sweeting
        Sent: Tuesday, April 14, 2020 5:29 PM
        To: arin-ppml at arin.net
        Subject: Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

        All,

        For anyone interested in the content of the "Policy Experience Report presented by Registration Services to the AC at its annual workshop in January 2020" referenced in the problem statement you can see that report here:

        https://www.arin.net/about/welcome/ac/meetings/2020_0124/policy_experience_report.pdf

        Thank you.

        On 3/24/20, 1:22 PM, "ARIN-PPML on behalf of ARIN" <arin-ppml-bounces at arin.net on behalf of info at arin.net> wrote:

            On 19 March 2020, the ARIN Advisory Council (AC) accepted 
            "ARIN-prop-285: IPv6 Nano-allocations" as a Draft Policy.

            Draft Policy ARIN-2020-3 is below and can be found at:

            https://www.arin.net/participate/policy/drafts/2020_3/

            You are encouraged to discuss all Draft Policies on PPML. The AC will 
            evaluate the discussion in order to assess the conformance of this draft 
            policy with ARIN's Principles of Internet number resource policy as 
            stated in the Policy Development Process (PDP). Specifically, these 
            principles are:

            * Enabling Fair and Impartial Number Resource Administration
            * Technically Sound
            * Supported by the Community

            The PDP can be found at:
            https://www.arin.net/participate/policy/pdp/

            Draft Policies and Proposals under discussion can be found at:
            https://www.arin.net/participate/policy/drafts/

            Regards,

            Sean Hopkins
            Policy Analyst
            American Registry for Internet Numbers (ARIN)

            Draft Policy ARIN-2020-3: IPv6 Nano-allocations

            Problem Statement:

            ARIN's fee structure provides a graduated system wherein organizations
            pay based on the amount of number resources they consume.

            In the case of the very smallest ISPs, if a 3X-Small ISP (with a /24 or 
            smaller of IPv4) gets the present minimal-sized IPv6 allocation (a /36), 
            its annual fees will double from $250 to $500/year.

            According to a Policy Experience Report presented by Registration 
            Services to the AC at its annual workshop in January 2020, this 
            represents a disincentive to IPv6 adoption with a substantial fraction 
            of so-situated ISPs saying "no thanks" and abandoning their request for 
            IPv6 number resources when informed of the impact on their annual fees.

            This can be addressed by rewriting subsection 6.5.2(b). Initial 
            Allocation Size to allow allocation of a /40 to only the smallest ISPs 
            upon request, and adding a new clause 6.5.2(g) to cause an automatic 
            upgrade to at least a /36 in the case where the ISP is no longer 3X-Small.

            Reserving /40s only for organizations initially expanding into IPv6 from 
            an initial sliver of IPv4 space will help to narrowly address the 
            problem observed by Registration Services while avoiding unintended 
            consequences by accidentally giving a discount for undersized allocations.

            Policy Statement:

            Replace the current 6.5.2(b) with the following:

            b. In no case shall an LIR receive smaller than a /32 unless they
            specifically request a /36 or /40.

            In order to be eligible for a /40, an ISP must meet the following 
            requirements:
              * Hold IPv4 direct allocations totaling a /24 or less (to include zero)
              * Hold IPv4 reassignments/reallocations totaling a /22 or less (to 
            include zero)

            In no case shall an ISP receive more than a /16 initial allocation.

            Add 6.5.2(g) as follows:

            g. An LIR that requests a smaller /36 or /40 allocation is entitled to 
            expand the allocation to any nibble aligned size up to /32 at any time 
            without renumbering or additional justification.  /40 allocations shall 
            be automatically upgraded to /36 if at any time said LIR's IPv4 direct 
            allocations exceed a /24. Expansions up to and including a /32 are not 
            considered subsequent allocations, however any expansions beyond /32 are 
            considered subsequent allocations and must conform to section 6.5.3. 
            Downgrades of any IPv6 allocation to less than a /36 are not permitted 
            regardless of the ISP's current or former IPv4 number resource holdings.

            Comments:

            The intent of this policy proposal is to make IPv6 adoption at the very 
            bottom end expense-neutral for the ISP and revenue-neutral for ARIN. The 
            author looks forward to a future era wherein IPv6 is the dominant 
            technology and IPv4 is well in decline and considered optional leading 
            the Community to conclude that sunsetting this policy is prudent in the 
            interests of avoiding an incentive to request undersized IPv6 allocations.

            Timetable for implementation: Immediate

            _______________________________________________
            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.

    _______________________________________________
    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.