[arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6
hostmaster at uneedus.com
hostmaster at uneedus.com
Thu Jul 13 12:32:57 EDT 2017
The main reason I advanced this proposal is because the policy for the
average small user of IPv4 differs greatly from that of that same small
user when they chose to go dual stack and add IPv6 to their network.
The majority of all internet connections for residential and small/medium
business use in IPv4 land is a single public (or in some cases CGnat)
address behind a internal block of RFC1918 private network addresses. As
to SWIP, ISP's might have just a single entry showing a given block of
addresses are assigned to residential and small business customers to
document the assignment of these addresses for ARIN. There is no actual
SWIP down to the individual customer level. Only a small portion of total
ISP customers hold more than a /29, so very few individual SWIP records
are needed, and these are the customers that have 8 or more v4 addresses.
ISP's have fees for assigning these blocks, so any registration costs are
passed to the customer.
In IPv6, that changes. Currently, even the smallest block (/64) must be
registered when they are assigned to a customer. There is NO useable
level that does not require registration, and this is the problem I seek
It was generally agreed during discussion that even the smallest v6
customer needs to be able to route, so that means the minimum block
assigned to the smallest user cannot for technical reasons be any smaller
than a /60, and giving out /64's is not wise. Since a /48 can be
independently routed, of course a /48 should be subject to SWIP. Others
have suggested the SWIP standard should be tied to the block being
independently routed. However, that is not the standard in v4, where the
routing standard is /24, and the SWIP standard is /29.
Like the difference between /24, the smallest routable network in v4, /32,
the amount of v4 space the majority of customers have, and /29, the
current SWIP standard, a number for v6 between /48 and /60 should be
chosen to be the level that triggers SWIP, instead of the current policy
of SWIP everyone.
I initially proposed the absolute minimum size in my proposal that permits
routing which is to allow /60 and /64 subnets to be exempted from the SWIP
policy. After discussion, the majority of commenters feel that a /56
should also be exempted and this was the consensus.
In order to put the language in the same form as the IPv4 section, I
understand the language will be changed to "/55 or more" instead of "more
than a /56" in the next version of the draft, leaving /56, /60 and /64
exempted from mandatory SWIP registration, in much the same fashion as
/30, /31 and /32 are exempted in the IPv4 world.
Paradise On Line Inc.
On Wed, 12 Jul 2017, Owen DeLong wrote:
>> On Jul 11, 2017, at 23:26 , hostmaster at 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.
>> 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 <bill at herrin.us> wrote:
>>>> On Tue, May 30, 2017 at 9:12 AM, Roberts, Orin <oroberts at bell.ca <mailto:oroberts at 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.
>>>> 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.
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML