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

[Owen DeLong]

> On Apr 19, 2020, at 08:33 , Fernando Frediani <fhfrediani at gmail.com> 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 !

The RFC you are holding out as gospel states that it is a BCOP, not a standards track document.

It also supports /48s while admitting that other choices are available.

Your characterization of my attitude is not correct, sir.

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

It does NOT make /48s for residential customers an exception. Please show any language which does so. It states that longer than /48s are possible without structural harm to IPv6 itself. That’s as far as it goes.

You’re also wrong about the nature of the problem being discussed.

ISPs cannot under current policy obtain an allocation smaller than a /36. The policy language here would make /40s available (on an exceptional basis).

As such, the concern is not to turn reduced price /40s into an incentive for bad addressing policy. You may think that the bad addressing policy I advocate avoiding is good address policy, but, that doesn’t change the nature of the initial problem in any way and is orthogonal to it.

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

That’s _NOT_ what it says.

It says that /48 no longer needs to be a one-size-fits-all default.

It goes no further than that. It does not advocate for longer prefixes, it merely says that they could be acceptable or desirable in some cases and that the decision is left to the operational community and no longer a matter for the IETF.

> 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.
> 
ARIN has never had a policy that encouraged the assignment of smaller blocks to end sites. Currently ARIN most definitely has policy language that is intended to (admittedly subtly) encourage the assignment of /48s to end sites.

Owen

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