> On Jul 11, 2017, at 23:26 , hostmas...@uneedus.com wrote: > > First of all, ALL changes to v4 have been withdrawn from this proposal. This > proposal is ONLY about v6. Currently ALL v6 requires SWIP (/64 or more) and > this is unequal with v4 that has an 8 or more address standard for SWIP. > > I think that drawing the SWIP boundary for IPv6 based upon residential/non > residential (NRPM 2.13) is wrong, as this is NOT done in IPv4 and would treat > v6 and v4 differently. Currently in v4, it is 8 or more addresses. > Residential or Non Residential does not change the SWIP requirement in IPv4 > in any way.
You are entitled to your opinion, but IPv6 _IS_ fundamentally different from IPv4. The line is drawn where it is in IPv4 because for the most part, in IPv4, it’s actually rare for a residential customer to have 8 or more addresses assigned to their service and in such cases, it’s usually not a purely residential service. Further, at the time that line was drawn for IPv4, the definition of a residential customer and the residential customer privacy policies did not exist in the NRPM. > Thus, whatever boundary is chosen for v6, I think it should be a fixed value, > just like in IPv4. I would like to hear the exact reasons why it has been > proposed that there should be a residential/non residential difference in > SWIP policy, and what this difference in policy is meant to address. If it > is a valid reason, this should carry over to IPv4. There already is a residential/non-residential difference in that residential customers are allowed to be SWIPd with limited information. Further, as I stated above, the /29 boundary was chosen primarily because it was a convenient proxy for residential vs. business utilization. > Some commenters have suggested that routeability should be a factor in > determining if SWIP is needed. In IPv4, it is not possible to route anything > smaller than a /24, but the current SWIP v4 standard is /29 or more, much > smaller than the routability standard. In IPv6, nothing smaller than a /48 > is routable, so I kinda think that IPv4 /29 is very close to equal to IPv6 > more than a /56, and also not independently routable. Trying to draw such comparisons between IPv4 and IPv6 is utterly and completely specious, generally speaking. For any parallel you can draw I can cite multiple examples where it simply doesn’t fit. The simple fact of the matter is that IPv4 is a densely allocated space with a serious shortage of addresses. IPv6 is an entirely different addressing architecture with entirely different requirements and (hopefully) entirely different management styles. > The comments I have been watching have strongly supported setting the SWIP > level for IPv6 at more than a /56. This is only one nibble away from /60 in > the current proposal. I also note that it seems quite universal that most > commenters think that a /64 is wrong, and everyone, even dynamic residential > customers deserve to have at least a /60 so that they can route packets in v6. IMHO, even dynamic residential customers deserve to have at least a /48 as is the fundamental design intention of IPv6. I realize that there are those who oppose this view, but I’m quite certain that if you research it, you will find that there are no convincing arguments favoring longer prefixes for residential. In fact, almost every argument offered favoring these longer prefixes is based almost entirely on IPv4-think (shortage mentality and conservation). In 2000::/3 (1/8th of the total IPv6 space which the IETF has currently set aside as GUA), there are 2^45 /48s. That’s 35,184,372,088,832 (35 trillion) /48s. The total population of the world is 7 Billion. So in this first 1/8th of the IPv6 space, we have enough /48s to issue 5,000 to every single person on earth. (Yes, I realize there’s also addresses needed for servers, infrastructure, etc., but I think we can take that out of the extra 4,999 /48s per person and still have room to spare). If it turns out I’m wrong and we somehow exhaust the first /3 within my lifetime, I’ll join others in advocating more conservative policy for the next /3. There are still at least 3 more empty /3s after that and 3 more nearly empty /3s beyond those. (IETF is talking about issuing addresses from a third /3 for some special purpose I forget in addition to the minimal allocations out of the end of e000::/3 (multicast, ULA, etc.) and 0000::/3 (unknown, default, loopback, IPv4 mapped, etc.)). So, while at the time of drafting, the IPv4 policy used /29 as a proxy for the distinction between business and residential and while there was concern about transparency of utilization and not wanting to allow ISPs to hide artificially large allocations by calling them residential, those issues really don’t apply in the IPv6 world. Since ARIN policy fully supports, and even encourages /48s being issued to residential customers for IPv6, I see no reason that a SWIP boundary of larger than /56 is any more desirable than a SWIP boundary of larger than /48 with the proviso that businesses should be SWIPd regardless as I fail to see a public good from privacy protections for address assignments to businesses. Owen > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > > > On Tue, 11 Jul 2017, Owen DeLong wrote: > >> >>> On May 30, 2017, at 06:41 , William Herrin <b...@herrin.us> wrote: >>> >>> On Tue, May 30, 2017 at 9:12 AM, Roberts, Orin <orobe...@bell.ca >>> <mailto:orobe...@bell.ca>> wrote: >>> Hello all, >>> >>> I am avidly following this discussion and based on my daily observances >>> (daily swips /subnets ), I would say Andy is closest to being practical. >>> >>> Leave the IPv4 /29 requirements alone, THIS LIMIT IS ALREADY BEING PUSHED >>> AT DAILY BY NON-RESIDENTIAL USERS and only the vague ARIN policy prevents >>> total chaos. >>> >>> With regards to IPv6, I would recommend ANY USER/ENTITY/ORG that requests a >>> /56 OR LARGER NETWORK assignment be swiped. >>> >>> That would still leave /60 to /64 assignments as minimum assignment or for >>> dynamic usage for either residential or other usage. >>> >>> Howdy, >>> >>> I don't like putting the SWIP requirement at /56 or larger because I think >>> that would encourage ISPs to assign /60s instead of /56s. The IPv6 experts >>> I've read seem to have a pretty strong consensus that the minimum >>> assignment to an end user should be either /48 or /56. Setting ARIN policy >>> that encourages assignments smaller than -both- of these numbers would be a >>> bad idea IMHO. >> >> This is one of those rare occasions when I absolutely agree with Bill. If >> we’re going to do this, I would support a requirement as follows: >> >> 1. For customers fitting the definition in NRPM 2.13, /47 or >> shorter. >> 2. For customers not fitting the definition in NRPM 2.13 /63 or >> shorter. >> >>> Again I remind everyone that a /64 assignment to an end user, even for >>> dynamic or residential use, is absolutely positively 100% wrong. Doing so >>> prevents the end user from configuring their local lans as IPv6 is >>> designed. They need at least a /60 for that. If you are assigning /64's to >>> end users, you are doing it wrong. >> >> Yes… The only place I can imagine assigning /64s to customers as a >> legitimate practice is for single-LAN datacenter installations where the >> customer has no router. >> >> If the customer might have a router, a /48 is the best and safest default >> choice and shorter should be possible with reasonable justification. >> >> Owen >> > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. _______________________________________________ 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: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
