> On Apr 18, 2020, at 22:20 , Fernando Frediani <[email protected]> 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
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
