[arin-ppml] Solving the squatting problem

[Owen DeLong]

> On May 16, 2019, at 7:53 PM, Michel Py <michel at arneill-py.sacramento.ca.us> wrote:
> 
>> Mark Andrews wrote :
>> 240/4 isn’t ARIN’s to allocate or do you think ARIN should squat on the space? :-)
> 
> I was trying to find a more politically correct way to say it ;-)
> Look, you give me lemons, I make lemonade.
> 
> How did we call that, when ARIN started to allocate IPv6 PI when no such thing existed ? There was quite a bit of artistic license taken then. IPv6 PI was not ARIN to allocate either.

Incorrect.

IPv6 unicast addresses were allocated to ARIN for allocation and assignment. The addresses were in ARIN inventory and there was an erroneous view that IETF had authority to dictate registration policy for those addresses.

ARIN’s IPv6 PI policy was entirely about how ARIN managed address inventory in the ARIN registry and did not require IETF blessing or approval.

IETF handed off 2000::/3 to IANA to manage as the RIRs see fit through the global policy development process (which currently requires the same policy to be approved by each RIR’s individual PDP followed by some work by the ASO-AC/NRO-NC to finalize it through the ICANN/IANA process).

After that, ARIN obtained some IPv6 blocks form IANA within 2000::/3 (namely 2001:400::/23, 2001:1800::/23, 2001:4800::/23, 2600::/12, 2610::/23, 2620::/23) for ARIN to manage according to ARIN policies.

240/4 is still in “reserved for future use” status in the IANA registry and asunder authority of the IETF per RFC1112.

So, while it’s in the IANA registry, it’s not clear that IANA has any authority to make any determination about its status without IETF blessing. Certainly, IANA has not so far and is unlikely to allocate it to ARIN without significant changes to the current situation.

These are very very different circumstances between the IPv6 PI policy (you’re welcome, by the way) and 240.0.0.0/4.

> 
> 
>> David Farmer wrote :
>> I suppose we could try a global policy that would have to pass in all 5 RIRs requesting IANA
>> and the IETF to allocate 240/4 for Private Use. If that were to actually occur, it seems
>> difficult for the IETF to ignore such a request. While on the other hand, I'm not sure there
>> would be a consensus within the ARIN community, let alone the other RIRs, to do such a thing anyway.
> 
> There is definitely something about tilting at a windmill here; I'm just trying to think out of the box.
> We have a problem with some ARIN members using address space that has been allocated to other ARIN members and we know it.

Yes, but in most of the cases where it’s actually a problem, it involves hijacking and not squatting.[1]

Squatting is kind of like gnats. We’d prefer not to have them, but calling them a problem kind of inflates the impact beyond reality.


> I think there will be a consensus that ARIN has absolutely no stick to make them stop, so what we need is a carrot.
> Mine is not very palatable, but maybe it would be more attractive to ARIN members who squat by providing them an exit than to the IETF.

You say we need a carrot, then suggest ARIN offer a semi-rotted clove of garlic that belongs to someone else saying “look… A carrot!” claiming this is an improvement to the current situation. 

> Do you have a better suggestion ? The squatting issue is new, what does ARIN do about it ?

The squatting “issue” isn’t new, and I’m not entirely convinced it’s an issue, either.

I think the better suggestion is recognize that IPv4 is a quagmire and will never stop being a quagmire, work towards a better IPv6 future and eventually, allow said quagmire to fade into the annals of history.

>> Nevertheless, there is no way for ARIN to unilaterally allocate 240/4 for any purpose.
> 
> I beg to disagree. It could be an experimental purpose. Sounds like the product of buffalo rumination, but policy is sometimes about untold nuances.

Um, unless I misread many things, including RFC1112 and the IANA registry, no, ARIN would need IETF and IANA consent to begin allocating 240/4 for any purpose.

Owen

[1]  I define hijacking as the public announcement of a prefix by an entity which is not the registrant and does not have the consent of the registrant. I define squatting as the internal use (without public announcement) by an entity of a prefix for which it is not the registrant and does not have the permission of the registrant.