It’s more a matter of the nature of CMTS systems. Bottom line, there are way more /12s than there are (or can be) Comcast sized ISPs, so I’m really not seeing that need as a problem.
Owen > On Jan 6, 2023, at 01:20, John Santos <[email protected]> wrote: > > So, if I did the math right, Comcast has about 70,000,000,000 residential > customers? That's ten /48 sites for every person on Earth, and they are ALL > Comcast customers? > > Maybe they shouldn't structure their IPv6 network exactly the same as their > IPv4 network? > > > On 1/6/2023 2:25 AM, Owen DeLong via ARIN-PPML wrote: >>>> On Jan 5, 2023, at 08:45, David Conrad <[email protected]> wrote: >>> >>> On Jan 4, 2023, at 5:18 PM, William Herrin <[email protected]> wrote: >>>> On Wed, Jan 4, 2023 at 5:10 PM David Conrad <[email protected]> wrote: >>>>> On Jan 4, 2023, at 2:32 PM, William Herrin <[email protected]> wrote: >>>>>> However, since /48 is also the minimum Internet routable size, >>>>> Sorry, what? Out of 172,457 IPv6 prefixes seen at AMSIX (according to >>>>> routeviews) on 2023-01-01, counts of prefixes longer than 48: >>>> Sorry, I didn't realize I'd be called out for insufficient pedantry. >>> >>> You’re aware you’re on the Internet, right? >>> >>>> The minimum IPv6 size _ubiquitously accepted_ into folks' Internet BGP >>>> tables is /48. As with IPv4's /24 boundary, some folks accept longer >>>> prefixes. As with IPv4, -some- is not enough. >>> >>> “Ubiquitous". Like /24 in IPv4 was ubiquitous until Sprint (the 800 lbs >>> gorilla at the time) started filtering at /19? The point being that >>> arbitrary boundaries are overly simplistic: there aren’t hard rules here, >>> only local policy. But you know this. >> SPRINT’s attempt to filter at /19 lasted, what, a few months before they >> were forced to back down? >> The /24 arbitrary boundary has pretty well stood the test of time as, I >> suspect, will the /48. >>> >>> Anyhow, back to the original question: >>> >>> On Wed, Jan 4, 2023 at 11:52 AM Fernando Frediani <[email protected] >>> <mailto:[email protected]>> wrote: >>>> >>>> I always found a bit strange (not only in ARIN) to have this distinction >>>> between ISP and End-user. In practice things should not differ much. Only >>>> thing that would possible remain slightly different are the details of >>>> justifications that must be provided and the size of the block to be >>>> allocated. >>>> >>> In practice, ISPs tend to grow much more and more quickly than end user >>> networks. >>>> >>>> Another thing that I wanted to understand better is the reasoning to >>>> allocate a significant smaller IPv6 block to a said end-user organization >>>> given it is not so scarce resource. At least a /40 should be minimal >>>> default for an end-user (not a /48) and a /32 for any size of ISP. >>>> >>> You might want to look at RFC 6177. >> I think a /48 per site is a perfectly reasonable basis for assignments. >> There may be sties that need more, but they are likely to be few and far >> between and there are procedures to take care of them. Note: Many end users >> are multiple sites. An end site is defined (IIRC from what I wrote when >> authoring the ARIN policies that are still in effect to the best of my >> knowledge): >> A single building or structure or a single tenant in a multi-tenant building >> or structure. >> If that’s not the exact correct wording, it’s close and mirrors the intended >> meaning. >>>> For now my personal impression is to create some artificial scarcity in >>>> order to have different levels of Service Category. >>>> >>> Never attribute to malice what can be more easily explained by inertia. >> I once had this discussion with John Brzowski of Comcast. His excuse was “If >> we gave everyone /48s, the way our network is structured, we’d have to ask >> ARIN for a /12. He felt this was a reason not to. I wondered why. I never >> got an answer. >> So I would say never attribute to malice that which can be easily explained >> by lack of imagination. >> 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. > > -- > 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 ([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. _______________________________________________ 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.
