Re: Purchased IPv4 Woes

[Suresh Ramasubramanian]

Which one was it that demanded 2500?

There's only one reasonably well known pay for whitelisting type of blocklist 
but I'd have thought they're a lot cheaper.

--srs

> On 20-Mar-2017, at 9:02 AM, Justin Wilson  wrote:
> 
> Then you have the lists which want money to be removed.  I have an IP that 
> was blacklisted by hotmail. Just a single IP. I have gone through the 
> procedures that are referenced in the return e-mails.  No response.  My next 
> step says something about a $2500 fee to have it investigated.  I know 
> several blacklists which are this way.  Luckily, many admins do not use such 
> lists.

Re: Purchased IPv4 Woes

[Justin Wilson]

Then you have the lists which want money to be removed.  I have an IP that was 
blacklisted by hotmail. Just a single IP. I have gone through the procedures 
that are referenced in the return e-mails.  No response.  My next step says 
something about a $2500 fee to have it investigated.  I know several blacklists 
which are this way.  Luckily, many admins do not use such lists.


Justin Wilson
j...@mtin.net

---
http://www.mtin.net Owner/CEO
xISP Solutions- Consulting – Data Centers - Bandwidth

http://www.midwest-ix.com  COO/Chairman
Internet Exchange - Peering - Distributed Fabric

> On Mar 12, 2017, at 9:10 PM, Bob Evans  wrote:
> 
> Pete's right about how IPs get put on the lists. In fact, let us not
> forget that these lists were mostly created with volunteers - some still
> today. Many are very old lists. Enterprise networks select lists by some
> sort of popularity / fame - etc.. Like how they decide to install 8.8.8.8
> as first - its easy and they think its better than their local ISP they
> pay yet they always call the ISP about slowness when 8.8.8.8 is for
> consumers and doesn't always resolve quickly.  It's a tough sale.
> 
> Once had a customer's employee abuse their mail server - it made some
> lists. Customer complained our network is hosting spammers and sticking
> them in the middle of a problem that is our networks. Hard win. Took us
> months to get that IP off lists. That was one single IP. We did not allow
> them to renew their contract once the term was over. Now, they suffer with
> comcast for business. ;-)
> 
> Thank You
> Bob Evans
> CTO
> 
> 
> 
> 
>> On Sun, 12 Mar 2017, Pete Baldwin wrote:
>> 
>>>   So this is is really the question I had, and this is why I was
>>> wanting to
>>> start a dialog here, hoping that it wasn't out of line for the list.  I
>>> don't
>>> know of a way to let a bunch of operators know that they should remove
>>> something without using something like this mailing list. Blacklists
>>> are
>>> supposed to fill this role so that one operator doesn't have to try and
>>> contact thousands of other operators individually, he/she just has to
>>> appeal
>>> to the blacklist and once delisted all should be well in short order.
>>> 
>>>   In cases where companies have their own internal lists, or only
>>> update
>>> them a couple of times a year from the major lists,  I don't know of
>>> another
>>> way to notify everyone.
>> 
>> I suspect you'll find many of the private "blacklistings" are hand
>> maintained (added to as needed, never removed from unless requested) and
>> you'll need to play whack-a-mole, reaching out to each network as you find
>> they have the space blocked on their mail servers or null routed on their
>> networks.  I doubt your message here will be seen by many of the "right
>> people."  How many company mail server admins read NANOG?  How many
>> companies even do email in-house and have mail server admins anymore? :)
>> 
>> Back when my [at that time] employer was issued some of 69/8, I found it
>> useful to setup a host with IPs in 69/8 and in one of our older IP blocks,
>> and then do both automated reachability testing and allow anyone to do a
>> traceroute from both source IPs simultaneously, keeping the results in a
>> DB.  If you find there are many networks actually null routing your
>> purchased space, you might setup something similar.
>> 
>> --
>>  Jon Lewis, MCP :)   |  I route
>>  |  therefore you are
>> _ http://www.lewis.org/~jlewis/pgp for PGP public key_
>> 
> 
> 

AT ISP Customers: Streaming Issues

[Scott Eiswirth]

Anyone an AT DSP or Fiber customer having issues with streaming music, 
videos, or games?


[DigiComm Systems Inc.]
Scott Eiswirth | Network Engineer
Office: (504) 212-0486
Mobile: (504) 881-6006
Fax:(504) 212-6772
www.digicommsystems.com

Re: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[Romeo Zwart]

Dear John, Bill and all,

On 17/03/17 19:31 , John Curran wrote:
> On 17 Mar 2017, at 2:17 PM, William Herrin  wrote:
>>
>> On Fri, Mar 17, 2017 at 2:14 PM, John Curran  wrote:
>>
>>> See previous reply.  The data was both correctly formatted and signed,
>>> so the agreed integrity checks passed.
>>>
>> Ah, okay. So it wasn't bad counts as originally reported but no data with
>> counts that confirmed no data. Thanks for the clarification!
> 
> Bill - 
> 
> Glad to help (and apologies for the information coming out in pieces –
> we’ve opted to go with updates as we learn more rather than some for 
> comprehensive but less timely report.) 

We have been slow to clarify this from the RIPE NCC end, for which I
apologize. As was already mentioned by Mark and John in previous
messages in this thread, the initial report from the RIPE NCC wasn't
complete, which has lead to unnecessary confusion.

A follow up message with additional detail was sent to the RIPE NCC DNS
working group list earlier today:
 https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003401.html

We hope that this clarifies matters sufficiently.

Kind regards,
Romeo Zwart
RIPE NCC

IPv6 oddness in Comcast land...

[valdis . kletnieks]

Trying to figure out what the heck is going on here.  Any good
explanations cheerfully accepted.

Background:  Home internet router is a Linksys WRT1200AC that had been
running OpenWRT 15.05.01. IPv6 worked just fine - Comcast handed me a /60
via DHCP-PD and no issues.  I reflashed it to Lede 17.01, and after doing
all the reconfig, I'm hitting a really strange IPv6 issue.

Symptoms - IPv6 still configures correctly, but IPv6 packets appear to go out
and disappear into the ether when they leave the Linksys.  Doing a traceroute
to any IPv6 destination makes things work again - for a while (from 15 minutes
to an hour or two).

As seen from my laptop (I have the matching tcpdump from the outbound
interface on the Linksys):

[~] ping -6 -c 3 listserv.vt.edu
PING listserv.vt.edu(listserv.ipv6.vt.edu 
(2001:468:c80:2105:211:43ff:feda:d769)) 56 data bytes

--- listserv.vt.edu ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2070ms

[~] traceroute -6 listserv.vt.edu
traceroute to listserv.vt.edu (2001:468:c80:2105:211:43ff:feda:d769), 30 hops 
max, 80 byte packets
 1  2601:5c0:c001:69e2::1 (2601:5c0:c001:69e2::1)  2.417 ms  3.077 ms  5.358 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * hu-0-10-0-7-pe04.ashburn.va.ibone.comcast.net (2001:558:0:f5c1::2)  
31.478 ms  31.975 ms
 7  2001:559::d16 (2001:559::d16)  32.406 ms  17.102 ms  24.751 ms
 8  2001:550:2:2f::a (2001:550:2:2f::a)  23.245 ms  23.519 ms  22.185 ms
 9  2607:b400:f0:2003::f0 (2607:b400:f0:2003::f0)  29.782 ms  28.604 ms  29.891 
ms
10  2607:b400:90:ff05::f1 (2607:b400:90:ff05::f1)  30.423 ms *  30.680 ms
11  * * *
12  listserv.ipv6.vt.edu (2001:468:c80:2105:211:43ff:feda:d769)  34.562 ms  
39.072 ms  24.633 ms
[~] ping -6 -c 3 listserv.vt.edu
PING listserv.vt.edu(listserv.ipv6.vt.edu 
(2001:468:c80:2105:211:43ff:feda:d769)) 56 data bytes
64 bytes from listserv.ipv6.vt.edu (2001:468:c80:2105:211:43ff:feda:d769): 
icmp_seq=1 ttl=53 time=33.3 ms
64 bytes from listserv.ipv6.vt.edu (2001:468:c80:2105:211:43ff:feda:d769): 
icmp_seq=2 ttl=53 time=24.3 ms
64 bytes from listserv.ipv6.vt.edu (2001:468:c80:2105:211:43ff:feda:d769): 
icmp_seq=3 ttl=53 time=46.0 ms

--- listserv.vt.edu ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 24.334/34.595/46.093/8.927 ms

So it looks like something times out somewhere and fails to pass packets
back.

TCP connections don't keep IPv6 alive. I have a browser window that
auto-updates every 5 minutes, and a SmokePing process on a Raspberri Pi uploads
to a server at work every few minutes, and those eventually drop back to IPv4
when the IPv6 TCP fails to connect. And normal UDP doesn't seem to keep it
alive - NTP pointing at IPv6 peers loses connectivity as well.

But a traceroute wakes it up. It's almost like some router is losing the
route to me out of the FIB, and fixes it when it has to handle a packet
on the CPU slow path (like send back a 'time exceeded').  But I'm mystified
why this started when I reflashed my router.



pgpFmMQ6AFHkS.pgp
Description: PGP signature

Re: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[Doug Barton]

On 03/18/2017 10:53 PM, John Curran wrote:

On 19 Mar 2017, at 12:50 AM, Doug Barton > wrote:

...
Meanwhile, my offer to help y'all fix your DNS was a sincere one. Feel
free to hit me up off list.


Doug -

  You’d want to make that offer to the RIPE NCC


My offer was in response to your assertion that normal DNS techniques of 
delegation were not sufficient to the unique problems ARIN has to deal 
with in regards to the address space you manage delegations for.


Subsequent to our conversation however, Shane Kerr was kind enough to 
explain the problem that the "zonelets" are designed to solve:


https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003406.html


Short version, ARIN maintains foo/8, but bar/16 within it is managed by 
RIPE, who wants to delegate it directly to the registered party for that 
block. They use a zonelet to tell ARIN how to do that.


As you have indicated that ARIN will not make any changes to its 
existing practices without specific instructions from RIPE, I will offer 
my suggestions to them instead.  :)


best,

Doug