[arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6
Paul McNary
pmcnary at cameron.net
Tue Jul 25 18:46:42 EDT 2017
Let me change "geolocation" to "address tracking".
For instance, Netflix blocks a certain region and whois is showing customer
in that region, whereas the customer is actually in a non-blocked region.
If I had my own IPv4 /24 or above I don't have any issue making this
entry correct to ARIN.
But I have a /25 block from a datacenter that shows I am in California.
Their SWIP policy on IPv4 is /24 to SWIP.
We are trying to minimize these issues as we deploy IPv6 when we have
direct allocation.
I am not debating the "address tracking" issue just brought it up
because I think John made a comment about it.
We see ebay, amazon, craig's list all using whois information.
Also our /25's have been blocked at the /24 and /18 level.
We had /24's blocked that are reallocated at the parent /18 level.
So unless there is some way to enforce, it just seems to be words on paper.
CHANGE of subject not topic
--------------------------------------
What I had wished to do on IPv6 deployment is assign an IPv6 /48 to each
Tower(WISP), each POP(ISP)
I would want that switched as will as any individually announced block
smaller than that.
Haven't decided but have a separate /48 to handle DNS, mail servers,
etc. ie Our Infrastructure
Anything less specific that a /48 would just add noise to the world and
would be somewhat proprietary.
I give away some info just advertising my POP's/Towers but I think that
would be for the collective good. :-)
The world doesn't need to know my Access Points or neighborhood routers,
etc.
I think I need to get off my soapbox and take a nap now!
I know I ramble a lot, but getting too old to change much! :-)
Thanks
Take care
Paul
On 7/25/2017 5:17 PM, Scott Leibrand wrote:
> If I, as an End User network, want to inform geolocation providers of
> where I'm using each netblock, having them assigned to me in the whois
> DB with an appropriate address is one of the best ways to do that.
> But if I'm running a geolocation service, I can't rely on whois as the
> sole source of data on where an address is used. If I have other info
> that contradicts the whois information, I'd probably just ignore the
> whois data and go with the facts on the ground.
>
> -Scott
>
> On Tue, Jul 25, 2017 at 3:12 PM, Paul McNary <pmcnary at cameron.net
> <mailto:pmcnary at cameron.net>> wrote:
>
> Owen
> Several weeks ago geolocation was one of the arguments for having
> accurate whois in this thread.
> This is no longer being argued?
> Paul
>
>
> On 7/25/2017 4:26 PM, Owen DeLong wrote:
>
> Huh?
>
> WHOIS is not a geolocation service and anyone who thinks it is
> should reduce their use of recreational pharmaceuticals.
>
> Owen
>
> On Jul 24, 2017, at 12:03 , Paul McNary
> <pmcnary at cameron.net <mailto:pmcnary at cameron.net>> wrote:
>
> Then that totally negates the reasoning for geolocation.
> The administrative address could be on the other side of
> the earth.
>
> Paul
>
>
> On 7/24/2017 1:31 PM, Owen DeLong wrote:
>
> On Jul 20, 2017, at 14:28 , hostmaster at uneedus.com
> <mailto:hostmaster at uneedus.com> wrote:
>
> My transit bus example is another example of SWIP
> difficulty. Very hard to provide a street address
> to SWIP a bus when it is mobile 16 hours a day.
>
> Not at all. A bus would be SWIPd to the bus yard or
> administrative offices of the bus company. The SWIP
> data is not required to be the service address, it is
> required to be an address for administrative and/or
> technical contact regarding the network and/or legal
> process service regarding same.
>
> [rest trimmed because we are in agreement on that part]
>
> Owen
>
> On Thu, 20 Jul 2017, Chris James wrote:
>
> @Paul - The API key is to email it.
>
> @Owen - Very difficult when you have dynamic
> ranges, and vps/container
> platforms spanning tens of thousands of
> instances across these dynamic
> ranges.
>
>
> On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary
> <pmcnary at cameron.net
> <mailto:pmcnary at cameron.net>> wrote:
>
> Owen
>
> The reassignment policy page says IPv6 has
> to be done vi API.
> Is that something else that is incorrect
> on the web site?
>
> Paul
>
>
> On 7/20/2017 3:16 PM, Owen DeLong wrote:
>
> How can it be overly difficult to fill
> out an email template with your
> customers’
> Name, Address, Phone Number?
>
> Really?
>
> Owen
>
> On Jul 19, 2017, at 23:48 , Pallieter
> Koopmans <Pallieter at pallieter.org
> <mailto:Pallieter at pallieter.org>>
>
> wrote:
>
> Hello,
>
> ARIN could quantify and require
> rules for when to SWIP, but in the
> end, there are going to be
> exceptions needed if the rules are
> to be
> strictly followed. Many will not
> separately SWIP a separately routed
> sub-block if it is too difficult
> or pointless to gather and share that
> data back upstream to ARIN.
>
> Thus a more fuzzy rule to require
> a best-effort and to add a
> rule-based reason (preferably both
> a carrot and a stick) for block
> owners to do their best to provide
> (only) useful data. In order to do
> that, one needs to look back at
> why that data is needed. For a block
> owner to assign the SWIP on a
> sub-block, he basically delegates tech
> and abuse contact requests down to
> those that are probably more likely
> to be able to actually act on the
> tech/abuse requests (and thus reduce
> request-handling workload higher
> up and overall). But for that to
> work, those tech/abuse contact
> requests need to be actually handled,
> otherwise, it is better to leave
> them with the block owner.
>
> In the end, the contact details
> should be as close to the "person"
> that is actually capable to both
> handle (think: volume/languages/etc)
> and act (think: authority) on the
> tech/abuse requests.
>
> eBrain
> Innovative Internet Ideas
>
> Pallieter Koopmans
> Managing Director
>
> +31-6-3400-3800
> <tel:%2B31-6-3400-3800> (mon-sat
> 9-22 CET)
> Skype: PallieterKoopmans
> _______________________________________________
> PPML
> You are receiving this message
> because you are subscribed to
> the ARIN Public Policy Mailing
> List (ARIN-PPML at arin.net
> <mailto:ARIN-PPML at arin.net>).
> Unsubscribe or manage your mailing
> list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> <http://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact info at arin.net
> <mailto: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
> <mailto:ARIN-PPML at arin.net>).
> Unsubscribe or manage your mailing
> list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> <http://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact info at arin.net
> <mailto: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
> <mailto:ARIN-PPML at arin.net>).
> Unsubscribe or manage your mailing list
> subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> <http://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact info at arin.net
> <mailto:info at arin.net> if you experience
> any issues.
>
> --
> This e-mail message may contain confidential
> or legally privileged
> information and is intended only for the use
> of the intended recipient(s).
> Any unauthorized disclosure, dissemination,
> distribution, copying or the
> taking of any action in reliance on the
> information herein is prohibited.
> E-mails are not secure and cannot be
> guaranteed to be error free as they
> can be intercepted, amended, or contain
> viruses. Anyone who communicates
> with us by e-mail is deemed to have accepted
> these risks. This company is
> not responsible for errors or omissions in
> this message and denies any
> responsibility for any damage arising from the
> use of e-mail. Any opinion
> and other statement contained in this message
> and any attachment are solely
> those of the author and do not necessarily
> represent those of the company.
>
> _______________________________________________
> PPML
> You are receiving this message because you are
> subscribed to
> the ARIN Public Policy Mailing List
> (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net>).
> Unsubscribe or manage your mailing list
> subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> <http://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact info at arin.net
> <mailto: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 <mailto:ARIN-PPML at arin.net>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> <http://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact info at arin.net <mailto: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
> <mailto:ARIN-PPML at arin.net>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> <http://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact info at arin.net <mailto:info at arin.net> if you
> experience any issues.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170725/8f9ac6f1/attachment.htm>
More information about the ARIN-PPML
mailing list