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

[John Santos]

Policy should not prohibit doing what many regard as best practice.  Just 
because SOME ISPs might find a /48 unnecessarily large doesn't mean that ALL 
will, or that the recommendation of a /48 is always WRONG and that nano-ISPs 
should be punished (financially) for doing so.

There is obviously a huge scaling issue with fees, when a giant ISP is paying 
less than a penny per year for addresses and a very small ISP is paying close to 
a dollar per year, but I don't think we can fix that with policy.  But we can 
make it less worse by allowing the tiniest ISPs to allocate what they need and 
not orders of magnitude more than they need at exponentially larger cost.

Is there any way to ensure that an ISP requesting a /40 has fewer than 250 
customers, so they can assign each a /48 in order to be eligible for the 
smallest allocation at commensurate cost with a /24 of IPv4?

On 4/19/2020 11:33 AM, Fernando Frediani wrote:
> On 19/04/2020 05:07, Owen DeLong wrote:
>>
>> Right… IETF designed a good architecture and then came under pressure from a 
>> bunch of people with an IPv4 mindset and given the modern state of the IETF 
>> decided to just punt on the whole thing rather than waste more time on an 
>> argument where people were determined to do what they were going to do 
>> anyway. RFC 6177 is more of a cop-out than a legitimate standards document.
> We cannot just choose the RFCs we will follow from those we like and disregard 
> those which we don't. Imagine if vendors start to do the same !
>
> Since it correctly (in my view) does putting that /48 for residential 
> customers should be treated as an exception therefore no RIRs should have to 
> adapt their policies to it. If ISPs assign /48 to these customers in 
> exceptional basis (not as default) then they would have less or none of of the 
> problems discussed here.
>
> <clip>
>
>>
>> There’s absolutely noting in RFC6177 that says /48s should not be given out 
>> to residential customers. It punts it to the operational community and says 
>> it really shouldn’t
>> be up to the IETF. That’s generally true, but that does come with a 
>> responsibility that the operational community doesn’t arbitrarily create 
>> negative impacts without good
>> reason.
> One of the main points of the document, if not the most, is that /48 is no 
> longer the default and not recommended as well. Therefore if it still possible 
> to assign to a residential customer it should then be considered an exception 
> not a normal thing as the others.
> Let me quote an important part of it within section 2: "/Hence, it is strongly 
> intended that even home sites be given multiple subnets worth of space, by 
> default.  Hence, this document still recommends giving home sites 
> significantly more than a single /64, but does not recommend that every home 
> site be given a /48 either./"
>
> Furthermore at the time of the write of the document it also mentions: "Since 
> then, APNIC [APNIC-ENDSITE], ARIN [ARIN-ENDSITE], and RIPE [RIPE-ENDSITE] have 
> revised the end site assignment policy to encourage the assignment of smaller 
> (i.e., /56) blocks to end sites.". Although some of these might have been 
> retired in their manuals it is possible to notice the spirit of  the change 
> RFC6177 brings, and is still valid.
>
> Regards
> Fernando
>
>
> _______________________________________________
> 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.

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20200419/8bd78630/attachment.htm>