[arin-ppml] IPv4 SWIP requirements (?)

[Kevin Blumberg]

Peter,

I agree that this policy should be about the sizing of SWIP assignments in IPv6 only. 

I would prefer that any issue related to enforcement be left out of the policy (I don't see it in the current draft).

The benefit of having an appropriate size, is that it shows the community what the expectation should be. 

Regarding the size, this is only for customers that specify the need for a static assignment. A customer being assigned a dynamic /48 would not apply etc.

The smaller the block, the more customers will be shoe horned into the wrong assignment size, for the sake of paperwork.

I believe that larger than /56 should be the bar.

Thanks,

Kevin Blumberg


-----Original Message-----
From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Peter Thimmesch
Sent: Friday, May 26, 2017 8:25 PM
To: hostmaster at uneedus.com
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] IPv4 SWIP requirements (?)

Albert,

I concur 100% with your goal here and believe that there is a path to creating an equitable policy. Therefore I support, and ask others responding to this thread, with the intent of your policy proposal. 

The sole question, outside of "size" of the v6 cut-off, is whether there should be a mechanism to "punish" those that do not follow the policy. 

Can we work first to agree on the size cut-off and then address what, if any, enforcement tools can be agreed upon? 

The draft proposed "more than a /60", is this acceptable to the community? I support revising the current policy to this size. 

Regards,

Peter Thimmesch

On May 26, 2017, at 20:11, "hostmaster at uneedus.com" <hostmaster at uneedus.com> wrote:

>> So, let me see if I understand this...
>> 
>> ARIN doesn't, can't, and most probably won't either enforce the 
>> existing
>> (IPv4) SWIP rules, nor, for that matter, any new SWIP rules that may 
>> be drafted and/or promulgated with respect to IPv6.  Is that about 
>> the size of it?
>> 
>> If so, then color me perplexed.  I'm not at all sure that I grasp the
>> reason(s) why people on this list are spending/investing time and 
>> energy discussing and debating some new draft rule for IPv6 that also 
>> and likewise won't ever actually be enforced.
>> 
>> Am I missing something?
> 
> I am the proposer of the current item regarding IPv6 Assignment Registration.
> 
> I wrote this proposal with all seriousness, and do not see it as head of a pin dancing.  When the rules for v4 likely affect less than 5-10% of the total customer base at an ISP, but adding IPv6 elevates it to 100%, this is wrong, and this does deserve a serious shot at repair.  I would like to see the percentages of v6 customers subject to this rule to be roughly the same as the current number of v4 customers subject to the rule.
> 
> In the IPv4 world, a majority of the total number of access circuits for Internet access only provide 1 global IP address.  In the case of mobile networks, you do not even get that, but rather an RFC1918 address behind some sort of NAT.  The current rule of /29 or more means that all these IPv4 customers are not, and never have been subject to SWIP rules. Generally only those doing hosting of some sort, or larger businesses actually request an amount of addresses that require SWIP.
> 
> Therefore, while we discuss how many access providers are ignoring the SWIP rules, do remember that the majority of ISP customers for IPv4 internet access are NOT subject to the SWIP rules, since they have 1 or less dedicated IP addresses.
> 
> Only the largest IPv4 customers are subject to SWIP, not the majority of the total customer base.
> 
> When the standard was lowered to the /29 point, somehow the proposal at that time also decided to lower the v6 point from /48 to /64.  Of course, /64 means EVERY customer, even the very smallest must be subject to SWIP under the rules.  As noted we have gone a few years with only a few people requesting v6 assignments, and the SWIP requirement has been ignored to a large degree much to the same degree that v6 itself has been ignored.
> 
> The current rule for IPv6 is 100% is subject to SWIP.  Whereas maybe 10% or less of your customer base under v4 was subject to SWIP, the current requirement is 100% for v6.
> 
> How can you expect such a rule to be followed, and is it reasonable to subject the majority of the access customers to this rule for v6, when it has NEVER been the rule in v4? I have never seen anyone propose SWIP at the /32 level.  The current v6 standard of 100% SWIP is UNREASONABLE. This is why I am proposing a change in the standard.
> 
> Reasonable rules are more likely to be complied with, and whatever the rule is, I agree that the rules should not be ignored, and also agree that in fact, it is widely ignored.  If it were made more reasonable, I have hope that it might also be followed more.
> 
> If the Registration rule was made closer to the current v4 rule, such that does not catch most access provider customers, there will be fewer addresses to SWIP, and I believe it will be more likely than the current rule to be followed, as the number of assignments requiring registration will be vastly decreased from the current standard of 100% of v6.
> 
> While I doubt that this registration requirement is the "cause" of not providing IPv6 connections, it certainly adds to the excuses not to adopt.
> We know that lots of excuses have been used, and we should do anything to cut back on the excuses.
> 
> In answer to the question as to the purpose of this proposal, it is to make the rules for SWIP more equal between IPv4 and IPv6.  Currently, IPv4 only requires SWIP for a /29 or more, leaving the majority of access circuits without any SWIP requirement whatsoever.  This is NOT currently true for IPv6, which the policy manual requires registration for a /64 or more of space, which is basically 100%.
> 
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
> _______________________________________________
> 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.
_______________________________________________
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.