Scott, thanks again. Yes, your precise reading is correct and welcome. As you may have discerned, my concerns with this matter reveal my small ISP priorities. When we got our /32 (2005) and to this day, the religious wars seemed to have settled on /48 as the 'default' assignment for customers. We had exactly one IPV4 /29 in our history. My approach to that situation was to plan to divide the /32 into logical subnets, assign those to our exchanges so that every customer got a /48 and retain one or more chunks to assign /40s or /44s out of, so that the customer could then also assign /48s out of them. I get that people want to announce /48s. Do what you wish to them. I am primarily concerned that my small concern is not SWIPing all of its customer /48s. So yes, I did omit the /48 announcement clause in my discussion, to focus on the precept of non-announced /48s not being required to SWIP. Thanks again for helping me clarifying that.
John Springer On Sun, Jul 23, 2017 at 10:10 PM, Scott Leibrand <[email protected]> wrote: > No. It says: > > Each static IPv6 assignment containing a /47 or more addresses, or > sub-delegation of any size that will be individually announced, shall be > registered in the WHOIS directory > > I read that as: > > Each static IPv6 assignment containing a /47 or more addresses, and each > sub-delegation of any size that will be individually announced, shall be > registered in the WHOIS directory > > So a /48 sub-delegation shall be registered if it will be individually > announced. > > You said: > > To be explicit, to me, "/47 or more addresses, or sub-delegation of any > size that will be individually announced," refers to /47s, /46s, /45s ... > and not /48s, /49s, /50s, etc. > > > That entire quoted clause refers to /48s (or longer, if such becomes > possible) that will be individually announced. So your clarification, as > originally stated, does not match my reading of the text. However, it now > sounds like that's not what you meant, and you were trying to say: > > To be explicit, to me, "/47 or more addresses," refers to /47s, /46s, /45s > ... and not /48s, /49s, /50s, etc. > > > If that's what you actually meant, then yes, that is the way to read > "more": as equivalent to "/47 or shorter". > > > Leif, it seems like we have some potential ambiguity in the new text as to > whether "or sub-delegation of any size" is part of the subject of the > sentence, or a subordinate clause to "containing". Does my rewrite above > clarify your intent? Or were you intending it to mean "Each static IPv6 > assignment containing a ... sub-delegation of any size that will be > individually announced, shall be registered in the WHOIS directory"? That > interpretation makes no sense to me, as the sub-delegation clause would be > redundant. So if that's what you meant, I'd appreciate some clarity on what > it is intended to accomplish. > > Scott > > On Jul 23, 2017, at 8:35 PM, John Springer <[email protected]> wrote: > > Thanks, Scott, > > Are we energetically agreeing? You scared me there for a second. /48s are > excluded, unless they are part of a "subdelegation of any size that will be > individually announced". Yes. > > How is that defined by the way? Will be individually announced in 2 years, > 2 days, right now? > > On another matter, this problem statement has been making me uneasy all > along, but because it was only required to be clear and in scope to be > accepted as Draft Policy, it was not appropriate for me to object. This > seems like as good a time as any to address some concerns, which are my > opinions only. > > "Current ARIN policy has different WHOIS directory registration > requirements for IPv4 vs IPv6 address assignments." > > This is a correct statement! It is not a problem however, nor is it > sufficient motive for trying to solve a problem, per se. > > "IPv4 registration is triggered for an assignment of any address block > equal to or greater than a /29 (i.e., eight IPv4 addresses). > In the case of IPv6, registration occurs for an assignment of any block > equal to or greater than a /64," > > Two facts. The second is undoubtedly a great pity, but to entangle these > logically is a fallacy of inconsistency, specifically a false equivalence. > These two facts are unrelated. It does not help the case to try to make > them interdependent. And it is not needed. All that is being attempted is > to modify V6 SWIP requirements. Do that. And DO NOT settle on 8 subnets. > > "which constitutes one entire IPv6 subnet and is the minimum block size > for an allocation." > > I think I'm looking at current text. How did this make it this far? One > ENTIRE IPV6 subnet? There are lots of entire V6 subnets all the way from /0 > to /128. What does that have to do with anything? And, yeah, the SWIP > boundary being the so called "minimum" allocation seems broken, but that is > its own thing. > > "There is no technical or policy rationale for the disparity, which could > serve as a deterrent to more rapid IPv6 adoption." > > Possibly true, but irrelevant. There is no technical or policy rationale > for them being alike either, nor is there any reason to suppose that if > they were, folks would adopt V6 faster. SWIPing /64 is definitely wrong for > V6. Concentrate on that. We can make policy for V6 without needing to refer > to V4. > > "The purpose of this proposal is to eliminate the disparity and > corresponding adverse consequences." > > With respect, it is not. The disparity does not qualify as a logical > motive. The brokenness of SWIPing /64s does not require injustice and if > /64 SWIPing is a deterrent to V6 adoption, that is its own good and > sufficient reason. If you had to refer to an analogy, you could say, > "SWIPing /64s is analogous to SWIPing /32s and that seems dumb". > > So all you need is: > > Problem Statement: SWIPing IPV6 /64s is the problem. The purpose of this > proposal is to pick a different number. > > Policy statement: > 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to > strike "/64 or more addresses" and change to "/47 or more addresses, or > subdelegation of any size that will be individually announced," > and > 2) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the > NRPM by deleting the phrase "holding /64 and larger blocks" > > BUT. These observations do not appear to have any effect one way or the > other on the policy text. To me, picking a different number does not have > anything to do with disparity, but so what? Changing the IPV6 SWIP > threshold is not unfair and partial if someone makes unfounded assertions > regarding linkages between v4 and V6. And it is not technically unsound to > make fallacious observations if they are kind of orthogonal to the meat of > the matter. > > So, still support. I'd rather see it simpler, but I guess I can tolerate > a little hand waving. > > Writing solely on my own behalf, > > John Springer > > On Fri, Jul 21, 2017 at 9:15 PM, Scott Leibrand <[email protected]> > wrote: > >> On Jul 21, 2017, at 8:31 PM, John Springer <[email protected]> wrote: >> >> I support this Draft Policy as re-written. >> >> I shared the author's distaste for the requirement that IPV6 /64s be >> SWIP'd, but was not reassured when the discussion veered to consider >> prefixes between /48 and /64. AFAIK, ISPs have long been encouraged to >> apply for their allocations based on the idea of assigning a /48 to each >> 'customer' to provide room for unknown technologies, among other things. I >> did not wish to endanger that premise, but current language appears to moot >> that concern. >> >> To be explicit, to me, "/47 or more addresses, or sub-delegation of any >> size that will be individually announced," refers to /47s, /46s, /45s ... >> and not /48s, /49s, /50s, etc. >> >> >> That's not what it says. It says /48s (or longer) should be individually >> SWIPped if they're going to be announced. Otherwise there's no reason for >> the extra clause. >> >> Blocks in the GRT need to be SWIPped to the announcing party if that's a >> different organization from the holder of the larger block. >> >> -Scott >> >> >> On Fri, Jul 21, 2017 at 9:44 AM, Leif Sawyer <[email protected]> wrote: >> >>> Happy Friday, everybody. >>> >>> >>> >>> As promised, here is the latest rewrite of the draft policy below, and >>> it will soon be updated at: >>> >>> https://www.arin.net/policy/proposals/2017_5.html >>> >>> >>> >>> There are two changes noted in the policy statement: the first of which >>> reflects what seems to be the current >>> >>> consensus of the PPML regarding netblock sizing; the second is to strike >>> language that may be read as either restrictive >>> >>> or non-operational. >>> >>> >>> >>> ---- >>> >>> >>> >>> Problem Statement: >>> >>> Current ARIN policy has different WHOIS directory registration >>> requirements for IPv4 vs IPv6 address assignments. >>> >>> IPv4 registration is triggered for an assignment of any address >>> block equal to or greater than a /29 (i.e., eight IPv4 addresses). >>> >>> In the case of IPv6, registration occurs for an assignment of any >>> block equal to or greater than a /64, which constitutes one entire IPv6 >>> subnet and is the minimum block size for an allocation. >>> >>> Accordingly, there is a significant disparity between IPv4 and >>> IPv6 WHOIS registration thresholds in the case of assignments, resulting in >>> more work in the case of IPv6 than is the case for IPv4. >>> >>> There is no technical or policy rationale for the disparity, >>> which could serve as a deterrent to more rapid IPv6 adoption. >>> >>> The purpose of this proposal is to eliminate the disparity and >>> corresponding adverse consequences. >>> >>> >>> >>> Policy statement: >>> >>> 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM >>> to strike "/64 or more addresses" and change to "/47 or more addresses, or >>> sub-delegation of any size that will be individually announced," >>> >>> and >>> >>> 2) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the >>> NRPM by deleting the phrase "holding /64 and larger blocks" >>> >>> >>> >>> Comments: >>> >>> a. Timetable for implementation: >>> >>> Policy should be adopted as soon as possible. >>> >>> >>> >>> b. Anything else: >>> >>> Author Comments: >>> >>> IPv6 should not be more burdensome than the equivalent IPv4 >>> network size. >>> >>> Currently, assignments of /29 or more of IPv4 space (8 >>> addresses) require registration >>> >>> The greatest majority of ISP customers who have assignments of >>> IPv4 space are of a single IPv4 address which do not trigger any ARIN >>> registration requirement when using IPv4. >>> >>> This is NOT true when these same exact customers use IPv6, as >>> assignments of /64 or more of IPv6 space require registration. >>> >>> Beginning with RFC 3177, it has been standard practice to >>> assign a minimum assignment of /64 to every customer end user site, and >>> less is never used. >>> >>> This means that ALL IPv6 assignments, including those customers >>> that only use a single IPv4 address must be registered with ARIN if they >>> are given the minimum assignment of /64 of IPv6 space. >>> >>> This additional effort may prevent ISP's from giving IPv6 >>> addresses because of the additional expense of registering those addresses >>> with ARIN, which is not required for IPv4. >>> >>> The administrative burden of 100% customer registration of IPv6 >>> customers is unreasonable, when such is not required for those customers >>> receiving only IPv4 connections. >>> >>> >>> >>> >>> >>> --- >>> >>> >>> >>> Leif Sawyer >>> >>> Advisory Council >>> >>> >>> >>> _______________________________________________ >>> 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: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact [email protected] if you experience any issues. >>> >> >> _______________________________________________ >> 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: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact [email protected] if you experience any issues. >> >> >
_______________________________________________ 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: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
