[arin-ppml] Draft Policy ARIN-2019-18: LIR/ISP Re-Assignment to Non-Connected Networks

[David Farmer]

So working on this a bit more, I suggest the following policy text;

Add to the end of section 2.4;

LIRs may also assign address space to other organizations or customers that
request it for use in operational networks.

Change section 8.5.2 as follows;

ARIN allocates or assigns number resources to organizations via transfer
solely for the purpose of use in operational networks.

Delete all but the first two sentences of 4.2.3.3, leaving;

4.2.3.3. Contiguous Blocks

IP addresses are allocated to ISPs in contiguous blocks, which should
remain intact. Fragmentation of blocks is discouraged

This text makes an editorial change to the text to be added to 2.4,
restores the original text of 8.5.2, making an editorial change to it that
is consistent with the editorial change made the new 2.4 and delete most of
4.2.3.3 as that text is impractical given today realities. The editorial
changes remove the possible implication that use is required in any
particular operational network, such as the LIR's or the providers network.

Thanks


On Tue, Oct 1, 2019 at 5:13 PM David Farmer <farmer at umn.edu> wrote:

> Because of an off-list conversation I'd like to add I think the
> expectations of RFC2008 still exist in our policy manual today;
>
>
> 4.2.1.1. Purpose
>
> ARIN allocates blocks of IP addresses to ISPs for the purpose of
> reassigning and reallocating that space to *their customers.*
>
> 4.2.3.3. Contiguous Blocks
>
> IP addresses are allocated to ISPs in contiguous blocks, which should
> remain intact. Fragmentation of blocks is discouraged. To avoid
> fragmentation, *ISPs are encouraged to require their customers to return
> address space if they change ISPs.* *Therefore, if a customer moves to
> another service provider or otherwise terminates a contract with an ISP, it
> is recommended that the customer return the network addresses to the ISP
> and renumber into the new provider’s address space.* The original ISP
> should allow sufficient time for the renumbering process to be completed
> before requiring the address space to be returned.
>
>
> Now ARIN's ability to enforce this is very limited, since ISPs can
> make reassignments entirely by their own policy without any ARIN review
> against NRPM today, we even eliminated ARIN review of large reassignments.
> So, I'm not sure a policy change is actually required, as there is noting
> ARIN can do about address leases absent connectivity when they are made as
> reassignments.
>
> However, I think clarifying that leases without connectivity are valid and
> are documented with reassignments and reallocations might return some peace
> and quiet to PPML
>
> Also maybe everything after the second sentence of 4.2.3.3 should be
> deleted as impractical in a post-free-pool world. That is "To avoid
> fragmentation..."
>
> Thanks.
>
> On Tue, Oct 1, 2019 at 4:02 PM Scott Leibrand <scottleibrand at gmail.com>
> wrote:
>
>> +1 to everything David just said.
>>
>> Do y'all have what you need to draft another version of this proposal
>> tightening up the language to be consistent with this? Or does someone here
>> need to propose text?
>>
>> -Scott
>>
>> On Tue, Oct 1, 2019 at 1:32 PM David Farmer <farmer at umn.edu> wrote:
>>
>>>
>>> On Tue, Oct 1, 2019 at 9:50 AM Scott Leibrand <scottleibrand at gmail.com>
>>> wrote:
>>>
>>>> Should we make 2019-18 clearly say that reallocation or reassignment to
>>>> non-connected networks who will themselves make operational use of the
>>>> leased addresses is considered efficient use? Basically, keep the “use”
>>>> requirement around reassignments the same as it is now, and just state
>>>> clearly that non-connected reassignments are ok?
>>>>
>>>> Scott
>>>>
>>>
>>> I support language like this, but I do not support removal of the "use"
>>> requirement, someone has to be using the addresses, if not there is no
>>> basis for an assignment or allocation, or reassignment or reallocation.
>>>
>>> Furthermore, RFC2008 introduced the address lending model, and this has
>>> been the primary model of acquiring address space for regular users ever
>>> since. RFC2008 does expects the relationship to be more than just for
>>> address space, it expects connectivity is being provided as well.
>>> Furthermore, that the address will be returned when the connectivity
>>> ceases.  However, the reason for this is aggregation, if the user of the
>>> address space isn't connected then the provider can't aggregate.
>>>
>>> However, in a world without a free-pool aggregation as a primary concern
>>> has effectively gone out the window. We are now routing ever smaller bits
>>> and pieces of address space, we have to, it's called recycling. Further, we
>>> have decided that routing policy is not ARIN or the other RIR's business,
>>> and aggregation is routing policy. Therefore address space as the only
>>> relationship between the leasor and leasee, while not ideal, it is
>>> impractical for this to be a policy violation any longer.
>>>
>>> If I've been using address space for years and I want to change my
>>> provider and my provider is willing to allow me, probably for a fee, to
>>> keep using the address space they have loaned me for years, the facts on
>>> the ground today make it impractical for this to be a policy violation.
>>> Further, it that isn't a policy violation, then a new address only lease
>>> transaction shouldn't be either.
>>>
>>> Guys we live is a post-free-pool world some ideas have to change with
>>> the facts on the ground.  Address leasing absent connectivity is a fact of
>>> life in a post-free-pool world.
>>> That doesn't mean I willing to give up on some kind of basic "use"
>>> requirement, again someone has to be using the addresses, if not there is
>>> no basis for an assignment or allocation, or a reassignment or reallocation
>>> either.
>>>
>>> Thanks
>>>
>>> --
>>> ===============================================
>>> 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
>>> ===============================================
>>>
>>
>
> --
> ===============================================
> 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
> ===============================================
>


-- 
===============================================
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
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20191001/ebb9db76/attachment.htm>