[arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

[Owen DeLong]

> On Jul 13, 2017, at 09:32 , hostmaster at uneedus.com wrote:
> 
> 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.

Understood.

> 
> 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.

Some ISPs have fees for assigning these blocks. There are no registration costs per se for SWIP. SWIP is free.

> 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 to change.

And we are in agreement. I’ve expressed support for the change, I just want to be slightly more liberal about it while still preserving the integrity of the registry.

> 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.

Personally, I don’t believe that independent routability is a matter for the RIR to consider in policy as the RIR has no control over or participation in such a decision, it is entirely to the ISPs to determine.

> 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.

Why? Why should we saddle IPv6 with the baggage of policy that was carefully crafted to deal with the unique shortage situation as it existed in IPv4 and the assignment policies that resulted from that unfortunate situation?

> 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.

Consensus hasn’t yet been reached. I agree that there is significant support for “shorter than /56” actually (not /56 itself). Nonetheless, I don’t believe that shorter than /56 is the ideal place to put the boundary.

> 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.

Again, you say this as if matching IPv4 policy is some lofty or higher goal. I absolutely disagree with this premise. The sooner we can abandon the baggage holding back the internet known as IPv4, the better. IPv4 policy was written by flawed human beings just like IPv6 policy. I say this as one of the largest single contributing authors of IPv4 (as well as IPv6) policy in the ARIN NRPM.

There is absolutely nothing sacrosanct about IPv4 policy as it is currently written and we should only emulate IPv4 policy in developing IPv6 policy where that is the best IPv6 policy we can build. In this case, because IPv6 is so fundamentally different from IPv4 in its architecture and the way addresses are intended to be deployed, the only thing we can possibly achieve by saddling IPv6 policy in this area with IPv4 thinking is to further debilitate IPv6 unnecessarily.

That is why I proposed that now that we have a definition of residential customers (we didn’t have one when the IPv4 SWIP policy was written) using it as a point of distinction can help achieve better policy goals.

Perhaps taking a step back and reviewing the policy goals (overall strategic ideals, rather than specific policy objectives) we want to achieve is worth while.

From my perspective, the overall IPv6 policy goals should be:

	1.	Do not encourage ISPs to issue long prefixes.
	2.	Discourage non-nibble-aligned allocations and assignments by ISPs.
	3.	Ensure that the WHOIS database remains a useful mechanism for transparency in resource allocations.
		A.	Reasonable Accuracy and Currency of Data
		B.	Sufficiently detailed to allow appropriate contacts for addressing technical, administrative, and abuse issues.
		C.	Appropriate protections for residential customer privacy.
	4.	Prevent fragmentation where possible without sacrificing more important goals.
	5.	Make sure IPv6 addresses are readily available to any entity which needs them on a reasonable basis.

It is my opinion that setting the SWIP boundary at “shorter than /56” will not achieve these goals as well as if we set a residential boundary at “shorter than /48” while preserving a stricter SWIP boundary for businesses. I’m willing and open to shorter prefixes for businesses than my proposed /63 or shorter being exempt from SWIP and would support any boundary up to and including “shorter than /52”.

Surely you can see the likely difference in responsibility and contact requirements between a residential site with a /48 and a business with a /48.

Owen

> 
> Albert Erdmann
> Network Administrator
> 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.
>> 
>> 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 <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.
>>>>> 
>>>>> 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 at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>