True, but it does help when it is being used. If we could increase the adoption of SWIP from the service providers, it would also be used more heavily for geolocation services, and the upward spiral begins. There will always be some abuse of geolocation services as long as there are georestrictions for media etc.. It's between service provider authenticity and the service that requires geolocation that the trust needs to be formed. It's up to us to provide a mechanism/tool/information to allow them to build that trust.
I'm all for having the ability to SWIP per IP, and it's up to me as a service provider to keep it as authentic as I can, so Netflix can trust me. When applying this to IPv6 (and forgive my lack of knowledge) but part of the address is identifying the physical interface (hardware). Seems a SWIP registration should be on that part of the address and then regardless of service provider that host will always be identified the same, owned by Bob Smith. As a service provider (SDWAN provider) I would NAT their network portion of their traffic to return to me, but keep the host the same. If I'm trying to hide the identity of the host by doing a full NAT with an encrypted tunnel, I'm clearly up to no good and shouldn't be trusted by content providers anyway. Trying to hide who I am is not security, it's trying to disguise myself to obtain something my actual ID would not allow me to, or I wouldn't want someone knowing I'm trying to obtain something. All in all, I think we need to provide a mechanism that can allow SP's and applications to build trust through that mechanism. My newbie 2 cents. -----Original Message----- From: ARIN-PPML [mailto:[email protected]] On Behalf Of Owen DeLong Sent: Tuesday, July 11, 2017 8:41 PM To: [email protected] Cc: [email protected] Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 > I also question why 100% SWIP on v6, because 99.9% of ISP's are not coming > back for a new assignment. While SWIP is useful for network security and > contact needs, this is NOT the purpose it was established. It was > established to document an ISP's address utilization rates for ARIN to be > used when the ISP requests more space. Since very few have come back to > ARIN for more v6 space, I think its purpose is not needed until such time > as an ISP needs to get its ducks together to ask for more IPv6 space, > which with the larger space of v6 will be never for most ISP’s. As someone who was around back when much of this was hashed out, I can assure you that SWIP (and WHOIS before it) was not deployed primarily for ISPs to document utilization. It was, in fact, primarily for security and contact purposes from the first days of the WHOIS protocol. RIR uses (and RIRs themselves) came much later in the game. The RIR rules and requirements around SWIP and WHOIS were actually put in place primarily to protect this ability to have security and contact information where needed. Later the RIRs discovered the usefulness of this same data for utilization validation, but it was NOT the original purpose for collecting the data. > I also do not think ARIN's policies should be supporting the business > models of the Geolocation providers, of which one of the most annoying > customers of same is the Copyright Trolls. Even the "Residential Privacy" > people must publically declare a zipcode, a goldmine for the Geolocation > providers. As one who works for a company that is not strictly a geolocation provider, but which does a great deal of geolocation as part of its other business needs, I will say this simply isn’t true. Any geolocation provider basing their conclusions on whois is an extremely inaccurate geolocation provider. Owen _______________________________________________ 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.
