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

[Owen DeLong]

> On Apr 18, 2020, at 22:20 , Fernando Frediani <fhfrediani at gmail.com> wrote:
> 
> On 19/04/2020 01:38, David Farmer wrote:
>> I support this policy as written, as I said previously, I recommend a couple of changes, but I won't repeat the details of those changes here.
>> 
>> Regarding the current discussion of /48 assignments to residential customers, that is the architecture as defined by the IETF, and ARIN policy MUST NOT create situations where its necessary or that incentivizes ISPs to make assignments longer than /48. Further, this policy is at least minimally consistent with the IPv6 architecture, and /48 IPv6 assignments, when considering a 3X-Small ISP, with a /24 of IPv4 and a /40 of IPv6, both address families will reasonably support 250 or fewer customers.
> Can you please quote exactly where IETF defines that way ? 
> 
> RFC6177 in its abstract says: "RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases.  The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005. This document obsoletes the RFC 3177 recommendations on the  assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is an issue for the operational community.  The IETF's role in this case is limited to providing guidance on IPv6 architectural and operational considerations."
> 
> ...
> "This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original recommendations in RFC 3177. Moreover, this document clarifies that a one-size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default.”

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.

>> The number of customers and the size of IPv6 customer assignments actually deployed in reality are outside the scope and control of ARIN, the other RIRs, and even the IETF. It is solely in the scope and control of the ISP deploying a network. Furthermore, RFC 6177 recognizes longer end-site assignments between /48 and /64 could be reasonable.
> Recognizes as an exception and it clearly states that is not the recommendation anymore, talks about all the issues and why it was reviewed and mentions that if someone justify can get it, so as an exception.
> 
It recognizes LONGER assignments as an exception, yes. It does not clearly state that /48 is no longer the recommendation.

Specifically:
Moreover, this document clarifies that a one-size-fits-all
   recommendation of /48 is not nuanced enough for the broad range of
   end sites and is no longer recommended as a single default.


Recognizes that perhaps there are some end sites where a /48 does not necessarily make sense. At the time of writing, IIRC, the major target of this was cell phones.

Residential end users remained controversial throughout the discussion and there was never a consensus reached (one of the main reasons 6177 uses so much weasel wording) for longer prefix assignments to residential end sites.
> Given all above I cannot agree and have the same view that /48 to residential customers indistinctly is a normal thing and that RIRs should necessarily adapt to allow ISPs to make these assignments the way is being suggested in this discussion.
> 
I’m sorry, I cannot parse your actual intent from this statement. Can you try rewording it?

Section 2 basically states that if you ignore the goals of automated hierarchy, you can fudge home sites down to /56 and still meat the remaining goals. It narrowly interprets RFC3177 and ignores any use cases not previously documented in that RFC.

Section 4.1 all but admits that any site using RFC3056 addressing and sparse allocation (also recommended back then and still good practice today) would potentially be negatively impacted by longer assignments.

Section 5 is worth a read, tooo.

	- Although a /64 can (in theory) address an almost unlimited
        number of devices, sites should be given sufficient address
        space to be able to lay out subnets as appropriate, and not be
        forced to use address conservation techniques such as using
        bridging.  Whether or not bridging is an appropriate choice is
        an end site matter.

      - assigning a longer prefix to an end site, compared with the
        existing prefixes the end site already has assigned to it, is
        likely to increase operational costs and complexity for the end
        site, with insufficient benefit to anyone.

 - the operational considerations of managing and delegating the
        reverse DNS tree under ip6.arpa on nibble versus non-nibble
        boundaries should be given adequate consideration.


Admittedly, these don’t argue specifically for /48 (except possibly the middle one when it comes to customers moving from ISPs that do give out /48s to ISPs that don’t).

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.

Owen

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