I’ll admit to having skimmed some of this thread, so apologies in advance if I've missed prior discussion of the point below.
The guidance against assigning /48s by default described in RFC6177 made sense at the time, particularly for an individual residential subscriber site, given the assumption that a residential site would rarely, if ever, have a second layer of L3 forwarding beyond the broadband router - that is, each /64 within the customer’s allocation would be attached to the edge gateway (i.e. multiple VLANs, WiFi SSIDs with L3 separation, etc.) In that world, allowing 65K unique /64s gateways to exist on a home broadband router was rightly seen as unnecessarily wasteful, regardless of sparse addressing design patterns. As is, even the 256 /64 prefixes in the /56 I can route to my broadband edge device seems like overkill, and I’d like to think I’m much savvier than the typical residential subscriber :) That said, RFC8273, published 6 years after 6177, now recommends that instead of assigning individual /128s to hosts within a shared /64, prefix delegation should be utilized instead to assign a /64 *per host* by default within an IPv6 network. This practice unlocks the ability for any end host to become a downstream “virtual” L3 router, allowing individually addressed software components to be uniquely addressed within a host (obvious candidates here would be virtual machines and docker containers, but also individual servers or clients living on the host), all numbered from a /64 with a known physical* location for policy/security purposes. Given this recommendation, I believe it absolutely makes sense now to standardize as best practice the default assignment of a /48 to even residential subscribers, given that IETF-codified best practices now recommend exactly that two-layer routing model that the lack of which provided the original justification for RFC6177. (Side note: Happy to work with any interested parties on a new RFC re-codifying the recommendations from RFC3177, informed by 8273, and obsoleting 6177 given the above). Thanks, -Chris *Yes, I’m aware the host itself could be virtual as well. Turtles all the way down, folks. > On Apr 19, 2020, at 10:28 AM, John Santos <j...@egh.com> wrote: > > 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@arin.net >> <mailto:ARIN-PPML@arin.net>). >> Unsubscribe or manage your mailing list subscription at: >> https://lists.arin.net/mailman/listinfo/arin-ppml >> <https://lists.arin.net/mailman/listinfo/arin-ppml> >> Please contact i...@arin.net <mailto:i...@arin.net> if you experience any >> issues. > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues.
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
