[arin-ppml] "Residential Customer" by examples

[hostmaster at uneedus.com]

Well, assuming everything is legit, maybe those last stars on the 
traceroute belong to a point to point link between Dallas and Riga :)

Of course the more likely course is that this block points to a server in 
that datacenter, and by the definition is not a "Residential Customer". 
The only realistic option is to blackhole those blocks, and/or the 
allocations to that upstream operator.

Having learned that a definition does exist, I guess I am supposed to 
notify the one IPv6 provider who has registered my assignments in SWIP to 
take down the privacy protection for my /48 assignment, as the policy 
manual would likely consider my SSH'ing to business hosts to be not 
consistent with a "Residential Customer".  As for my other upstream 
provider and their /48 assignment, there is no SWIP record to change, as 
they have never registered the assignment.

Just as a note toward 2017-5:

Since I only have a single IPv4 address at home from each upstream, unlike 
our Riga "friend", no SWIP requirement exists in my case.  However, after 
looking over the rest of the definitions in that section at 2.15 Provider 
Assignment Unit, it appears that ARIN recommends that I receive a /48 for 
each site.  However as discussed before, these "minimum" assignments 
trigger a SWIP requirement.

Maybe since 2.15 suggests a minimum IPv6 site assignment of /48, my 
proposal should be amended to match this by changing "more than a /60" to 
"more than a /48".

Albert Erdmann
Network Administrator
Paradise On Line Inc.



On Sat, 27 May 2017, Ronald F. Guilmette wrote:

>
> In message <D3D4C237-CCDB-4B9F-9C0F-9714EE17CA79 at panix.com>,
> David Huberman <daveid at panix.com> wrote:
>
>> It's hidden in the definition section up top:
>>
>> https://www.arin.net/policy/nrpm.html#two13
>
> I do apologize for being so dense and/or so pedantic, but I'm still rather
> entirely unclear on the precise meaning and appropriate interpretation of
> the term "Residential Customer" as allegedly defined in NRPM section 2.13
> and as referenced in NRPM sections 4.2.3.7.3.2 and 6.5.5.3.1.
>
> Perhaps David or others can help alleviate my confusion by way of a couple
> of specific examples...
>
> Let's take the dual cases of 69.162.77.192/29 (NET-69-162-77-192-1) and
> also 69.162.115.240/28 (NET-69-162-115-240-1).
>
> Now, with respect to these two specific cases, I'll be more than happy
> to concede that the specific East Bloc cybercriminal who has been using
> both of these blocks as his base of operations for some months now... as he
> merrily goes about his daily acivities of hacking machines, spamming, and
> spreading malware... probably -does- have a ``residence'' someplace,
> most likely in Moscow, according to my research, but perhaps even in
> Riga, Latvia, as suggested by the ARIN WHOIS record.  He may even be
> sitting in that residence right now, as we speak, sipping on a Jolt Cola,
> and giggling to himself as he sits comfortably in his dirty t-shirt,
> shorts, and flip-flops.  (It's warning up now, this time of year, even
> in Moscow.)
>
> So, given that this guy undoubtedly ``resides'' *somewhere* it seems that
> it could easily be argued that this cybercrook technically qualifies as
> a "Residential" customer.  And I have no reason to doubt at all that he
> may be, and most probably is actually accessing his servers... and thus,
> arguably, "receiving service", as per NRPM 2.13...  at his residence in
> Moscow, or Riga, or wherever.  Thus, any lawyer worth his salt could and
> would argue that this guy qualifies... at least under a somewhat contorted
> reading of NRPM 2.13... as a "Residential Customer".
>
> But that all having been said, from where I am sitting, traceroutes into
> the middles of these two IPv4 blocks appear to me to dead-end someplace
> within a data center in Dallas, Texas.
>
> So, you know, I'll be the first to admit that I do make mistakes, and
> maybe I'm just misinterpreting the traceroute data, and maybe these
> two IPv4 assignments really do dead-end at a nice summer dacha in or
> on the outskirts of Riga.  And in that case, I'll just beg forgiveness
> of everyone here and apply for that remedial traceroute reading course
> that I saw advertised on TV.
>
> On the other hand, if in fact what I seem to be seeing in the traceroutes
> is correct, I can imagine yet another scenario that would easily explain the
> known facts of this case.
>
> It is not utterly beyond the realm of possibility that this fellow, this
> cybercriminal from Riga (or, more likely, Moscow), has acually managed to
> make his way to the United States, and thence to Dallas, Texas, and then,
> with the help of a folding cot, a sleeping bag and a little portable gas
> stove, the guy could have easily taken up residence within some comfortable
> corner of the very same Dallas data center where the traceroutes seem to
> lead.
>
> In this case also, a clever attorney would argue.... and I personally would
> have to conceed... that under one possible interpretation of NRPM 2.13 the
> cybercrook in question *does* qualify as a "Residential Customer".  (Although
> in this case, one might be forgiven for faulting Limestone Networks for
> having incorrectly listed "Riga, Latvia" as the publically-accessible part
> of the fellow's residence address, rather than, you know, Dallas, Texas,
> which would arguably have been rather more accurate.)
>
> I'm quite sure that some of my inability to understand this all arises
> from my own ignorance and my own limited and now-antiquated understanding
> of commercial networking and connectivity provisioning.  I do confess that
> I've failed to keep up with all of the technical innovations of the past
> few years, and as a result I still cling to a rather old-fashioned mental
> image of a "residential customer" as being someone sitting in a house or
> an apartment within a residential neighborhood, and out at the end of some
> pair of copper wires.  (Silly, I know.)
>
> And of course, this antiquated mental image I have of the traditional
> "Norman Rockwell" residential customer, just doesn't fit well anymore
> with the likes of more modern service providers, such as Limestone Networks,
> which is apparently able to provide (and actually providing) "residential
> service" to Riga, Latvia from its headquarters in Dallas, Texas.
>
> Anyway, I really am sheepishly apologetic to everyone here for my difficulty
> in understanding these new sorts of "residential" service arrangements, but
> in my own defense I'd just like everyone to note that my ability (or rather
> inability) to wrap my head around this kind of new-style residential service
> provisioning hasn't been helped any by what I see on Limestone's corporate
> home page, which mentions only "Dedicated Servers", "Cloud Solutions", and
> "Colocation Services", but neglects to mention the company's residential
> service offerings within the Baltic States.
>
> Perhaps if they update their home page so as to mention those residential
> offerings also, I and others will be better able to understand how they
> came to have "Private Customer" ARIN SWIPs in Riga, Latvia while providing
> service to Russian cybercriminals via the very same ARIN allocations.
>
>
> Regards,
> rfg
>
>
> P.S.  This particular case probably wouldn't even have caught my eye or
> attention had it not been for the fact that the specific Russian cyber-
> criminal whose identity is being so effectively hidden behind the
> aforementioned ARIN "Private Customer" SWIPs has denominated all of the
> prices for all of the fradulent crap he's selling on his fradulent web
> sites in U.S. dollars, and the fact that these sites are all written in
> impeccable American Engish.
>
> In short, this particular cybercrook is *not* targeting Zimbabweans or
> Singaporeans.  He's targeting Americans.  (And I happen to be one of
> those, just as, presumably, the officers, directors, and employees of
> Limestone Networks are, even if they are also Texans.)
>
> That this cybercrook is able to specifically target Americans, apparently
> entirely, or at least arguably, while staying entirely "within the rules"
> (of ARIN) is, I think, a rather entirely disgusting example, both of the
> clear and apparent gaping loopholes in the system, and of the willingness
> and ability of various providers within the ARIN region... and in the U.S.
> in particular... to deftly skirt at least the intent of the rules, and
> perhaps even the letter of them, and thus to profit, even if only indirectly,
> from the criminal schemes and frauds of East Bloc cybercrooks, even and
> especially those who target the providers' fellow countrymen, in part by
> providing to these cybercrooks the specific commodity that the cybercrooks
> value most highly:  anonymity.
>
> This commodity is -not- being provided to the cybercrooks gratis of course.
> We live in America, after all... land of the free and home of profit motive.
> Thus, as is customary, both in business and in crime the world over, the
> providers are providing the anonymity service in exchange for their agreed-
> upon piece of the pie.
>
>
> P.P.S.  It is my sincere and certain hope that nobody, and least of all
> ARIN, will do anything which would in any way disturb, delete, or alter
> either of the two SWIPs mentioned above as a result of this posting.  I am
> not quite finished studying the activities of the inhabitants therein just
> yet, and thus have no desire to see them immediately disturbed.  Thankfully,
> given that ARIN has no clear community mandate to do so, I can have utter
> confidence in ARIN's discression in this matter, especially given that
> Limestone Networks seems unlikely to be requesting new allocations within
> the immediate future.
> _______________________________________________
> 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.
>