From betty at nanog.org  Fri Jul  1 13:52:19 2016
From: betty at nanog.org (Betty Burke <betty@nanog.org>)
Date: Fri, 1 Jul 2016 09:52:19 -0400
Subject: [NANOG-announce] NANOG ON THE ROAD - NYC
Message-ID: <CABhExizHy4STP1ukON-RijLg1v6pJMcGj48N3+9HZg4krK=gdA@mail.gmail.com>

We are very excited to be holding the next NOTR event in New York
<https://www.nanog.org/meetings/road12/home> on July 21, 2016, and we
invite you to join us!

Are you interested in Internet networking/peering? Do you work at a
colocation, hosting or data center facility? Are you a provider of
hardware/software solutions for the Internet industry?  If so, the NANOG On
The Road New York event is perfect for you!

Date:  Thursday, July 21, 2016
Time:  Registration Desk opens at 8:30am and Program is from 9:00 AM - 5:00
PM
Location: Marriott Marquis <http://nanog.org/meetings/road12/hotel> - 1535
Broadway, New York, NY  10036
The FREE to attend event is open for registration.  Register Now!
<https://www.nanog.org/meetings/road12/registration>

If you are, or will be, in the New York area, we invite you to attend.  And
don?t forget to share the invitation with your colleagues or others you
feel may benefit from attending.  Make NANOG On The Road your first step
toward learning how you can take the wheel and steer the future of the
Internet.

Learn more about On The Road events here
<https://www.nanog.org/meetings/road/home>.  Feel free to contact us at
nanog-support at nanog.org with any questions you may have.


Sincerely,

Betty

Betty J. Burke
NANOG Executive Director
2864 Carpenter Rd., Ste 100
Ann Arbor, MI 48108
+1 866-902-1336
-------------- next part --------------
_______________________________________________
NANOG-announce mailing list
NANOG-announce at mailman.nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce

From nanog at ics-il.net  Fri Jul  1 15:40:39 2016
From: nanog at ics-il.net (Mike Hammett)
Date: Fri, 1 Jul 2016 10:40:39 -0500 (CDT)
Subject: IPv4 Legacy assignment frustration
In-Reply-To: <CAJ3iMJTBA2sdNgzYQjCxqSbwj+6cGXGa8gkcdM0CAstkZES7RQ@mail.gmail.com>
References: <A70F8E3612EA89458171DFBAA8A2A8DC83AD1063@UM-MBX-T03.um.umsystem.edu>
 <0DADFF47-F759-4D13-BAC4-3E16078A6E2C@gmail.com>
 <CAL9jLaZGgY-vomENCWeHNW3nSRo2VE3zqrjxxURr1u6YQ3Rgyw@mail.gmail.com>
 <A70F8E3612EA89458171DFBAA8A2A8DC83AD2F8D@UM-MBX-T03.um.umsystem.edu>
 <alpine.DEB.2.11.1606221440550.31112@grey.csi.cam.ac.uk>
 <CALsiHpwR8pdKg-a+hfE0LM1SifEstVhySV6ih+nnxAQUT1hLbw@mail.gmail.com>
 <CALFTrnO91jxid8PcTsyeN3RQM_46CARcyGXvanbGSqGWBaH92w@mail.gmail.com>
 <CAJ3iMJTBA2sdNgzYQjCxqSbwj+6cGXGa8gkcdM0CAstkZES7RQ@mail.gmail.com>
Message-ID: <2096785570.7382.1467387636452.JavaMail.mhammett@ThunderFuck>

<3 name and shame. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


----- Original Message -----

From: "Tom Smyth" <tom.smyth at wirelessconnect.eu> 
To: "Ray Soucy" <rps at maine.edu> 
Cc: nanog at nanog.org 
Sent: Thursday, June 23, 2016 10:23:39 AM 
Subject: Re: IPv4 Legacy assignment frustration 

Hi Ray, Kraig 
I think people affected just have to try to put pressure on their isps in 
the path between the afffected ips and hope for the best... public pressure 
is probably the only way to get around what I think most of us would agree 
is a terrible practice... I really hope that we can get rid of this 
practice as the last crumbs of IPv4 are carved up and re-distributed 
amongst new and growing isps. 

perhaps a name and shame project to highlight those isps that block ip 
ranges constantly and indiscriminately, 
needless to say the impact such practice has on peoples freedom to 
communicate, 

Thanks 

Tom Smyth 



On Thu, Jun 23, 2016 at 4:09 PM, Ray Soucy <rps at maine.edu> wrote: 

> Regardless of whether or not people "should" do this, I think the horse has 
> already left the barn on this one. I don't see any way of getting people 
> who decided to filter all of APNIC to make changes. Most of them are 
> static configurations that they'll never look to update. 
> 
> On Wed, Jun 22, 2016 at 12:06 PM, Kraig Beahn <kraig at enguity.com> wrote: 
> 
> > The following might add some clarity, depending upon how you look at it: 
> > 
> > We, as "core" engineers know better than to use some of the sources 
> listed 
> > below, tho, my suspicion is that when an engineer or local IT person, on 
> an 
> > edge network starts to see various types of attacks, they play 
> wack-a-mole, 
> > based upon outdated or incomplete data, and never think twice about 
> > revisiting such, as, from their perspective, everything is working just 
> > fine. 
> > 
> > In a networking psychology test, earlier this morning, I wrote to ten 
> > well-known colleagues that I was fairly confident didn't regularly follow 
> > the nanog lists. Such individuals comprised of IP and IT engineers for 
> > which manage various network sizes and enterprises, ultimately posing the 
> > question of "Where in the world is 150.201.15.7, as we were researching 
> > some unique traffic patterns". 
> > 
> > *Seven out of ten came back with overseas*. Two came back with more 
> > questions "as the address space appeared to be assigned to APNIC", but 
> was 
> > routed domestically. 
> > 
> > *One came back with the correct response.* (MORENET) 
> > 
> > Two of the queried parties were representative of major networks, one for 
> > an entire state governmental network with hundreds of thousands of actual 
> > users and tens of thousands of routers, the other from another major 
> > university. (Names left out, in the event they see this message later in 
> > the day or week) 
> > 
> > After probing the origin of their responses, I found the following 
> methods 
> > or data-sources were used: 
> > 
> > -Search Engines - by far, the worst offender. Not necessarily "the 
> engines" 
> > at fault, but a result of indexed sites containing inaccurate or outdated 
> > CIDR lists. 
> > -User generated forums, such as "Block non-North American Traffic for 
> > Dummies Like Me 
> > <https://www.webmasterworld.com/search_engine_spiders/4663915-2-30.htm>" 
> > (Yes - that's the actual thread name on WebMasterWorld.com, from a Sr. 
> > Member) 
> > -Static (or aged) CIDR web-page based lists, usually placed for 
> advertorial 
> > generation purposes and rarely up to date or accurate. (usually via SE's 
> or 
> > forum referrals) 
> > -APNIC themselves - A basic SE search resulted in an APNIC page 
> > < 
> > 
> https://www.apnic.net/manage-ip/manage-historical-resources/erx-project/erx-ranges 
> > > 
> > that, 
> > on it's face, appears to indicate 150.0.0.0/8 is in fact, part of the 
> > current APNIC range. 
> > -GitHub BGP Ranking tools: CIRCL / bgp-ranging example 
> > < 
> https://github.com/CIRCL/bgp-ranking/blob/master/lib/db_init/ip_del_list> 
> > (last 
> > updated on May 16th, 2011, tho an RT lookup 
> > <http://bgpranking.circl.lu/ip_lookup?ip=150.201.15.7> via the CIRCL 
> tool 
> > does shows the appropriate redirect/org) 
> > -Several routing oriented books and Cisco examples 
> > < 
> > 
> http://www.cisco.com/c/en/us/support/docs/ip/integrated-intermediate-system-to-intermediate-system-is-is/13796-route-leak.pdf 
> > > 
> > list 
> > such range, for example, FR/ISBN 2-212-09238-5. 
> > -And even established ISPs, that are publically announcing their "block 
> > list 
> > <http://www.albury.net.au/netstatus/derouted.html>", such as Albury's 
> > Local 
> > ISP in Australia 
> > 
> > The simple answer is to point IT directors, IP engineers or "the 
> > receptionists that manages the network" to the appropriate registry 
> > data-source, which should convince them that corrective action is 
> > necessary, i.e. fix your routing table or firewall. The complexity begins 
> > in trying to locate all of these people and directing them to the 
> > appropriate data-source, which I think is an unrealistic task, even for 
> the 
> > largest of operators. Maybe a nanog-edge group is in order. 
> > 
> > If the issue was beyond just a nuisance and If I were in your shoes, i'd 
> > renumber or use an alternate range for the types of traffic affected by 
> > such blocks, i.e. administrative web traffic trying to reach major 
> > insurance portals. (Looks like AS2572 is announcing just over 700k IPv4 
> > address, over about 43 ranges with only some potentially affected) 
> > 
> > Realizing that renumbering is also extremely unrealistic, if you haven't 
> > already reached the IPv6 bandwagon, that's an option or, if none of the 
> > above seem reasonable, you could always put together a one-page PDF that 
> > points these administrators to the appropriate resource to validate that 
> > you, are in fact, part of the domestic United States. 
> > 
> > I agree that a more accurate tool probably needs to be created for the 
> > "general population to consume," but then again, even that solution, is 
> > "just another tool" for the search-engines to index, and you're back at 
> > square one. 
> > 
> > As much as I think most of us would like to help fix this issue, I don't 
> > know that a decent, non-invasive solution exists, at least based upon the 
> > few hours we threw at this issue today... 
> > 
> > On Wed, Jun 22, 2016 at 10:37 AM, Tony Finch <dot at dotat.at> wrote: 
> > 
> > > Spurling, Shannon <shannon at more.net> wrote: 
> > > 
> > > > It?s a problem with the miss-use of the RIR delegation of a legacy 
> > > > block. 
> > > > 
> > > > The assumption that because a block is assigned to a particular RIR, 
> > all 
> > > > users in that block have to be in that RIR?s territory, without 
> > actually 
> > > > running a query against that RIR?s Whois database. 
> > > 
> > > Actually, a simple whois query often isn't enough to solve this 
> problem. 
> > > Neither RIPE nor APNIC do proper whois referrals for IPv4 addresses 
> that 
> > > are registered in other RIRs. ARIN, however, does. 
> > > 
> > > (However, if the geoip people are using whois data, I can't believe 
> they 
> > > aren't handling cases like this properly, because it's blatantly 
> obvious 
> > > if you scan IPv4 address space for referrals.) 
> > > 
> > > 
> > > If you use FreeBSD-CURRENT's whois client, it tries to work mostly by 
> > > following referrals, rather than using a built-in database mapping 
> query 
> > > strings to whois servers. If you query for 150.199.0.0 (for example) 
> you 
> > > get the following (which I have brutally trimmed for length): 
> > > 
> > > % IANA WHOIS server 
> > > 
> > > refer: whois.apnic.net 
> > > 
> > > inetnum: 150.0.0.0 - 150.255.255.255 
> > > organisation: Administered by APNIC 
> > > status: LEGACY 
> > > 
> > > % [whois.apnic.net] 
> > > 
> > > inetnum: 150.0.0.0 - 150.255.255.255 
> > > netname: ERX-NETBLOCK 
> > > descr: Early registration addresses 
> > > 
> > > remarks: Address ranges from this historical space have now 
> > > remarks: been transferred to the appropriate RIR 
> database.remarks: 
> > > remarks: If your search has returned this record, it means the 
> > > remarks: address range is not administered by APNIC. 
> > > remarks: 
> > > remarks: Instead, please search one of the following databases: 
> > > 
> > > (It then unhelpfully lists all the other RIRs.) 
> > > 
> > > FreeBSD's whois client spots this failure then retries the query at 
> ARIN. 
> > > 
> > > 
> > > There's a similar problem with RIPE, for instance if you query for 
> > > 141.211.0.0: 
> > > 
> > > % IANA WHOIS server 
> > > 
> > > refer: whois.ripe.net 
> > > 
> > > inetnum: 141.0.0.0 - 141.255.255.255 
> > > organisation: Administered by RIPE NCC 
> > > status: LEGACY 
> > > 
> > > % This is the RIPE Database query service. 
> > > 
> > > inetnum: 141.209.0.0 - 141.225.255.255 
> > > netname: NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK 
> > > descr: IPv4 address block not managed by the RIPE NCC 
> > > 
> > > remarks: You can find the whois server to query, or the 
> > > remarks: IANA registry to query on this web page: 
> > > remarks: http://www.iana.org/assignments/ipv4-address-space 
> > > remarks: 
> > > remarks: You can access databases of other RIRs at: 
> > > 
> > > (It then unhelpfully lists all the other RIRs.) 
> > > 
> > > Actually RIPE is even worse than APNIC because it implicitly has a 
> > > referral loop between IANA and RIPE. 
> > > 
> > > 
> > > BUT NOTE! 
> > > 
> > > The APNIC and RIPE databases do in fact contain the referral 
> information 
> > - 
> > > you can get it via RDAP but not whois. Repeating the examples, 
> > > 
> > > $ curl -i https://rdap.apnic.net/ip/150.199.0.0 
> > > HTTP/1.1 301 Moved Permanently 
> > > Location: https://rdap.arin.net/registry/ip/150.199.0.0 
> > > 
> > > $ curl -i https://rdap.db.ripe.net/ip/141.211.0.0 
> > > HTTP/1.1 301 Moved Permanently 
> > > Location: https://rdap.arin.net/registry/ip/141.211.0.0 
> > > 
> > > 
> > > Tony. 
> > > -- 
> > > f.anthony.n.finch <dot at dotat.at> http://dotat.at/ - I xn--zr8h 
> > > punycode 
> > > Biscay: Cyclonic becoming mainly northwest, 4 or 5. Moderate. Fog 
> > patches, 
> > > thundery showers. Moderate, occasionally very poor. 
> > > 
> > 
> > 
> > 
> > -- 
> > 
> 
> 
> 
> -- 
> Ray Patrick Soucy 
> Senior Cyber Security Engineer 
> Networkmaine, University of Maine System US:IT 
> 
> 207-561-3526 
> 



-- 
Kindest regards, 
Tom Smyth 

Mobile: +353 87 6193172 
--------------------------------- 
PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL 
This email contains information which may be confidential or privileged. 
The information is intended solely for the use of the individual or entity 
named above. If you are not the intended recipient, be aware that 
any disclosure, copying, distribution or use of the contents of this 
information is prohibited. If you have received this electronic 
transmission in error, please notify me by telephone or by electronic mail 
immediately. Any opinions expressed are those of the author, not the 
company's .This email does not constitute either offer or acceptance of 
any contractually binding agreement. Such offer or acceptance must be 
communicated in 
writing. You are requested to carry out your own virus check before opening 
any attachment. Thomas Smyth accepts no liability for any loss or damage 
which may be caused by malicious software or attachments. 


From owen at delong.com  Fri Jul  1 17:08:35 2016
From: owen at delong.com (Owen DeLong)
Date: Fri, 1 Jul 2016 10:08:35 -0700
Subject: NANOG67 - Tipping point of community and sponsor bashing?
In-Reply-To: <CAObxEFBR5XGYhomFBYv2Kp-TNNyOsL+nEOwRQB4h7FFkQyRUpg@mail.gmail.com>
References: <CAFN0R26s22kpK_97WtKBbG-iNUkzpn2pZ24kWMsJih=+-WSKQg@mail.gmail.com>
 <20160614155024.GB8504@bamboo.slabnet.com>
 <AEEA2158-B269-485C-B384-A3B48E67086A@ianai.net>
 <CAD6AjGTfYMLu_AqEQaYNuREPLxAhtDiH5L8PGzrD1L_r8p=HxA@mail.gmail.com>
 <CADn4PSgE_LycEwMyK6dKLCWKQeB7c18CAQjD6A7qunh4Exf9DA@mail.gmail.com>
 <57603722.4000609@bryanfields.net>
 <D7D5CA90-8558-4EE5-8BE9-512E7303E1F2@delong.com>
 <CAO1bj=Z9ZfzfdKofSOnPDM_FpuS22OruwGxsVqak2EQeQhAoFQ@mail.gmail.com>
 <CAFJiuFpzO91_coAp=2VUQKaiKehXCPZAJsvWeG_5yTE0j-UuWw@mail.gmail.com>
 <9DBE06AF-E738-465B-9D19-A8270AFA1AF0@netnod.se>
 <CAPkb-7BckbR=ab7pWvE8h4zYUe3hc_iLPKFu_vNbqmFVJ=ppjQ@mail.gmail.com>
 <987088bd-0467-ede7-78a0-5c8f52fe9c04@nordu.net>
 <00d957e5-5310-619d-49b9-221fbf5916a8@nipper.de>
 <CADn4PSgjyQJyU6aUmbPbJMQGQx9PGTSG_Vx9=rFkN__wJq7U7Q@mail.gmail.com>
 <CAObxEFBR5XGYhomFBYv2Kp-TNNyOsL+nEOwRQB4h7FFkQyRUpg@mail.gmail.com>
Message-ID: <07AE89CA-2916-4347-8D21-732C1A5277B7@delong.com>

I have to agree with Rick here.

Owen

> On Jun 29, 2016, at 22:43 , Rick Astley <jnanog at gmail.com> wrote:
> 
> I have to agree with Dan in that even if you disagreed with the talk you
> have to agree that it probably spawned relevant discussion and reflection
> (both on and off list). I would hate to see a move to ideas and discussions
> that are chosen simply for offending the fewest people. Another sort of
> similar critique aimed at large routing vendors was "Help! My big expensive
> router is really expensive" at NANOG 60 in Atlanta. Perhaps the critiques
> were seen as more constructive and I don't remember the same backlash after
> the talk but I found both talks and various discussions that followed
> insightful.
> 
> On Fri, Jun 17, 2016 at 4:53 PM, Daniel Golding <dgolding at gmail.com> wrote:
> 
>> Hmm - as far as whether this was a good or bad NANOG presentation...this is
>> some of the best discussion I've seen on list in a while. There is a frank
>> exchange of views between many different parties. This may result in some
>> follow-up presentations at future NANOGs by IXP operators (please!).
>> 
>> Seems that, whether you agree with Dave or not, it was successful. It also
>> seems that the IXP operators who came under the most criticism have reacted
>> with a lot of professionalism and maturity. Other IXP operators have
>> reacted pretty poorly, which is ironic.
>> 
>> Dan
>> 


From lyndon at orthanc.ca  Fri Jul  1 19:23:48 2016
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Fri, 1 Jul 2016 12:23:48 -0700
Subject: yahoo mta admin help needed
Message-ID: <A12BDEF0-5B3B-4570-92F9-029BDD6A801C@orthanc.ca>

Is there a Yahoo MTA admin listening who can help diagnose what might be a network ACL block to one of our SMTP server subnets?

Thanks,

--lyndon


From zwicky at yahoo-inc.com  Fri Jul  1 19:33:48 2016
From: zwicky at yahoo-inc.com (Elizabeth Zwicky)
Date: Fri, 1 Jul 2016 19:33:48 +0000 (UTC)
Subject: yahoo mta admin help needed
In-Reply-To: <A12BDEF0-5B3B-4570-92F9-029BDD6A801C@orthanc.ca>
References: <A12BDEF0-5B3B-4570-92F9-029BDD6A801C@orthanc.ca>
Message-ID: <957394128.59658.1467401628423.JavaMail.yahoo@mail.yahoo.com>


Start by going to https://postmaster.yahoo.com?and describing symptoms (they're not going to respond well to mentions of ACL blocks, and will want to know what's actually happening in SMTP).
Also, timeouts on the Yahoo side are also rare in the extreme, so if your problem is that attempts time out or vanish into a black hole, I would start troubleshooting elsewhere.
Elizabeth Zwicky

    On Friday, July 1, 2016 12:27 PM, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
 

 Is there a Yahoo MTA admin listening who can help diagnose what might be a network ACL block to one of our SMTP server subnets?

Thanks,

--lyndon


  

From mike at mikejones.in  Fri Jul  1 19:52:33 2016
From: mike at mikejones.in (Mike Jones)
Date: Fri, 1 Jul 2016 20:52:33 +0100
Subject: IPv6 deployment excuses
Message-ID: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>

Hi,

I am in contact with a couple of network operators trying to prod them
to deploy IPv6, I figured that 10 minutes to send a couple of emails
was worth the effort to make them "see a customer demand" (now none of
them can use the excuse that nobody has asked for it!), but the
replies I got were less than impressive to say the least.

I was wondering if you guys could summarise your experiences with
people who make excuses for not deploying IPv6? I regularly see a
specific person saying "we can't deploy it because X" followed by you
guys "correcting them" and telling them how to deploy it without the
problems they claim they will have, but that is only a small snapshot
of the people who bother to post about their ignorance in public. I
suspect there is also a lot of selection-bias in the NANOG membership
base but you deal with a lot of enterprise networks off of this list
so probably have broader experience than the NANOG archives.

Can we have a thread summarising the most common excuses you've heard,
and if they are actual problems blocking IPv6 deployment or just down
to ignorance? Perhaps this could be the basis for an FAQ type page
that I can point people to when they say they don't know how to deploy
IPv6 on their networks? :)

- Mike Jones

From saper at saper.info  Fri Jul  1 20:10:47 2016
From: saper at saper.info (Marcin Cieslak)
Date: Fri, 1 Jul 2016 20:10:47 +0000
Subject: IPv6 deployment excuses
In-Reply-To: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
Message-ID: <alpine.BSF.2.11.1607012002391.12110@z.fncre.vasb>

On Fri, 1 Jul 2016, Mike Jones wrote:

> Hi,
> 
> I am in contact with a couple of network operators trying to prod them
> to deploy IPv6, I figured that 10 minutes to send a couple of emails
> was worth the effort to make them "see a customer demand" (now none of
> them can use the excuse that nobody has asked for it!), but the
> replies I got were less than impressive to say the least.

When I talked to one European residential cable provider ca. 2008
they used a similar argument. Fast forward to 2016 and
IPv6 (and dual stack lite) is *the* way they provide Internet access
those days. The reason is simple: their growth rate is way too high
to provide IPv4 to everyone at this point.

If the provider is still using the "see a customer demand" argument
this could mean their IPv4 demand may not be growing fast enough. 
Depending on the market they operate on this an be an indication that
their market growth rate may not be fast enough.

Maybe their customer demand for IP(v4) leaves something to be desired?
Or they sit on some almost empty /8s.

Marcin

From hugo at slabnet.com  Fri Jul  1 21:00:47 2016
From: hugo at slabnet.com (Hugo Slabbert)
Date: Fri, 1 Jul 2016 14:00:47 -0700 (PDT)
Subject: IPv6 deployment excuses
In-Reply-To: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
Message-ID: <3e1b229.kqhkiG.155a8439000@slabnet.com>



---- From: Mike Jones <mike at mikejones.in> -- Sent: 2016-07-01 - 12:52 ----

> Hi,
>
> I am in contact with a couple of network operators trying to prod them
> to deploy IPv6, I figured that 10 minutes to send a couple of emails
> was worth the effort to make them "see a customer demand" (now none of
> them can use the excuse that nobody has asked for it!), but the
> replies I got were less than impressive to say the least.
>
> I was wondering if you guys could summarise your experiences with
> people who make excuses for not deploying IPv6?

http://ipv6excuses.com/
https://twitter.com/ipv6excuses

>
> - Mike Jones
>

--
Hugo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 821 bytes
Desc: PGP/MIME digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160701/2b99b52a/attachment.pgp>

From jared at puck.nether.net  Fri Jul  1 21:26:32 2016
From: jared at puck.nether.net (Jared Mauch)
Date: Fri, 1 Jul 2016 17:26:32 -0400
Subject: IPv6 deployment excuses
In-Reply-To: <3e1b229.kqhkiG.155a8439000@slabnet.com>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <3e1b229.kqhkiG.155a8439000@slabnet.com>
Message-ID: <2634D4B9-A92B-408F-87C8-AA9C0A8CCEFB@puck.nether.net>

https://youtu.be/v26BAlfWBm8

Is always good for a reminder and laughs on a holiday weekend. 

Jared Mauch

> On Jul 1, 2016, at 5:00 PM, Hugo Slabbert <hugo at slabnet.com> wrote:
> 
> http://ipv6excuses.com/
> https://twitter.com/ipv6excuses

From gwardell at gwsystems.co.il  Fri Jul  1 21:43:21 2016
From: gwardell at gwsystems.co.il (Gary Wardell)
Date: Fri, 1 Jul 2016 17:43:21 -0400
Subject: IPv6 deployment excuses
In-Reply-To: <3e1b229.kqhkiG.155a8439000@slabnet.com>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <3e1b229.kqhkiG.155a8439000@slabnet.com>
Message-ID: <013001d1d3e1$96dbbae0$c49330a0$@gwsystems.co.il>

> 
> http://ipv6excuses.com/

That website only supports IPv4.

Gary




From alarig at swordarmor.fr  Fri Jul  1 21:53:12 2016
From: alarig at swordarmor.fr (Alarig Le Lay)
Date: Fri, 1 Jul 2016 23:53:12 +0200
Subject: IPv6 deployment excuses
In-Reply-To: <013001d1d3e1$96dbbae0$c49330a0$@gwsystems.co.il>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <3e1b229.kqhkiG.155a8439000@slabnet.com>
 <013001d1d3e1$96dbbae0$c49330a0$@gwsystems.co.il>
Message-ID: <20160701215312.GU16573@bulbizarre.swordarmor.fr>

On Fri Jul  1 17:43:21 2016, Gary Wardell wrote:
> > 
> > http://ipv6excuses.com/
> 
> That website only supports IPv4.

It?s on your side.

alarig at pikachu ~ % telnet ipv6excuses.com http
Trying 2403:7000:8000:500::26...
Connected to ipv6excuses.com.
Escape character is '^]'.
^]
telnet> quit
Connection closed.

-- 
alarig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160701/db9aa9bf/attachment.pgp>

From hugo at slabnet.com  Fri Jul  1 22:00:01 2016
From: hugo at slabnet.com (Hugo Slabbert)
Date: Fri, 1 Jul 2016 15:00:01 -0700 (PDT)
Subject: IPv6 deployment excuses
In-Reply-To: <20160701215312.GU16573@bulbizarre.swordarmor.fr>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <3e1b229.kqhkiG.155a8439000@slabnet.com>
 <013001d1d3e1$96dbbae0$c49330a0$@gwsystems.co.il>
 <20160701215312.GU16573@bulbizarre.swordarmor.fr>
Message-ID: <3f87fb8.kqhkiG.155a879c7b8@slabnet.com>

---- From: Alarig Le Lay <alarig at swordarmor.fr> -- Sent: 2016-07-01 - 14:53 ----

> On Fri Jul  1 17:43:21 2016, Gary Wardell wrote:
>> >
>> > http://ipv6excuses.com/
>>
>> That website only supports IPv4.
>
> It?s on your side.
>
> alarig at pikachu ~ % telnet ipv6excuses.com http
> Trying 2403:7000:8000:500::26...
> Connected to ipv6excuses.com.
> Escape character is '^]'.
> ^]
> telnet> quit
> Connection closed.
>
> --
> alarig

twitter.com, OTOH...

--
Hugo


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 821 bytes
Desc: PGP/MIME digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160701/232cce11/attachment.pgp>

From gwardell at gwsystems.co.il  Fri Jul  1 23:25:25 2016
From: gwardell at gwsystems.co.il (Gary Wardell)
Date: Fri, 1 Jul 2016 19:25:25 -0400
Subject: IPv6 deployment excuses
In-Reply-To: <20160701215312.GU16573@bulbizarre.swordarmor.fr>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <3e1b229.kqhkiG.155a8439000@slabnet.com>
 <013001d1d3e1$96dbbae0$c49330a0$@gwsystems.co.il>
 <20160701215312.GU16573@bulbizarre.swordarmor.fr>
Message-ID: <015f01d1d3ef$d8d335a0$8a79a0e0$@gwsystems.co.il>

Ok, 

 

I didn't dig.

 

Evidently it's because not all of the content could be delivered over v6.

 



 

> -----Original Message-----

> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Alarig Le

> Lay

> Sent: Friday, July 01, 2016 5:53 PM

> To: nanog at nanog.org

> Subject: Re: IPv6 deployment excuses

> 

> On Fri Jul  1 17:43:21 2016, Gary Wardell wrote:

> > >

> > >  <http://ipv6excuses.com/> http://ipv6excuses.com/

> >

> > That website only supports IPv4.

> 

> It?s on your side.

> 

> alarig at pikachu ~ % telnet ipv6excuses.com http Trying

> 2403:7000:8000:500::26...

> Connected to ipv6excuses.com.

> Escape character is '^]'.

> ^]

> telnet> quit

> Connection closed.

> 

> --

> alarig


From dbrisson at uvm.edu  Sat Jul  2 00:52:26 2016
From: dbrisson at uvm.edu (Daniel Brisson)
Date: Sat, 2 Jul 2016 00:52:26 +0000
Subject: Charter CMTS help requested
Message-ID: <93C2B3B0-113E-410A-A3A1-AC328F4D2CDB@uvm.edu>

Hello,

I?m hoping a Charter engineer with CMTS expertise would be willing to hit me off-list regarding a chronic connectivity issue.  I?m getting nowhere with customer service or escalation and would love to talk to someone who could get to the root cause.

Thanks in advance,
-dan

From mohta at necom830.hpcl.titech.ac.jp  Sat Jul  2 03:49:50 2016
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sat, 2 Jul 2016 12:49:50 +0900
Subject: IPv6 deployment excuses
In-Reply-To: <2634D4B9-A92B-408F-87C8-AA9C0A8CCEFB@puck.nether.net>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <3e1b229.kqhkiG.155a8439000@slabnet.com>
 <2634D4B9-A92B-408F-87C8-AA9C0A8CCEFB@puck.nether.net>
Message-ID: <13e05110-89bf-a000-f7e3-1b7c39ad8588@necom830.hpcl.titech.ac.jp>

Jared Mauch wrote:

> https://youtu.be/v26BAlfWBm8
>
> Is always good for a reminder and laughs on a holiday weekend.

But, end to end NATs are actually good:

	https://tools.ietf.org/html/draft-ohta-e2e-nat-00

fully transparent to all the transport and application layer
protocols.

And, to applications running over TCP/UDP, UPnP capable legacy
NATs are transparent, if host TCP/UDP are modified to perform
reverse NAT, information to do so is provided by UPnP.

						Masataka Ohta

From jared at puck.nether.net  Sat Jul  2 11:12:22 2016
From: jared at puck.nether.net (Jared Mauch)
Date: Sat, 2 Jul 2016 07:12:22 -0400
Subject: IPv6 deployment excuses
In-Reply-To: <13e05110-89bf-a000-f7e3-1b7c39ad8588@necom830.hpcl.titech.ac.jp>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <3e1b229.kqhkiG.155a8439000@slabnet.com>
 <2634D4B9-A92B-408F-87C8-AA9C0A8CCEFB@puck.nether.net>
 <13e05110-89bf-a000-f7e3-1b7c39ad8588@necom830.hpcl.titech.ac.jp>
Message-ID: <C352698F-3520-4405-86B7-6150815352A7@puck.nether.net>

Actually they are not that great. Look at the DDoS mess that UPnP has created and problems for IoT (I call it Internet of trash, as most devices are poorly implemented without safety in mind) folks on all sides. 

The fact that I go to a hotel and that AT&T mobility have limited internet reach is a technology problem that we all must work to fix. 

Jared Mauch

> On Jul 1, 2016, at 11:49 PM, Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp> wrote:
> 
> And, to applications running over TCP/UDP, UPnP capable legacy
> NATs are transparent, if host TCP/UDP are modified to perform
> reverse NAT, information to do so is provided by UPnP.


From mike at mikejones.in  Sat Jul  2 11:44:24 2016
From: mike at mikejones.in (Mike Jones)
Date: Sat, 2 Jul 2016 12:44:24 +0100
Subject: IPv6 deployment excuses
In-Reply-To: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
Message-ID: <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>

Thanks guys, this is what I have come up with so far. Next week i'll
put together a web page or something with slightly better write-ups,
but these are my initial ideas for responses to each point. Better
answers would be welcome.

"We have NAT, therefore we don't need IPv6."
"We still have plenty of IPv4 addresses"
"IPv4 works so we don't need IPv6."

They said similar things about IPX, DECNET, Appletalk........ but they
eventually realised it was easier to move to IP than to keep making
excuses for why their network can't connect to anything.

"we want NAT for IPv6 for security reasons"

NAT does not provide any security, typically a NAT will also include a
stateful firewall which provides the security. You can deploy a
stateful firewall for your IPv6 network if you like, however it isn't
required as much as you probably think it is - see below.

"IPv6 is just another way for hackers to get in."

There is no difference between IPv4 and IPv6 when it comes to
firewalls and reachability. It is worth noting that hosts which
support IPv6 are typically a lot more secure than older IPv4-only
hosts. As an example every version of Windows that ships with IPv6
support also ships with the firewall turned on by default.

"End users don't care about IPv6"

Are you saying this in response to someone asking for IPv6? because
that would be contradictory. I am an end user and I care about IPv6!

"But it isn't a priority and we have other stuff to do"

Reconfiguring every router on your network is not something you want
to rush when you realise you needed IPv6 yesterday, early adopters
have the advantage that they can gain experience with running IPv6 and
test their infrastructure without worrying about critical traffic
being IPv6-only.

"None of the software vendors support IPv6."

If your software vendors were following best practices and writing
decent code then this would not be a problem, I suggest pushing your
vendors to fix their code. If you only have 1 of two systems that are
IPv4-only then you can always "special case" them. See NAT64 for
information about one way of reaching IPv4 hosts from an IPv6 network.
If you dual stack then it doesn't matter and you can just use IPv4 for
those few services than require it until you get a fix from the
vendor.

"None of our staff understand IPv6."

Do your staff understand IPv4? because it's not that different...

"IPv6 addresses are too long to remember"

You shouldn't need to remember IP addresses, that's what DNS is for.
However I will say that in my experience and many other peoples having
the extra bits to structure your network in a logical fasion can make
addresses more obvious and easier to remember. You have a single
prefix to remember, then can address hosts within that subnet however
you like. In IPv4 you rarely have the luxury of being able to number
your DNS server 192.0.2.53 and your web server 192.0.2.80 to make them
easier to remember, whereas in IPv6 you can easily assign hosts easy
to remember addresses.

"Having to dual stack means I still have to manage a 4 and 6 network."

Good point, however if you want to ease your network management and
run an IPv6-only network with IPv4-only services still reachable over
the top of it then there are several ways to do it, the most obvious
being NAT64.

"Our DNS provider won't let us as add AAAA records"

Seriously? who is your DNS provider? You need to ask them why they
don't support standard record types. If they refuse to add standard
records to your zone, get a new provider there are plenty out there.

"We'll deploy IPv6 right after we finish deploying DNSSEC"

The 2 are not mutually exclusive - at a large organisation where this
sort of project would be major work, you probably have different teams
dealing with IP and DNS so there's no reason one would stop the other.

"But Android doesn't support stateful DHCPv6."

I will admit that the specifications were written a little loosely so
you have 2 ways of configuring hosts, however if you configure both RA
and DHCP then you will cover 100% of IPv6-capible hosts.

"Our legal intercept setup does not work with IPv6"

If your lawful intercept equipment can't see traffic just because they
used an "unknown" protocol then it has a major flaw!

- Mike Jones

From ruairi.carroll at gmail.com  Sat Jul  2 15:35:05 2016
From: ruairi.carroll at gmail.com (Ruairi Carroll)
Date: Sat, 2 Jul 2016 17:35:05 +0200
Subject: IPv6 deployment excuses
In-Reply-To: <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
Message-ID: <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>

Issues I've faced in the past with v6 deployments, from the point of view
of stub networks. Feel free to pick/choose as you wish:

- Badly understood (By the team) methods to assign addressing to servers.
- Poor tooling in regards to log processing/external providers.
- Unknown cost in dev time to debug badly written applications (ie: cheaper
to buy v4 space than assign dev time, which is inherently expensive)
- PMTUD issues (Mostly around PTB handling)
- ECMP issues (Mostly around flow labels and vendor support for that, also
feeds back into PMTUD issues)
- Cogent/HE "spat" causes legitimate concerns about reachability (ie: why
should I buy an extra transit because someone else is playing silly buggers)
- Lack of backbone forces stubs to de-aggregate to much annoyance (but 0
choice) of everyone else
- Maintaining 2x IP stacks is inherently expensive Vs 1


Of course, you can say "v4 has these issues too" to some of these, and call
bullshit on others. That's not the point, I'm just airing some issues that
can be deal breakers.

I would imagine that as v4 becomes more expensive, most of the list will no
longer be an issue.

/Ruairi





On 2 July 2016 at 13:44, Mike Jones <mike at mikejones.in> wrote:

> Thanks guys, this is what I have come up with so far. Next week i'll
> put together a web page or something with slightly better write-ups,
> but these are my initial ideas for responses to each point. Better
> answers would be welcome.
>
> "We have NAT, therefore we don't need IPv6."
> "We still have plenty of IPv4 addresses"
> "IPv4 works so we don't need IPv6."
>
> They said similar things about IPX, DECNET, Appletalk........ but they
> eventually realised it was easier to move to IP than to keep making
> excuses for why their network can't connect to anything.
>
> "we want NAT for IPv6 for security reasons"
>
> NAT does not provide any security, typically a NAT will also include a
> stateful firewall which provides the security. You can deploy a
> stateful firewall for your IPv6 network if you like, however it isn't
> required as much as you probably think it is - see below.
>
> "IPv6 is just another way for hackers to get in."
>
> There is no difference between IPv4 and IPv6 when it comes to
> firewalls and reachability. It is worth noting that hosts which
> support IPv6 are typically a lot more secure than older IPv4-only
> hosts. As an example every version of Windows that ships with IPv6
> support also ships with the firewall turned on by default.
>
> "End users don't care about IPv6"
>
> Are you saying this in response to someone asking for IPv6? because
> that would be contradictory. I am an end user and I care about IPv6!
>
> "But it isn't a priority and we have other stuff to do"
>
> Reconfiguring every router on your network is not something you want
> to rush when you realise you needed IPv6 yesterday, early adopters
> have the advantage that they can gain experience with running IPv6 and
> test their infrastructure without worrying about critical traffic
> being IPv6-only.
>
> "None of the software vendors support IPv6."
>
> If your software vendors were following best practices and writing
> decent code then this would not be a problem, I suggest pushing your
> vendors to fix their code. If you only have 1 of two systems that are
> IPv4-only then you can always "special case" them. See NAT64 for
> information about one way of reaching IPv4 hosts from an IPv6 network.
> If you dual stack then it doesn't matter and you can just use IPv4 for
> those few services than require it until you get a fix from the
> vendor.
>
> "None of our staff understand IPv6."
>
> Do your staff understand IPv4? because it's not that different...
>
> "IPv6 addresses are too long to remember"
>
> You shouldn't need to remember IP addresses, that's what DNS is for.
> However I will say that in my experience and many other peoples having
> the extra bits to structure your network in a logical fasion can make
> addresses more obvious and easier to remember. You have a single
> prefix to remember, then can address hosts within that subnet however
> you like. In IPv4 you rarely have the luxury of being able to number
> your DNS server 192.0.2.53 and your web server 192.0.2.80 to make them
> easier to remember, whereas in IPv6 you can easily assign hosts easy
> to remember addresses.
>
> "Having to dual stack means I still have to manage a 4 and 6 network."
>
> Good point, however if you want to ease your network management and
> run an IPv6-only network with IPv4-only services still reachable over
> the top of it then there are several ways to do it, the most obvious
> being NAT64.
>
> "Our DNS provider won't let us as add AAAA records"
>
> Seriously? who is your DNS provider? You need to ask them why they
> don't support standard record types. If they refuse to add standard
> records to your zone, get a new provider there are plenty out there.
>
> "We'll deploy IPv6 right after we finish deploying DNSSEC"
>
> The 2 are not mutually exclusive - at a large organisation where this
> sort of project would be major work, you probably have different teams
> dealing with IP and DNS so there's no reason one would stop the other.
>
> "But Android doesn't support stateful DHCPv6."
>
> I will admit that the specifications were written a little loosely so
> you have 2 ways of configuring hosts, however if you configure both RA
> and DHCP then you will cover 100% of IPv6-capible hosts.
>
> "Our legal intercept setup does not work with IPv6"
>
> If your lawful intercept equipment can't see traffic just because they
> used an "unknown" protocol then it has a major flaw!
>
> - Mike Jones
>

From kmedcalf at dessus.com  Sat Jul  2 15:37:13 2016
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Sat, 02 Jul 2016 09:37:13 -0600
Subject: IPv6 deployment excuses
In-Reply-To: <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
Message-ID: <34df7da568d43b45ad87565fcec90ffa@mail.dessus.com>


> There is no difference between IPv4 and IPv6 when it comes to
> firewalls and reachability. It is worth noting that hosts which
> support IPv6 are typically a lot more secure than older IPv4-only
> hosts. As an example every version of Windows that ships with IPv6
> support also ships with the firewall turned on by default.

Just because the firewall is turned on does not mean that it is configured properly.  

Every version of Windows that ships with IPv6 support also ships with the Firewall configured in such a fashion that you may as well have it turned off.  

This is especially true in Windows 8 and later where the firewall is reconfigured without your permission by Microsoft every time you install any update whatsoever back to the "totally insecure" default state -- and there is absolutely no way to fix this other than to check, every single minute, that the firewall is still configured as you configured it, and not as Microsoft (and their NSA partners) choose to configure it.

All versions of Windows 8 and later whether using IPv4 or IPv6 are completely unsuitable for use on a network attached to the Internet by any means (whether using NAT or not) that does not include an external (to Windows) -- ie, in network -- statefull firewall over which Windows, Microsoft, (and their NSA partners) have no automatic means of control.  If you allow UPnP control of the external statefull firewall from Windows version 8 or later, you may as well not bother having any firewall at all because it is not under your control.





From sryan at arbor.net  Sat Jul  2 16:07:55 2016
From: sryan at arbor.net (Spencer Ryan)
Date: Sat, 2 Jul 2016 12:07:55 -0400
Subject: IPv6 deployment excuses
In-Reply-To: <34df7da568d43b45ad87565fcec90ffa@mail.dessus.com>
References: <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <34df7da568d43b45ad87565fcec90ffa@mail.dessus.com>
Message-ID: <CA+HzidT=716bnS9LSoZW-80KYSydhj04N7ZCSz7+asp9WCJLAA@mail.gmail.com>

Windows 8 and 10 with the most recent service packs default the firewall to
on with very few inbound exemptions.

On Jul 2, 2016 11:38 AM, "Keith Medcalf" <kmedcalf at dessus.com> wrote:

>
> > There is no difference between IPv4 and IPv6 when it comes to
> > firewalls and reachability. It is worth noting that hosts which
> > support IPv6 are typically a lot more secure than older IPv4-only
> > hosts. As an example every version of Windows that ships with IPv6
> > support also ships with the firewall turned on by default.
>
> Just because the firewall is turned on does not mean that it is configured
> properly.
>
> Every version of Windows that ships with IPv6 support also ships with the
> Firewall configured in such a fashion that you may as well have it turned
> off.
>
> This is especially true in Windows 8 and later where the firewall is
> reconfigured without your permission by Microsoft every time you install
> any update whatsoever back to the "totally insecure" default state -- and
> there is absolutely no way to fix this other than to check, every single
> minute, that the firewall is still configured as you configured it, and not
> as Microsoft (and their NSA partners) choose to configure it.
>
> All versions of Windows 8 and later whether using IPv4 or IPv6 are
> completely unsuitable for use on a network attached to the Internet by any
> means (whether using NAT or not) that does not include an external (to
> Windows) -- ie, in network -- statefull firewall over which Windows,
> Microsoft, (and their NSA partners) have no automatic means of control.  If
> you allow UPnP control of the external statefull firewall from Windows
> version 8 or later, you may as well not bother having any firewall at all
> because it is not under your control.
>
>
>
>
>

From kmedcalf at dessus.com  Sat Jul  2 16:41:48 2016
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Sat, 02 Jul 2016 10:41:48 -0600
Subject: IPv6 deployment excuses
In-Reply-To: <CA+HzidT=716bnS9LSoZW-80KYSydhj04N7ZCSz7+asp9WCJLAA@mail.gmail.com>
Message-ID: <04f1d90c3975174680957a9f22f940d6@mail.dessus.com>


Yes, the default is "on".  An exception is added for EVERY SINGLE PIECE of Microsoft Crapware, whether it is needed or not (and in every single case, it is not).  And if you turn those exceptions "off", then they are turned back on by Microsoft and their NSA partners for you, without your permission, whenever automatic updates run (and also at other times that I have not determined the trigger).  You must continuously check that the firewall (although ON) remains configured as you configured it, or if Microsoft (and their NSA partners) have changed the configuration without your permission.

Of course, most people do not bother configuring the firewall and do not wonder why every piece of Crapware has in incoming exception, and do not bother to turn those off (including some on this list apparently).  So they will never notice these nefarious doings which have been a hotbed of discussion on the Internet for many years.

And this is on the latest distribution of Windows 10 including the upcoming anniversary edition and has been that way since at least the first version of Windows 8.

Whether or not Windows 7 also behaves the same way I do not know because I never ran it.

> -----Original Message-----
> From: Spencer Ryan [mailto:sryan at arbor.net]
> Sent: Saturday, 2 July, 2016 10:08
> To: Keith Medcalf
> Cc: North American Network Operators' Group
> Subject: RE: IPv6 deployment excuses
> 
> Windows 8 and 10 with the most recent service packs default the firewall
> to on with very few inbound exemptions.
> 
> 
> On Jul 2, 2016 11:38 AM, "Keith Medcalf" <kmedcalf at dessus.com> wrote:
> 
> 
> 
> 	> There is no difference between IPv4 and IPv6 when it comes to
> 	> firewalls and reachability. It is worth noting that hosts which
> 	> support IPv6 are typically a lot more secure than older IPv4-only
> 	> hosts. As an example every version of Windows that ships with IPv6
> 	> support also ships with the firewall turned on by default.
> 
> 	Just because the firewall is turned on does not mean that it is
> configured properly.
> 
> 	Every version of Windows that ships with IPv6 support also ships
> with the Firewall configured in such a fashion that you may as well have
> it turned off.
> 
> 	This is especially true in Windows 8 and later where the firewall is
> reconfigured without your permission by Microsoft every time you install
> any update whatsoever back to the "totally insecure" default state -- and
> there is absolutely no way to fix this other than to check, every single
> minute, that the firewall is still configured as you configured it, and
> not as Microsoft (and their NSA partners) choose to configure it.
> 
> 	All versions of Windows 8 and later whether using IPv4 or IPv6 are
> completely unsuitable for use on a network attached to the Internet by any
> means (whether using NAT or not) that does not include an external (to
> Windows) -- ie, in network -- statefull firewall over which Windows,
> Microsoft, (and their NSA partners) have no automatic means of control.
> If you allow UPnP control of the external statefull firewall from Windows
> version 8 or later, you may as well not bother having any firewall at all
> because it is not under your control.
> 
> 
> 
> 
> 





From lost at l-w.ca  Sat Jul  2 16:49:40 2016
From: lost at l-w.ca (William Astle)
Date: Sat, 2 Jul 2016 10:49:40 -0600
Subject: IPv6 deployment excuses
In-Reply-To: <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
Message-ID: <5777F0A4.4040102@l-w.ca>

There's one other major issue faced by stub networks which I have 
encountered at $DAYJOB:

- My upstream(s) refuse(s) to support IPv6

This *is* a deal breaker. The pat response of "get new upstreams" is not 
helpful and shows the distinct bias among this community to the large 
players who actually have budgets to work with. It's not always possible 
to change to a better upstream and even when it is, it is often 
prohibitively expensive. This is particularly the case with colocation 
where the cost of changing providers is huge as it requires physically 
relocating equipment. That either requires doubling up (very expensive) 
or non-trivial downtime (also likely very expensive). This is an 
especially sad state of affairs given that at least one very large 
network (AS701) has pulled this refusal at some data centres on their 
network. Their specific excuse du jour changes every few months but it 
usually boils down to "we don't want to put any effort or resources into 
updating anything".

On 16-07-02 09:35 AM, Ruairi Carroll wrote:
> Issues I've faced in the past with v6 deployments, from the point of view
> of stub networks. Feel free to pick/choose as you wish:
>
> - Badly understood (By the team) methods to assign addressing to servers.
> - Poor tooling in regards to log processing/external providers.
> - Unknown cost in dev time to debug badly written applications (ie: cheaper
> to buy v4 space than assign dev time, which is inherently expensive)
> - PMTUD issues (Mostly around PTB handling)
> - ECMP issues (Mostly around flow labels and vendor support for that, also
> feeds back into PMTUD issues)
> - Cogent/HE "spat" causes legitimate concerns about reachability (ie: why
> should I buy an extra transit because someone else is playing silly buggers)
> - Lack of backbone forces stubs to de-aggregate to much annoyance (but 0
> choice) of everyone else
> - Maintaining 2x IP stacks is inherently expensive Vs 1
>
>
> Of course, you can say "v4 has these issues too" to some of these, and call
> bullshit on others. That's not the point, I'm just airing some issues that
> can be deal breakers.
>
> I would imagine that as v4 becomes more expensive, most of the list will no
> longer be an issue.
>
> /Ruairi
>
>
>
>
>
> On 2 July 2016 at 13:44, Mike Jones <mike at mikejones.in> wrote:
>
>> Thanks guys, this is what I have come up with so far. Next week i'll
>> put together a web page or something with slightly better write-ups,
>> but these are my initial ideas for responses to each point. Better
>> answers would be welcome.
>>
>> "We have NAT, therefore we don't need IPv6."
>> "We still have plenty of IPv4 addresses"
>> "IPv4 works so we don't need IPv6."
>>
>> They said similar things about IPX, DECNET, Appletalk........ but they
>> eventually realised it was easier to move to IP than to keep making
>> excuses for why their network can't connect to anything.
>>
>> "we want NAT for IPv6 for security reasons"
>>
>> NAT does not provide any security, typically a NAT will also include a
>> stateful firewall which provides the security. You can deploy a
>> stateful firewall for your IPv6 network if you like, however it isn't
>> required as much as you probably think it is - see below.
>>
>> "IPv6 is just another way for hackers to get in."
>>
>> There is no difference between IPv4 and IPv6 when it comes to
>> firewalls and reachability. It is worth noting that hosts which
>> support IPv6 are typically a lot more secure than older IPv4-only
>> hosts. As an example every version of Windows that ships with IPv6
>> support also ships with the firewall turned on by default.
>>
>> "End users don't care about IPv6"
>>
>> Are you saying this in response to someone asking for IPv6? because
>> that would be contradictory. I am an end user and I care about IPv6!
>>
>> "But it isn't a priority and we have other stuff to do"
>>
>> Reconfiguring every router on your network is not something you want
>> to rush when you realise you needed IPv6 yesterday, early adopters
>> have the advantage that they can gain experience with running IPv6 and
>> test their infrastructure without worrying about critical traffic
>> being IPv6-only.
>>
>> "None of the software vendors support IPv6."
>>
>> If your software vendors were following best practices and writing
>> decent code then this would not be a problem, I suggest pushing your
>> vendors to fix their code. If you only have 1 of two systems that are
>> IPv4-only then you can always "special case" them. See NAT64 for
>> information about one way of reaching IPv4 hosts from an IPv6 network.
>> If you dual stack then it doesn't matter and you can just use IPv4 for
>> those few services than require it until you get a fix from the
>> vendor.
>>
>> "None of our staff understand IPv6."
>>
>> Do your staff understand IPv4? because it's not that different...
>>
>> "IPv6 addresses are too long to remember"
>>
>> You shouldn't need to remember IP addresses, that's what DNS is for.
>> However I will say that in my experience and many other peoples having
>> the extra bits to structure your network in a logical fasion can make
>> addresses more obvious and easier to remember. You have a single
>> prefix to remember, then can address hosts within that subnet however
>> you like. In IPv4 you rarely have the luxury of being able to number
>> your DNS server 192.0.2.53 and your web server 192.0.2.80 to make them
>> easier to remember, whereas in IPv6 you can easily assign hosts easy
>> to remember addresses.
>>
>> "Having to dual stack means I still have to manage a 4 and 6 network."
>>
>> Good point, however if you want to ease your network management and
>> run an IPv6-only network with IPv4-only services still reachable over
>> the top of it then there are several ways to do it, the most obvious
>> being NAT64.
>>
>> "Our DNS provider won't let us as add AAAA records"
>>
>> Seriously? who is your DNS provider? You need to ask them why they
>> don't support standard record types. If they refuse to add standard
>> records to your zone, get a new provider there are plenty out there.
>>
>> "We'll deploy IPv6 right after we finish deploying DNSSEC"
>>
>> The 2 are not mutually exclusive - at a large organisation where this
>> sort of project would be major work, you probably have different teams
>> dealing with IP and DNS so there's no reason one would stop the other.
>>
>> "But Android doesn't support stateful DHCPv6."
>>
>> I will admit that the specifications were written a little loosely so
>> you have 2 ways of configuring hosts, however if you configure both RA
>> and DHCP then you will cover 100% of IPv6-capible hosts.
>>
>> "Our legal intercept setup does not work with IPv6"
>>
>> If your lawful intercept equipment can't see traffic just because they
>> used an "unknown" protocol then it has a major flaw!
>>
>> - Mike Jones
>>
>


From xxnog at ledeuns.net  Sat Jul  2 17:46:35 2016
From: xxnog at ledeuns.net (Denis Fondras)
Date: Sat, 2 Jul 2016 19:46:35 +0200
Subject: IPv6 deployment excuses
In-Reply-To: <5777F0A4.4040102@l-w.ca>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
 <5777F0A4.4040102@l-w.ca>
Message-ID: <20160702174635.GV16361@enforcer.ledeuns.net>

On Sat, Jul 02, 2016 at 10:49:40AM -0600, William Astle wrote:
> it usually boils down to "we don't want to put any effort or resources into
> updating anything".
> 

And they must be right as their clients won't go away... :p

From nanog at ics-il.net  Sat Jul  2 18:42:54 2016
From: nanog at ics-il.net (Mike Hammett)
Date: Sat, 2 Jul 2016 13:42:54 -0500 (CDT)
Subject: IPv6 deployment excuses
In-Reply-To: <04f1d90c3975174680957a9f22f940d6@mail.dessus.com>
References: <04f1d90c3975174680957a9f22f940d6@mail.dessus.com>
Message-ID: <1214617199.8674.1467484972312.JavaMail.mhammett@ThunderFuck>

Security that is too strict will be disabled and be far less effective than proper security measures. Security zealots are often blind to that. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


----- Original Message -----

From: "Keith Medcalf" <kmedcalf at dessus.com> 
To: "nanog list" <nanog at nanog.org> 
Sent: Saturday, July 2, 2016 11:41:48 AM 
Subject: RE: IPv6 deployment excuses 


Yes, the default is "on". An exception is added for EVERY SINGLE PIECE of Microsoft Crapware, whether it is needed or not (and in every single case, it is not). And if you turn those exceptions "off", then they are turned back on by Microsoft and their NSA partners for you, without your permission, whenever automatic updates run (and also at other times that I have not determined the trigger). You must continuously check that the firewall (although ON) remains configured as you configured it, or if Microsoft (and their NSA partners) have changed the configuration without your permission. 

Of course, most people do not bother configuring the firewall and do not wonder why every piece of Crapware has in incoming exception, and do not bother to turn those off (including some on this list apparently). So they will never notice these nefarious doings which have been a hotbed of discussion on the Internet for many years. 

And this is on the latest distribution of Windows 10 including the upcoming anniversary edition and has been that way since at least the first version of Windows 8. 

Whether or not Windows 7 also behaves the same way I do not know because I never ran it. 

> -----Original Message----- 
> From: Spencer Ryan [mailto:sryan at arbor.net] 
> Sent: Saturday, 2 July, 2016 10:08 
> To: Keith Medcalf 
> Cc: North American Network Operators' Group 
> Subject: RE: IPv6 deployment excuses 
> 
> Windows 8 and 10 with the most recent service packs default the firewall 
> to on with very few inbound exemptions. 
> 
> 
> On Jul 2, 2016 11:38 AM, "Keith Medcalf" <kmedcalf at dessus.com> wrote: 
> 
> 
> 
> > There is no difference between IPv4 and IPv6 when it comes to 
> > firewalls and reachability. It is worth noting that hosts which 
> > support IPv6 are typically a lot more secure than older IPv4-only 
> > hosts. As an example every version of Windows that ships with IPv6 
> > support also ships with the firewall turned on by default. 
> 
> Just because the firewall is turned on does not mean that it is 
> configured properly. 
> 
> Every version of Windows that ships with IPv6 support also ships 
> with the Firewall configured in such a fashion that you may as well have 
> it turned off. 
> 
> This is especially true in Windows 8 and later where the firewall is 
> reconfigured without your permission by Microsoft every time you install 
> any update whatsoever back to the "totally insecure" default state -- and 
> there is absolutely no way to fix this other than to check, every single 
> minute, that the firewall is still configured as you configured it, and 
> not as Microsoft (and their NSA partners) choose to configure it. 
> 
> All versions of Windows 8 and later whether using IPv4 or IPv6 are 
> completely unsuitable for use on a network attached to the Internet by any 
> means (whether using NAT or not) that does not include an external (to 
> Windows) -- ie, in network -- statefull firewall over which Windows, 
> Microsoft, (and their NSA partners) have no automatic means of control. 
> If you allow UPnP control of the external statefull firewall from Windows 
> version 8 or later, you may as well not bother having any firewall at all 
> because it is not under your control. 
> 
> 
> 
> 
> 






From jared at puck.nether.net  Sat Jul  2 18:47:56 2016
From: jared at puck.nether.net (Jared Mauch)
Date: Sat, 2 Jul 2016 14:47:56 -0400
Subject: IPv6 deployment excuses
In-Reply-To: <5777F0A4.4040102@l-w.ca>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
 <5777F0A4.4040102@l-w.ca>
Message-ID: <C68C08C1-2B4F-459A-9324-E931EA1B99D8@puck.nether.net>

Living in an area where we have a dense pocket without broadband available is a key problem. The two incumbents fail to service the area despite one having fiber 1200' away at the entry to our street. 

One area incumbent can do native v6, the other does 6rd but they don't serve the area so it's even moot. I'm in the process of building my own fiber now due to this problem. The service will likely look like native v6 and 100.64 for v4 w/ nat. This penalty for v4 will become more apparent over time is my guess. 

Jared Mauch

> On Jul 2, 2016, at 12:49 PM, William Astle <lost at l-w.ca> wrote:
> 
> My upstream(s) refuse(s) to support IPv6
> 
> This *is* a deal breaker. The pat response of "get new upstreams" is not helpful


From kmedcalf at dessus.com  Sat Jul  2 19:05:41 2016
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Sat, 02 Jul 2016 13:05:41 -0600
Subject: IPv6 deployment excuses
In-Reply-To: <1214617199.8674.1467484972312.JavaMail.mhammett@ThunderFuck>
Message-ID: <b9778185ee8e2e4cacb2dbd44fae8144@mail.dessus.com>


This is a non sequitur.

In what way is the blocking of incoming unsolicited connections not a "proper security measure"?

What gives you (or anyone else) the right to "disable" security measures which you (or anyone else) consider "too strict"?

How do you arrive at the conclusion that disabling unsolicited incoming connections to software that does not require it (and which you do not want to accept such unsolicited incoming connections) is "far less effective" than "proper security measures" (and what are those alleged "proper security measures)?  

Explain especially in light of built-in crapware which cannot otherwise be removed from the system because it has been "integrated" by scattering its parts (with no purpose other than to make the crapware non-removeable) into critical components so as to prevent removal without breaking the system?

Please explain how expecting firewall setting to remain set as they have been deliberately set makes one a "security zealot"?

If the ACLs on your Cisco router suddenly decided to change all by themselves because Cisco had decided they did not like the way you had set them, I am quite sure that you take an entirely different position!


> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett
> Sent: Saturday, 2 July, 2016 12:43
> Cc: nanog list
> Subject: Re: IPv6 deployment excuses
> 
> Security that is too strict will be disabled and be far less effective
> than proper security measures. Security zealots are often blind to that.
> 
> 
> 
> 
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
> 
> 
> 
> Midwest Internet Exchange
> http://www.midwest-ix.com
> 
> 
> ----- Original Message -----
> 
> From: "Keith Medcalf" <kmedcalf at dessus.com>
> To: "nanog list" <nanog at nanog.org>
> Sent: Saturday, July 2, 2016 11:41:48 AM
> Subject: RE: IPv6 deployment excuses
> 
> 
> Yes, the default is "on". An exception is added for EVERY SINGLE PIECE of
> Microsoft Crapware, whether it is needed or not (and in every single case,
> it is not). And if you turn those exceptions "off", then they are turned
> back on by Microsoft and their NSA partners for you, without your
> permission, whenever automatic updates run (and also at other times that I
> have not determined the trigger). You must continuously check that the
> firewall (although ON) remains configured as you configured it, or if
> Microsoft (and their NSA partners) have changed the configuration without
> your permission.
> 
> Of course, most people do not bother configuring the firewall and do not
> wonder why every piece of Crapware has in incoming exception, and do not
> bother to turn those off (including some on this list apparently). So they
> will never notice these nefarious doings which have been a hotbed of
> discussion on the Internet for many years.
> 
> And this is on the latest distribution of Windows 10 including the
> upcoming anniversary edition and has been that way since at least the
> first version of Windows 8.
> 
> Whether or not Windows 7 also behaves the same way I do not know because I
> never ran it.
> 
> > -----Original Message-----
> > From: Spencer Ryan [mailto:sryan at arbor.net]
> > Sent: Saturday, 2 July, 2016 10:08
> > To: Keith Medcalf
> > Cc: North American Network Operators' Group
> > Subject: RE: IPv6 deployment excuses
> >
> > Windows 8 and 10 with the most recent service packs default the firewall
> > to on with very few inbound exemptions.
> >
> >
> > On Jul 2, 2016 11:38 AM, "Keith Medcalf" <kmedcalf at dessus.com> wrote:
> >
> >
> >
> > > There is no difference between IPv4 and IPv6 when it comes to
> > > firewalls and reachability. It is worth noting that hosts which
> > > support IPv6 are typically a lot more secure than older IPv4-only
> > > hosts. As an example every version of Windows that ships with IPv6
> > > support also ships with the firewall turned on by default.
> >
> > Just because the firewall is turned on does not mean that it is
> > configured properly.
> >
> > Every version of Windows that ships with IPv6 support also ships
> > with the Firewall configured in such a fashion that you may as well have
> > it turned off.
> >
> > This is especially true in Windows 8 and later where the firewall is
> > reconfigured without your permission by Microsoft every time you install
> > any update whatsoever back to the "totally insecure" default state --
> and
> > there is absolutely no way to fix this other than to check, every single
> > minute, that the firewall is still configured as you configured it, and
> > not as Microsoft (and their NSA partners) choose to configure it.
> >
> > All versions of Windows 8 and later whether using IPv4 or IPv6 are
> > completely unsuitable for use on a network attached to the Internet by
> any
> > means (whether using NAT or not) that does not include an external (to
> > Windows) -- ie, in network -- statefull firewall over which Windows,
> > Microsoft, (and their NSA partners) have no automatic means of control.
> > If you allow UPnP control of the external statefull firewall from
> Windows
> > version 8 or later, you may as well not bother having any firewall at
> all
> > because it is not under your control.
> >
> >
> >
> >
> >
> 
> 
> 
> 





From mark.tinka at seacom.mu  Sun Jul  3 09:42:22 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Sun, 3 Jul 2016 11:42:22 +0200
Subject: IPv6 deployment excuses
In-Reply-To: <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
Message-ID: <0def83fa-8188-5d52-2129-e0f1ba96f330@seacom.mu>



On 2/Jul/16 17:35, Ruairi Carroll wrote:

> - ECMP issues (Mostly around flow labels and vendor support for that, also
> feeds back into PMTUD issues)

Do you rely on the ToS field in IPv4 for ECMP?

> - Maintaining 2x IP stacks is inherently expensive Vs 1

How so?

Mark.

From mark.tinka at seacom.mu  Sun Jul  3 09:48:14 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Sun, 3 Jul 2016 11:48:14 +0200
Subject: IPv6 deployment excuses
In-Reply-To: <5777F0A4.4040102@l-w.ca>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
 <5777F0A4.4040102@l-w.ca>
Message-ID: <d088333e-b8d5-6f19-0a25-018223dea0cd@seacom.mu>



On 2/Jul/16 18:49, William Astle wrote:

>  Their specific excuse du jour changes every few months but it usually
> boils down to "we don't want to put any effort or resources into
> updating anything".

If you keep asking your girlfriend out on a date each week, and she
refuses to go out with you, each week, at some point, painful as it
might be, you have to cut your losses and move on.

Continuing to keep her as your girlfriend does not change the fact that
she does not want go out with you anymore, and only further incentivizes
her not to change her ways, as she knows you don't have the will or
strength to walk regardless of the bad treatment.

Mark.

From ruairi.carroll at gmail.com  Sun Jul  3 10:01:11 2016
From: ruairi.carroll at gmail.com (Ruairi Carroll)
Date: Sun, 3 Jul 2016 12:01:11 +0200
Subject: IPv6 deployment excuses
In-Reply-To: <0def83fa-8188-5d52-2129-e0f1ba96f330@seacom.mu>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
 <0def83fa-8188-5d52-2129-e0f1ba96f330@seacom.mu>
Message-ID: <CANdN9jaxP_i22-TtRv1=Brj8pysBpqVyZdDp_PE4gnHW34QN9g@mail.gmail.com>

On 3 July 2016 at 11:42, Mark Tinka <mark.tinka at seacom.mu> wrote:

>
>
> On 2/Jul/16 17:35, Ruairi Carroll wrote:
>
> - ECMP issues (Mostly around flow labels and vendor support for that, also
> feeds back into PMTUD issues)
>
>
> Do you rely on the ToS field in IPv4 for ECMP?
>
>
Nope. I use l4 tuple for flow hashing to make TCP happy. I was referring to
two things:

-
https://www.nanog.org/sites/default/files/wednesday.general.lotfi.mtu.6.pdf
- https://tools.ietf.org/html/rfc7098

Core of the issue is that we _need_ to get an ICMP message back to the
original "real server" who sent it. It's a non-issue in the SP space, but
imagine if your ECMP groups were stateful in both directions...


> - Maintaining 2x IP stacks is inherently expensive Vs 1
>
>
> How so?
>

Think about it in layers, with each little piece adding up to the overall
cost:

Implementation:
- Numerous bugs in control plane features with v6 handling.
- Numerous platform quirks which need time to be understood.


Operational:
- Need dev time to ensure applications are v6 ready.
- Need SysAdmin time to evaluate kernel/userspace support and functionality
- Need to maintain two sets of templates for config purposes
- Need to maintain two sets of addressing policies


Design:
- Some switches are not suitable for v6 because of their multicast handling
- Need extra time to validate designs will be v6 ready
- Need engineers who understand v6 sufficiently to think in terms of
Anycast and ECMP (Those who do it in v4 space are already thin on the
ground)
- Need engineers who understand v6 sufficiently to describe a good
ACL/Firewall filtering.
- Need engineers who understand v6 sufficiently to understand the
peering/transit landscape (Which IS different from v4).


I'll be the first one to say it sucks, but this is the reality of being a
stub. My past implementation failures were all torpedo'd by lack of dev
time/priority.

/Ruairi


>
>
> Mark.
>

From mark.tinka at seacom.mu  Sun Jul  3 10:15:22 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Sun, 3 Jul 2016 12:15:22 +0200
Subject: IPv6 deployment excuses
In-Reply-To: <CANdN9jaxP_i22-TtRv1=Brj8pysBpqVyZdDp_PE4gnHW34QN9g@mail.gmail.com>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
 <0def83fa-8188-5d52-2129-e0f1ba96f330@seacom.mu>
 <CANdN9jaxP_i22-TtRv1=Brj8pysBpqVyZdDp_PE4gnHW34QN9g@mail.gmail.com>
Message-ID: <1eebdf61-b0e2-c0f7-9e81-9f00a7a218ae@seacom.mu>



On 3/Jul/16 12:01, Ruairi Carroll wrote:

>
> Core of the issue is that we _need_ to get an ICMP message back to the
> original "real server" who sent it. It's a non-issue in the SP space,
> but imagine if your ECMP groups were stateful in both directions...

Okay.


>  
>
> Think about it in layers, with each little piece adding up to the
> overall cost:

I understand your points - to your comment, my question is around
whether it is cheaper (for you) to just run IPv6 in lieu of IPv6 and IPv4.

Mark.

From ruairi.carroll at gmail.com  Sun Jul  3 10:27:08 2016
From: ruairi.carroll at gmail.com (Ruairi Carroll)
Date: Sun, 3 Jul 2016 12:27:08 +0200
Subject: IPv6 deployment excuses
In-Reply-To: <1eebdf61-b0e2-c0f7-9e81-9f00a7a218ae@seacom.mu>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
 <0def83fa-8188-5d52-2129-e0f1ba96f330@seacom.mu>
 <CANdN9jaxP_i22-TtRv1=Brj8pysBpqVyZdDp_PE4gnHW34QN9g@mail.gmail.com>
 <1eebdf61-b0e2-c0f7-9e81-9f00a7a218ae@seacom.mu>
Message-ID: <CANdN9jZk2fyGwSXdo5fgqnG-SfBrzDqvn_jaTf=wo=qQjf056Q@mail.gmail.com>

On 3 July 2016 at 12:15, Mark Tinka <mark.tinka at seacom.mu> wrote:

>
>
> On 3/Jul/16 12:01, Ruairi Carroll wrote:
>
>
> Core of the issue is that we _need_ to get an ICMP message back to the
> original "real server" who sent it. It's a non-issue in the SP space, but
> imagine if your ECMP groups were stateful in both directions...
>
>
> Okay.
>
>
>
>
> Think about it in layers, with each little piece adding up to the overall
> cost:
>
>
> I understand your points - to your comment, my question is around whether
> it is cheaper (for you) to just run IPv6 in lieu of IPv6 and IPv4.
>
>
Probably equal cost (ha ha) to pick one or the other. However since this
conversation was started about people using excuses to not deploy....and
being a stub/content provider, your main goal is reachability, to which v4
is still king.

So you have your hand forced to pick v4 for now.

/Ruairi


> Mark.
>

From tore at fud.no  Sun Jul  3 13:34:15 2016
From: tore at fud.no (Tore Anderson)
Date: Sun, 3 Jul 2016 15:34:15 +0200
Subject: IPv6 deployment excuses
In-Reply-To: <1eebdf61-b0e2-c0f7-9e81-9f00a7a218ae@seacom.mu>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
 <0def83fa-8188-5d52-2129-e0f1ba96f330@seacom.mu>
 <CANdN9jaxP_i22-TtRv1=Brj8pysBpqVyZdDp_PE4gnHW34QN9g@mail.gmail.com>
 <1eebdf61-b0e2-c0f7-9e81-9f00a7a218ae@seacom.mu>
Message-ID: <20160703153415.051e7eed@envy.e1.y.home>

* Mark Tinka

> I understand your points - to your comment, my question is around
> whether it is cheaper (for you) to just run IPv6 in lieu of IPv6 and
> IPv4.

We've found that it is. IPv6-only greatly reduces complexity compared to
dual stack. This means higher reliability, lower OpEx, shorter recovery
time when something does go wrong anyway, fewer SLA violations, happier
customers, and so on - the list goes on and on. Single stack is
essentially the KISS option.

It also means that we'll essentially never have to perform IPv4
renumbering exercises in order to accomodate for growth. Those tend to
be very costly due to the man-hours required for planning and
implementation.

Besides, it means we don't need IPv4 to number customer infrastructure.
As you probably know, IPv4 numbers have a real cost these days.

My point of view is ASP/MSP/data centre stuff. I know I'm not alone in
going down the IPv6 road here, though. Facebook is another prominent
example.

Other operators in different market segments are also doing IPv6-only.
Kabel Deutschland and T-Mobile US, for example. I'm guessing they have
similar motivations.

Tore

From ops.lists at gmail.com  Sun Jul  3 15:35:29 2016
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Sun, 03 Jul 2016 21:05:29 +0530
Subject: Charter FYI - FW: [SANOG] Reliance Jio (AS55836) origating a /16
 belonging to Charter (AS20115)
Message-ID: <DF780544-ADBC-422A-AC60-0C88FE0485A9@hserus.net>

 

 

From: sanog <sanog-bounces at sanog.org> on behalf of Anurag Bhatia <me at anuragbhatia.com>
Date: Sunday, 3 July 2016 at 8:46 PM
To: SANOG <sanog at sanog.org>
Subject: [SANOG] Reliance Jio (AS55836) origating a /16 belonging to Charter (AS20115)

 

Hello everyone! 

 

 

Is anyone from Jio network engineering team on this list? 

 

 

I see AS55836 is originating  47.35.0.0/16 while the pool belongs to Charter. There's even /18 slices of the pool being announced by Charter. 

 

 

 

>From Oregon route-views: 

 

 

route-views>sh ip bgp 47.35.0.0/16 long | exclude 20115

BGP table version is 18764390, local router ID is 128.223.51.103

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

              x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

 

     Network          Next Hop            Metric LocPrf Weight Path

 *   47.35.0.0/16     195.208.112.161                        0 3277 3267 174 64049 55836 i

 *                    217.192.89.50                          0 3303 6762 64049 55836 i

 *                    212.66.96.126                          0 20912 1267 64049 55836 i

 *                    162.243.188.2                          0 393406 6453 6762 64049 55836 i

 *                    192.241.164.4                          0 62567 2914 174 64049 55836 i

 *                    129.250.0.11          1007             0 2914 174 64049 55836 i

 *                    104.192.216.1                          0 46450 174 64049 55836 i

 *                    202.93.8.242                           0 24441 3491 3491 174 64049 55836 i

 *                    66.59.190.221                          0 6539 577 6762 64049 55836 i

 *                    144.228.241.130         80             0 1239 174 64049 55836 i

 *                    207.172.6.20             0             0 6079 3356 174 64049 55836 i

 

 

 

 

Does not seem good! 

 

-- 

 

 

Anurag Bhatia

anuragbhatia.com

_______________________________________________ sanog mailing list sanog at sanog.org https://lists.sanog.org/mailman/listinfo/sanog


From ops.lists at gmail.com  Sun Jul  3 15:48:55 2016
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Sun, 03 Jul 2016 21:18:55 +0530
Subject: Charter FYI - FW: [SANOG] Reliance Jio (AS55836) origating a /16
 belonging to Charter (AS20115)
In-Reply-To: <DF780544-ADBC-422A-AC60-0C88FE0485A9@hserus.net>
References: <DF780544-ADBC-422A-AC60-0C88FE0485A9@hserus.net>
Message-ID: <4DF5F0E2-0AF6-4033-AA8E-8612F34B4FE3@gmail.com>

On 03/07/16, 9:05 PM, "NANOG on behalf of Suresh Ramasubramanian" <nanog-bounces at nanog.org on behalf of ops.lists at gmail.com> wrote:

> Is anyone from Jio network engineering team on this list? 
> I see AS55836 is originating  47.35.0.0/16 while the pool belongs to 
> Charter. There's even /18 slices of the pool being announced by Charter.

Acked / fixed in record time actually




From jra at baylink.com  Sun Jul  3 18:24:20 2016
From: jra at baylink.com (Jay R. Ashworth)
Date: Sun, 3 Jul 2016 18:24:20 +0000 (UTC)
Subject: Charter FYI - FW: [SANOG] Reliance Jio (AS55836) origating a
 /16 belonging to Charter (AS20115)
In-Reply-To: <4DF5F0E2-0AF6-4033-AA8E-8612F34B4FE3@gmail.com>
References: <DF780544-ADBC-422A-AC60-0C88FE0485A9@hserus.net>
 <4DF5F0E2-0AF6-4033-AA8E-8612F34B4FE3@gmail.com>
Message-ID: <1087914762.17695.1467570260759.JavaMail.zimbra@baylink.com>

----- Original Message -----
> From: "Suresh Ramasubramanian" <ops.lists at gmail.com>

> On 03/07/16, 9:05 PM, "NANOG on behalf of Suresh Ramasubramanian"
> <nanog-bounces at nanog.org on behalf of ops.lists at gmail.com> wrote:
> 
>> Is anyone from Jio network engineering team on this list?
>> I see AS55836 is originating  47.35.0.0/16 while the pool belongs to
>> Charter. There's even /18 slices of the pool being announced by Charter.
> 
> Acked / fixed in record time actually

So carriers *still* aren't filtering incoming BGP announcements from 
subordinate carriers for sanity, huh?

Cheers,
-- jr 'yes, yes, I know, but even still' a
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274

From cb.list6 at gmail.com  Sun Jul  3 19:32:27 2016
From: cb.list6 at gmail.com (Ca By)
Date: Sun, 3 Jul 2016 12:32:27 -0700
Subject: Charter FYI - FW: [SANOG] Reliance Jio (AS55836) origating a /16
 belonging to Charter (AS20115)
In-Reply-To: <1087914762.17695.1467570260759.JavaMail.zimbra@baylink.com>
References: <DF780544-ADBC-422A-AC60-0C88FE0485A9@hserus.net>
 <4DF5F0E2-0AF6-4033-AA8E-8612F34B4FE3@gmail.com>
 <1087914762.17695.1467570260759.JavaMail.zimbra@baylink.com>
Message-ID: <CAD6AjGTq3wi4uNnDq2gCT2CUSLR0+g=w0W=euO1W=2peCEsJZQ@mail.gmail.com>

On Sunday, July 3, 2016, Jay R. Ashworth <jra at baylink.com
<javascript:_e(%7B%7D,'cvml','jra at baylink.com');>> wrote:

> ----- Original Message -----
> > From: "Suresh Ramasubramanian" <ops.lists at gmail.com>
>
> > On 03/07/16, 9:05 PM, "NANOG on behalf of Suresh Ramasubramanian"
> > <nanog-bounces at nanog.org on behalf of ops.lists at gmail.com> wrote:
> >
> >> Is anyone from Jio network engineering team on this list?
> >> I see AS55836 is originating  47.35.0.0/16 while the pool belongs to
> >> Charter. There's even /18 slices of the pool being announced by Charter.
> >
> > Acked / fixed in record time actually
>
> So carriers *still* aren't filtering incoming BGP announcements from
> subordinate carriers for sanity, huh?
>
>
Correct.

I am trying to chase down a hijack right now. AS12389 is passing a bad
route to Cogent, HE, GTT, and Hibernian. Email to noc at he got a quick fix,
still waiting on others.

Would have been nice for any of those folks to have used the correctly
published IRR, RPKI, or whois info instead of accepting and passing bad
routes.


Cheers,
> -- jr 'yes, yes, I know, but even still' a
> --
> Jay R. Ashworth                  Baylink
> jra at baylink.com
> Designer                     The Things I Think                       RFC
> 2100
> Ashworth & Associates       http://www.bcp38.info          2000 Land
> Rover DII
> St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647
> 1274
>

From mark.tinka at seacom.mu  Mon Jul  4 08:01:24 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Mon, 4 Jul 2016 10:01:24 +0200
Subject: IPv6 deployment excuses
In-Reply-To: <20160703153415.051e7eed@envy.e1.y.home>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
 <0def83fa-8188-5d52-2129-e0f1ba96f330@seacom.mu>
 <CANdN9jaxP_i22-TtRv1=Brj8pysBpqVyZdDp_PE4gnHW34QN9g@mail.gmail.com>
 <1eebdf61-b0e2-c0f7-9e81-9f00a7a218ae@seacom.mu>
 <20160703153415.051e7eed@envy.e1.y.home>
Message-ID: <5d01aa51-4402-3a73-a006-30e23351f24b@seacom.mu>



On 3/Jul/16 15:34, Tore Anderson wrote:

> We've found that it is. IPv6-only greatly reduces complexity compared to
> dual stack. This means higher reliability, lower OpEx, shorter recovery
> time when something does go wrong anyway, fewer SLA violations, happier
> customers, and so on - the list goes on and on. Single stack is
> essentially the KISS option.

What I was trying to get to is that, yes, running a single-stack is
cheaper (depending on what "cheaper" means to you) than running dual-stack.

That said, running IPv4-only means you put yourself at a disadvantage as
IPv6 is now where the world is going.

Similarly, running IPv6-only means you still need to support access to
the IPv4-only Internet anyway, if you want to have paying customers or
happy users.

So the bottom line is that for better or worse, any progressive network
in 2016 is going to have to run dual-stack in some form or other for the
foreseeable future. So the argument on whether it is cheaper or more
costly to run single- or dual-stack does not change that fact if you are
interested in remaining a going concern.

Mark.

From tore at fud.no  Mon Jul  4 09:04:42 2016
From: tore at fud.no (Tore Anderson)
Date: Mon, 4 Jul 2016 11:04:42 +0200
Subject: IPv6 deployment excuses
In-Reply-To: <5d01aa51-4402-3a73-a006-30e23351f24b@seacom.mu>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
 <0def83fa-8188-5d52-2129-e0f1ba96f330@seacom.mu>
 <CANdN9jaxP_i22-TtRv1=Brj8pysBpqVyZdDp_PE4gnHW34QN9g@mail.gmail.com>
 <1eebdf61-b0e2-c0f7-9e81-9f00a7a218ae@seacom.mu>
 <20160703153415.051e7eed@envy.e1.y.home>
 <5d01aa51-4402-3a73-a006-30e23351f24b@seacom.mu>
Message-ID: <20160704110442.055a4284@echo.ms.redpill-linpro.com>

* Mark Tinka <mark.tinka at seacom.mu>

> What I was trying to get to is that, yes, running a single-stack is
> cheaper (depending on what "cheaper" means to you) than running
> dual-stack.

Wholeheartedly agreed.

> That said, running IPv4-only means you put yourself at a disadvantage
> as IPv6 is now where the world is going.

Also wholeheartedly agreed.

> Similarly, running IPv6-only means you still need to support access to
> the IPv4-only Internet anyway, if you want to have paying customers or
> happy users.
> 
> So the bottom line is that for better or worse, any progressive
> network in 2016 is going to have to run dual-stack in some form or
> other for the foreseeable future. So the argument on whether it is
> cheaper or more costly to run single- or dual-stack does not change
> that fact if you are interested in remaining a going concern.

My point is that as a content provider, I only need dual-stacked
fa?ade. That can easily be achieved using, e.g., protocol translation
at the outer border of my network.

The inside of my network, where 99.99% of all the complexity, devices,
applications and so on reside, can be single stack IPv6-only today.

Thus I get all the benefits of running a single stack network, minus a
some fraction of a percent needed to operate the translation system.
(I could in theory get rid of that too by outsourcing it somewhere.)

Tore

From mark.tinka at seacom.mu  Mon Jul  4 09:21:37 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Mon, 4 Jul 2016 11:21:37 +0200
Subject: IPv6 deployment excuses
In-Reply-To: <20160704110442.055a4284@echo.ms.redpill-linpro.com>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
 <0def83fa-8188-5d52-2129-e0f1ba96f330@seacom.mu>
 <CANdN9jaxP_i22-TtRv1=Brj8pysBpqVyZdDp_PE4gnHW34QN9g@mail.gmail.com>
 <1eebdf61-b0e2-c0f7-9e81-9f00a7a218ae@seacom.mu>
 <20160703153415.051e7eed@envy.e1.y.home>
 <5d01aa51-4402-3a73-a006-30e23351f24b@seacom.mu>
 <20160704110442.055a4284@echo.ms.redpill-linpro.com>
Message-ID: <654adc1e-aafd-4a9e-a68e-500979593d03@seacom.mu>



On 4/Jul/16 11:04, Tore Anderson wrote:

> My point is that as a content provider, I only need dual-stacked
> fa?ade. That can easily be achieved using, e.g., protocol translation
> at the outer border of my network.
>
> The inside of my network, where 99.99% of all the complexity, devices,
> applications and so on reside, can be single stack IPv6-only today.
>
> Thus I get all the benefits of running a single stack network, minus a
> some fraction of a percent needed to operate the translation system.
> (I could in theory get rid of that too by outsourcing it somewhere.)

The NAT64 translation still requires a dual-stack deployment. Of course,
it is a smaller % of your overall single-stack IPv6 network, but still
there nonetheless.

The advantage with NAT64, as you say, is that it easier to rip it out
when the IPv4 Internet dies a happy death, than it would be if one were
keeping IPv4 primary and sticking IPv6 duct tape on top.

Mark.

From mohta at necom830.hpcl.titech.ac.jp  Mon Jul  4 09:41:00 2016
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Mon, 4 Jul 2016 18:41:00 +0900
Subject: IPv6 deployment excuses
In-Reply-To: <C352698F-3520-4405-86B7-6150815352A7@puck.nether.net>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <3e1b229.kqhkiG.155a8439000@slabnet.com>
 <2634D4B9-A92B-408F-87C8-AA9C0A8CCEFB@puck.nether.net>
 <13e05110-89bf-a000-f7e3-1b7c39ad8588@necom830.hpcl.titech.ac.jp>
 <C352698F-3520-4405-86B7-6150815352A7@puck.nether.net>
Message-ID: <2ae7bdc3-eeaa-9a3b-b8bd-013086b8bb95@necom830.hpcl.titech.ac.jp>

Jared Mauch wrote:

> Actually they are not that great. Look at the DDoS mess that UPnP has
> created and problems for IoT (I call it Internet of trash, as most
> devices are poorly implemented without safety in mind) folks on all
> sides.

Are you saying, without NAT or something like that to restrict
reachable ports, the Internet, regardless of whether it is with
IPv4 or IPv6, is not very secure?

With end to end NAT, you can still configure your UPnP capable NAT
boxes to restrict port forwarding.

> The fact that I go to a hotel and that AT&T mobility have limited
> internet reach is a technology problem that we all must work to fix.

Want to run a server at the hotel?

IP mobility helps you, if you have a home agent at your home and
you can use IP over UDP/TCP over IP as mobility tunnel.

						Masataka Ohta
>
>
> Jared Mauch
>
>> On Jul 1, 2016, at 11:49 PM, Masataka Ohta
>> <mohta at necom830.hpcl.titech.ac.jp> wrote:
>>
>> And, to applications running over TCP/UDP, UPnP capable legacy NATs
>> are transparent, if host TCP/UDP are modified to perform reverse
>> NAT, information to do so is provided by UPnP.
>
>
>


From fhr at fhrnet.eu  Mon Jul  4 10:21:53 2016
From: fhr at fhrnet.eu (Filip Hruska)
Date: Mon, 4 Jul 2016 12:21:53 +0200
Subject: IPv6 deployment excuses
In-Reply-To: <2ae7bdc3-eeaa-9a3b-b8bd-013086b8bb95@necom830.hpcl.titech.ac.jp>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <3e1b229.kqhkiG.155a8439000@slabnet.com>
 <2634D4B9-A92B-408F-87C8-AA9C0A8CCEFB@puck.nether.net>
 <13e05110-89bf-a000-f7e3-1b7c39ad8588@necom830.hpcl.titech.ac.jp>
 <C352698F-3520-4405-86B7-6150815352A7@puck.nether.net>
 <2ae7bdc3-eeaa-9a3b-b8bd-013086b8bb95@necom830.hpcl.titech.ac.jp>
Message-ID: <577A38C1.5000407@fhrnet.eu>

Without firewalls, internet is not very secure, regardless of protocol used.

On 07/04/2016 11:41 AM, Masataka Ohta wrote:
> Jared Mauch wrote:
> 
>> Actually they are not that great. Look at the DDoS mess that UPnP has
>> created and problems for IoT (I call it Internet of trash, as most
>> devices are poorly implemented without safety in mind) folks on all
>> sides.
> 
> Are you saying, without NAT or something like that to restrict
> reachable ports, the Internet, regardless of whether it is with
> IPv4 or IPv6, is not very secure?
> 
> With end to end NAT, you can still configure your UPnP capable NAT
> boxes to restrict port forwarding.
> 
>> The fact that I go to a hotel and that AT&T mobility have limited
>> internet reach is a technology problem that we all must work to fix.
> 
> Want to run a server at the hotel?
> 
> IP mobility helps you, if you have a home agent at your home and
> you can use IP over UDP/TCP over IP as mobility tunnel.
> 
>                          Masataka Ohta
>>
>>
>> Jared Mauch
>>
>>> On Jul 1, 2016, at 11:49 PM, Masataka Ohta
>>> <mohta at necom830.hpcl.titech.ac.jp> wrote:
>>>
>>> And, to applications running over TCP/UDP, UPnP capable legacy NATs
>>> are transparent, if host TCP/UDP are modified to perform reverse
>>> NAT, information to do so is provided by UPnP.
>>
>>
>>
> 

From contact at winterei.se  Mon Jul  4 11:25:35 2016
From: contact at winterei.se (Paul S.)
Date: Mon, 4 Jul 2016 20:25:35 +0900
Subject: Looking for a Seabone / Telecom Italia Sparkle rep
Message-ID: <82b83c73-4f27-9687-fe36-aeb9b981e96f@winterei.se>

Hi guys,

Does anyone have any good Seabone / Telecom Italia Sparkle 
representatives whose contacts they don't mind passing along?

Looking for service in Asia, particularly Singapore and Hong Kong markets.

Having absolutely no luck with the standard sales channels, no one has 
gotten back to us. We've been trying for a while.

Thanks in advance!


From mattlists at rivervalleyinternet.net  Mon Jul  4 12:44:10 2016
From: mattlists at rivervalleyinternet.net (Matt Hoppes)
Date: Mon, 4 Jul 2016 08:44:10 -0400
Subject: IPv6 deployment excuses
In-Reply-To: <5d01aa51-4402-3a73-a006-30e23351f24b@seacom.mu>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
 <0def83fa-8188-5d52-2129-e0f1ba96f330@seacom.mu>
 <CANdN9jaxP_i22-TtRv1=Brj8pysBpqVyZdDp_PE4gnHW34QN9g@mail.gmail.com>
 <1eebdf61-b0e2-c0f7-9e81-9f00a7a218ae@seacom.mu>
 <20160703153415.051e7eed@envy.e1.y.home>
 <5d01aa51-4402-3a73-a006-30e23351f24b@seacom.mu>
Message-ID: <B9CDA0F3-AE6F-435D-9904-C2AE05BCCCCB@rivervalleyinternet.net>

I disagree. Any data center or hosting provider is going to continue to offer IPv4 lest they island themselves from subscribers who have IPv4 only - which no data center is going to do. 

One can not run IPv6 only because there are sites that are only IPv4. 

Thus, as an ISP you can safely continue to run IPv4. Ipv4 won't be going away for at least ten years or more - if ever. 

I'm not saying don't be ready for IPv6. I'm not saying don't understand how it works. But doomsday isn't here. 

> On Jul 4, 2016, at 04:01, Mark Tinka <mark.tinka at seacom.mu> wrote:
> 
> 
> 
>> On 3/Jul/16 15:34, Tore Anderson wrote:
>> 
>> We've found that it is. IPv6-only greatly reduces complexity compared to
>> dual stack. This means higher reliability, lower OpEx, shorter recovery
>> time when something does go wrong anyway, fewer SLA violations, happier
>> customers, and so on - the list goes on and on. Single stack is
>> essentially the KISS option.
> 
> What I was trying to get to is that, yes, running a single-stack is
> cheaper (depending on what "cheaper" means to you) than running dual-stack.
> 
> That said, running IPv4-only means you put yourself at a disadvantage as
> IPv6 is now where the world is going.
> 
> Similarly, running IPv6-only means you still need to support access to
> the IPv4-only Internet anyway, if you want to have paying customers or
> happy users.
> 
> So the bottom line is that for better or worse, any progressive network
> in 2016 is going to have to run dual-stack in some form or other for the
> foreseeable future. So the argument on whether it is cheaper or more
> costly to run single- or dual-stack does not change that fact if you are
> interested in remaining a going concern.
> 
> Mark.

From marka at isc.org  Mon Jul  4 13:49:11 2016
From: marka at isc.org (Mark Andrews)
Date: Mon, 04 Jul 2016 23:49:11 +1000
Subject: IPv6 deployment excuses
In-Reply-To: Your message of "Mon, 04 Jul 2016 08:44:10 -0400."
 <B9CDA0F3-AE6F-435D-9904-C2AE05BCCCCB@rivervalleyinternet.net>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
 <0def83fa-8188-5d52-2129-e0f1ba96f330@seacom.mu>
 <CANdN9jaxP_i22-TtRv1=Brj8pysBpqVyZdDp_PE4gnHW34QN9g@mail.gmail.com>
 <1eebdf61-b0e2-c0f7-9e81-9f00a7a218ae@seacom.mu>
 <20160703153415.051e7eed@envy.e1.y.home>
 <5d01aa51-4402-3a73-a006-30e23351f24b@seacom.mu>
 <B9CDA0F3-AE6F-435D-9904-C2AE05BCCCCB@rivervalleyinternet.net>
Message-ID: <20160704134911.4B07A4D44E1E@rock.dv.isc.org>


In message <B9CDA0F3-AE6F-435D-9904-C2AE05BCCCCB at rivervalleyinternet.net>, Matt
 Hoppes writes:
> I disagree. Any data center or hosting provider is going to continue to
> offer IPv4 lest they island themselves from subscribers who have IPv4
> only - which no data center is going to do.
>
> One can not run IPv6 only because there are sites that are only IPv4.
>
> Thus, as an ISP you can safely continue to run IPv4. Ipv4 won't be going
> away for at least ten years or more - if ever.
>
> I'm not saying don't be ready for IPv6. I'm not saying don't understand
> how it works. But doomsday isn't here.

There are ISP's that are essentially IPv6 only today as they do not
have enough IPv4 addresses to give all their customers a public
IPv4 address.

Once you need to run a GGN you may as well run DS-Lite, MAP* or
(shudder) DNS64/NAT64 as NAT444.  There is no need to talk IPv4 to
your customers today.  You still need a small number of IPv4 address
to talk to legacy IPv4 servers on the internet.  Just because there
owners don't know they are legacy servers doesn't mean they aren't.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

From mattlists at rivervalleyinternet.net  Mon Jul  4 14:02:21 2016
From: mattlists at rivervalleyinternet.net (Matt Hoppes)
Date: Mon, 4 Jul 2016 10:02:21 -0400
Subject: IPv6 deployment excuses
In-Reply-To: <20160704134911.4B07A4D44E1E@rock.dv.isc.org>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
 <0def83fa-8188-5d52-2129-e0f1ba96f330@seacom.mu>
 <CANdN9jaxP_i22-TtRv1=Brj8pysBpqVyZdDp_PE4gnHW34QN9g@mail.gmail.com>
 <1eebdf61-b0e2-c0f7-9e81-9f00a7a218ae@seacom.mu>
 <20160703153415.051e7eed@envy.e1.y.home>
 <5d01aa51-4402-3a73-a006-30e23351f24b@seacom.mu>
 <B9CDA0F3-AE6F-435D-9904-C2AE05BCCCCB@rivervalleyinternet.net>
 <20160704134911.4B07A4D44E1E@rock.dv.isc.org>
Message-ID: <F8C84099-590B-40BA-AD85-811AE6CABF70@rivervalleyinternet.net>

My point is there are more than enough IPv4 addresses. The issue is not resources. It is hoarding and inappropriate use. 

The large ISPs have enough IPs to service every household in the US several times over. And yet, we have an IP shortage. 

There are universities holding onto /8s and not using them. 

IPv6 just feels like a knee jerk reaction. 

From tmorizot at gmail.com  Mon Jul  4 14:10:47 2016
From: tmorizot at gmail.com (Scott Morizot)
Date: Mon, 4 Jul 2016 09:10:47 -0500
Subject: IPv6 deployment excuses
In-Reply-To: <B9CDA0F3-AE6F-435D-9904-C2AE05BCCCCB@rivervalleyinternet.net>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
 <0def83fa-8188-5d52-2129-e0f1ba96f330@seacom.mu>
 <CANdN9jaxP_i22-TtRv1=Brj8pysBpqVyZdDp_PE4gnHW34QN9g@mail.gmail.com>
 <1eebdf61-b0e2-c0f7-9e81-9f00a7a218ae@seacom.mu>
 <20160703153415.051e7eed@envy.e1.y.home>
 <5d01aa51-4402-3a73-a006-30e23351f24b@seacom.mu>
 <B9CDA0F3-AE6F-435D-9904-C2AE05BCCCCB@rivervalleyinternet.net>
Message-ID: <CAFy81r=+n5S2RPvbFCE5BXgW9boJ021CcXFPkWtHC5x63bVXeQ@mail.gmail.com>

On Mon, Jul 4, 2016 at 7:44 AM, Matt Hoppes <
mattlists at rivervalleyinternet.net> wrote:

> I disagree. Any data center or hosting provider is going to continue to
> offer IPv4 lest they island themselves from subscribers who have IPv4 only
> - which no data center is going to do.
>
> Thus, as an ISP you can safely continue to run IPv4. Ipv4 won't be going
> away for at least ten years or more - if ever.
>

That's an interesting "bet the business" decision for an ISP to make. It's
not one a large ISP can make simply because they want to continue growing
their subscriber base and that's a losing proposition as far as profits go.
That's why all the big ISPs are either implementing IPv6 or actively
working to deploy it. So it seems you're saying that a small to medium
sized ISP can delay 10 or more years because all the content their
customers want will be available over IPv4.

And that's pretty much betting the entire business on what is basically
nothing more than a crystal ball. I don't know about you, but I think back
to the mid to late 80s and most ideas I saw about where technology would be
by the mid to late 90s were pretty inaccurate. Jump to the mid 2000s and
past projections were pretty off-base again. Shortly after that, mobile
computing really hit and the world today looks very little like it did
then. Do you really think someone should bet their entire business on your
ability to make Internet forecasts 10 years into the future?

Now, that's not to say I expect IPv4 to necessarily be mostly gone (from
the Internet, not private networks) in 10 years, though it wouldn't
particularly shock me either if things did work out that way. But I do
expect a tipping point will be reached well before then that reduces the
utility of IPv4. Technology changes on the Internet have not traditionally
been steady, gradual processes. Rather, they've had some sort of fairly
long lead time, a rapid spike of uptake, and then a flip from a 'new'
technology to something expected. There's then often something of a long
tail, but it can be pretty unpleasant to be forced to exist in that tail.
The attitude quickly switches to one of, "Oh, you're still using 'x'? You
should use 'y' instead. It's working fine." And issues with 'x' get lower
priority attention. And that 'flip', when it happens, tends to happy
relatively quickly.

Often, it can be difficult to predict if a new technology will overtake and
supplant an older one. The IPv6 transition, however, is being forced by
IPv4 exhaustion. That's putting a lot of technological and financial
pressure on most of the parties involved. As someone who works at an
enterprise that sees a lot of traffic, primarily from the US, we were
seeing a steady increase in IPv6 traffic from end users from practically
nothing in 2012 to around 15% in 2015. This year we've seen it spike to
25%-30%. So in the US, we may very well reach that tipping point within the
next couple of years. If we do, the utility of IPv4 will probably start to
degrade pretty rapidly as more attention and focus is placed on IPv6
connectivity. If that happens and you're still an IPv4 only edge/access
network that hasn't even begun planning an IPv6 deployment? That's apt to
be an uncomfortable experience.

But again, I'm not a prognosticator. I wouldn't have correctly guessed the
timing for any of the transitions I've seen in the past, though I did
sometimes come close to guessing the outcome. (That's one of the reasons I
started a small scale production deployment of Linux at my place of
employment back in the mid-90s, something we now have running on platforms
all the way up to our mainframes.) It looks to me like, in the US at least,
we're on the 'rapid uptake' slope of adoption. If that's the case, then
that tipping point is probably coming a lot sooner than 10 years out. You
could be right and everything will be fine for IPv4-only customers and
networks in 10 years. But that is most definitely a high stakes bet to
make. I certainly wouldn't be willing to make such a gamble.

I also want to note that enterprise or data center networks moving to IPv6
only does not necessarily involve NAT64 or any sort of translation. For any
large internet service, inbound connections are typically terminated at the
edge. A new connection is then established from the point of termination to
the data center resources. So Facebook, for instance, only needs to
dual-stack its edge. And if you use a 3rd part CDN for the edge, you don't
even have to do that. That's what other posters were pointing out.
Depending on its security profile, a large enterprise network might also
'proxy' outbound Internet traffic (primarily web, mail, DNS) already for
its internal users. If that's the case (as it is where I work) very little
outbound translation is required as well and only the outbound perimeter
services need to be dual-stacked long-term. So if an enterprise or data
center network operator isn't already thinking in terms of where they can
go IPv6 only rather than dual-stacked, now is probably when you want to
start thinking that way. There is a definite cost to trying to operate what
is essentially two networks over the long haul. The more places you can
move from dual-stacked to single-stacked IPv6 in your network, the better
off you'll be.

And even ISP access networks are moving more toward offering IPv4 as a
service on top of a native IPv6 network. T-Mobile is already doing that.
>From what I've seen, others are exploring ways to do it. Especially given
all the constraints on IPv4, that approach just makes sense.

So again, the safe bet today looks like IPv6 to me. Wagering that the rest
of the Internet will be fully supporting IPv4 at the same level of utility
as IPv6 in a decade looks like a high-risk gamble.

Scott

From baldur.norddahl at gmail.com  Mon Jul  4 14:15:59 2016
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Mon, 4 Jul 2016 16:15:59 +0200
Subject: IPv6 deployment excuses
In-Reply-To: <F8C84099-590B-40BA-AD85-811AE6CABF70@rivervalleyinternet.net>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
 <0def83fa-8188-5d52-2129-e0f1ba96f330@seacom.mu>
 <CANdN9jaxP_i22-TtRv1=Brj8pysBpqVyZdDp_PE4gnHW34QN9g@mail.gmail.com>
 <1eebdf61-b0e2-c0f7-9e81-9f00a7a218ae@seacom.mu>
 <20160703153415.051e7eed@envy.e1.y.home>
 <5d01aa51-4402-3a73-a006-30e23351f24b@seacom.mu>
 <B9CDA0F3-AE6F-435D-9904-C2AE05BCCCCB@rivervalleyinternet.net>
 <20160704134911.4B07A4D44E1E@rock.dv.isc.org>
 <F8C84099-590B-40BA-AD85-811AE6CABF70@rivervalleyinternet.net>
Message-ID: <CAPkb-7AAzv2H08i+D_spd1tGy1Gn-AE55ytMBkhnDGGQ0gDQuA@mail.gmail.com>

There are 7 billion people world wide that want Internet and only
approximately 3 billion usable IPv4 addresses. It wont do.
Den 4. jul. 2016 16.03 skrev "Matt Hoppes" <
mattlists at rivervalleyinternet.net>:

> My point is there are more than enough IPv4 addresses. The issue is not
> resources. It is hoarding and inappropriate use.
>
> The large ISPs have enough IPs to service every household in the US
> several times over. And yet, we have an IP shortage.
>
> There are universities holding onto /8s and not using them.
>
> IPv6 just feels like a knee jerk reaction.

From mattlists at rivervalleyinternet.net  Mon Jul  4 14:33:38 2016
From: mattlists at rivervalleyinternet.net (Matt Hoppes)
Date: Mon, 4 Jul 2016 10:33:38 -0400
Subject: IPv6 deployment excuses
In-Reply-To: <CAFy81r=+n5S2RPvbFCE5BXgW9boJ021CcXFPkWtHC5x63bVXeQ@mail.gmail.com>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
 <0def83fa-8188-5d52-2129-e0f1ba96f330@seacom.mu>
 <CANdN9jaxP_i22-TtRv1=Brj8pysBpqVyZdDp_PE4gnHW34QN9g@mail.gmail.com>
 <1eebdf61-b0e2-c0f7-9e81-9f00a7a218ae@seacom.mu>
 <20160703153415.051e7eed@envy.e1.y.home>
 <5d01aa51-4402-3a73-a006-30e23351f24b@seacom.mu>
 <B9CDA0F3-AE6F-435D-9904-C2AE05BCCCCB@rivervalleyinternet.net>
 <CAFy81r=+n5S2RPvbFCE5BXgW9boJ021CcXFPkWtHC5x63bVXeQ@mail.gmail.com>
Message-ID: <DAC3BF99-FB01-4E1A-8303-E30DF296E856@rivervalleyinternet.net>

Except that IPv4 is not exhausted. That's the doomsday message that was preached over and over. 

The simple fact that there is/are IP broker exchanges now simply proves there are surplus IPs to go around. 

We have an efficiency utilization issue - not an exhaustion issue. 

From saku at ytti.fi  Mon Jul  4 14:59:28 2016
From: saku at ytti.fi (Saku Ytti)
Date: Mon, 4 Jul 2016 17:59:28 +0300
Subject: IPv6 deployment excuses
In-Reply-To: <DAC3BF99-FB01-4E1A-8303-E30DF296E856@rivervalleyinternet.net>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
 <0def83fa-8188-5d52-2129-e0f1ba96f330@seacom.mu>
 <CANdN9jaxP_i22-TtRv1=Brj8pysBpqVyZdDp_PE4gnHW34QN9g@mail.gmail.com>
 <1eebdf61-b0e2-c0f7-9e81-9f00a7a218ae@seacom.mu>
 <20160703153415.051e7eed@envy.e1.y.home>
 <5d01aa51-4402-3a73-a006-30e23351f24b@seacom.mu>
 <B9CDA0F3-AE6F-435D-9904-C2AE05BCCCCB@rivervalleyinternet.net>
 <CAFy81r=+n5S2RPvbFCE5BXgW9boJ021CcXFPkWtHC5x63bVXeQ@mail.gmail.com>
 <DAC3BF99-FB01-4E1A-8303-E30DF296E856@rivervalleyinternet.net>
Message-ID: <CAAeewD8kuOFsvyPA5spo-xoxqkvfVc8Tqzqh8hPS51kb3Rwmcw@mail.gmail.com>

On 4 July 2016 at 17:33, Matt Hoppes <mattlists at rivervalleyinternet.net> wrote:

> The simple fact that there is/are IP broker exchanges now simply proves there are surplus IPs to go around.

I'm unsure of the message. Is the statement that if commodity is
tradable, there is surplus to go around? Is converse true? If I can't
buy it, there is no surplus?

I don't think either statement is correct. Lot of things exist in
exactly 1 copy, and there is market for them, so market does not imply
'surplus to go around'. And lack of market does not imply 'surplus to
go around', merely lack of demand.

Yes, US has more IP addresses allocated to them than there are people,
several times over. This is not true for earth. We need more
addresses, IPv4 addresses are scarce. Just because I can throw money
at the problem, does not mean problem does not exist. I am privileged,
but people shouldn't need to have my privileges to have access to
Internet.

-- 
  ++ytti

From swmike at swm.pp.se  Mon Jul  4 15:58:25 2016
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Mon, 4 Jul 2016 17:58:25 +0200 (CEST)
Subject: IPv6 deployment excuses
In-Reply-To: <F8C84099-590B-40BA-AD85-811AE6CABF70@rivervalleyinternet.net>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
 <0def83fa-8188-5d52-2129-e0f1ba96f330@seacom.mu>
 <CANdN9jaxP_i22-TtRv1=Brj8pysBpqVyZdDp_PE4gnHW34QN9g@mail.gmail.com>
 <1eebdf61-b0e2-c0f7-9e81-9f00a7a218ae@seacom.mu>
 <20160703153415.051e7eed@envy.e1.y.home>
 <5d01aa51-4402-3a73-a006-30e23351f24b@seacom.mu>
 <B9CDA0F3-AE6F-435D-9904-C2AE05BCCCCB@rivervalleyinternet.net>
 <20160704134911.4B07A4D44E1E@rock.dv.isc.org>
 <F8C84099-590B-40BA-AD85-811AE6CABF70@rivervalleyinternet.net>
Message-ID: <alpine.DEB.2.02.1607041753350.2309@uplift.swm.pp.se>

On Mon, 4 Jul 2016, Matt Hoppes wrote:

> My point is there are more than enough IPv4 addresses. The issue is not 
> resources. It is hoarding and inappropriate use.

I tend to make the analogy of land use and/or houses/apartments. Yes, 
there is that old lady down the street who lives in 300 square meters 
(~3000 sq feet for those who are !metric), and then there is the student 
who shares a 30sq meter studio with another student.

Now what? Yes, this is not fair and it's inefficient utilization of 
resources, but how are you going to rectify this? Forcibly take away the 
apartment from the old lady and tell her to go live somewhere else just 
because it isn't fair that she has 10 times the apartment size as the 
student?

IPv6 is the answer, because it doesn't have shortcoming when it comes to 
available "land". Everybody can get plenty. No need to try to take away 
resources from someone holding them (legitimately) as per the rules of 
yestercentury.

From mattlists at rivervalleyinternet.net  Mon Jul  4 16:28:28 2016
From: mattlists at rivervalleyinternet.net (Matt Hoppes)
Date: Mon, 4 Jul 2016 12:28:28 -0400
Subject: IPv6 deployment excuses
In-Reply-To: <alpine.DEB.2.02.1607041753350.2309@uplift.swm.pp.se>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
 <0def83fa-8188-5d52-2129-e0f1ba96f330@seacom.mu>
 <CANdN9jaxP_i22-TtRv1=Brj8pysBpqVyZdDp_PE4gnHW34QN9g@mail.gmail.com>
 <1eebdf61-b0e2-c0f7-9e81-9f00a7a218ae@seacom.mu>
 <20160703153415.051e7eed@envy.e1.y.home>
 <5d01aa51-4402-3a73-a006-30e23351f24b@seacom.mu>
 <B9CDA0F3-AE6F-435D-9904-C2AE05BCCCCB@rivervalleyinternet.net>
 <20160704134911.4B07A4D44E1E@rock.dv.isc.org>
 <F8C84099-590B-40BA-AD85-811AE6CABF70@rivervalleyinternet.net>
 <alpine.DEB.2.02.1607041753350.2309@uplift.swm.pp.se>
Message-ID: <0FBDAE88-1762-4792-B8A3-F1CC499A8CD7@rivervalleyinternet.net>

Except the lady will eventually downsize. The college student will want more and lease the space. 

Also, the 49,000 Sq ft office space that has been leased for 10 years and never occupied will be taken back and released to someone who will actually develop it. 

> On Jul 4, 2016, at 11:58, Mikael Abrahamsson <swmike at swm.pp.se> wrote:
> 
>> On Mon, 4 Jul 2016, Matt Hoppes wrote:
>> 
>> My point is there are more than enough IPv4 addresses. The issue is not resources. It is hoarding and inappropriate use.
> 
> I tend to make the analogy of land use and/or houses/apartments. Yes, there is that old lady down the street who lives in 300 square meters (~3000 sq feet for those who are !metric), and then there is the student who shares a 30sq meter studio with another student.
> 
> Now what? Yes, this is not fair and it's inefficient utilization of resources, but how are you going to rectify this? Forcibly take away the apartment from the old lady and tell her to go live somewhere else just because it isn't fair that she has 10 times the apartment size as the student?
> 
> IPv6 is the answer, because it doesn't have shortcoming when it comes to available "land". Everybody can get plenty. No need to try to take away resources from someone holding them (legitimately) as per the rules of yestercentury.

From morrowc.lists at gmail.com  Mon Jul  4 16:42:33 2016
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 4 Jul 2016 12:42:33 -0400
Subject: IPv6 deployment excuses
In-Reply-To: <0FBDAE88-1762-4792-B8A3-F1CC499A8CD7@rivervalleyinternet.net>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
 <0def83fa-8188-5d52-2129-e0f1ba96f330@seacom.mu>
 <CANdN9jaxP_i22-TtRv1=Brj8pysBpqVyZdDp_PE4gnHW34QN9g@mail.gmail.com>
 <1eebdf61-b0e2-c0f7-9e81-9f00a7a218ae@seacom.mu>
 <20160703153415.051e7eed@envy.e1.y.home>
 <5d01aa51-4402-3a73-a006-30e23351f24b@seacom.mu>
 <B9CDA0F3-AE6F-435D-9904-C2AE05BCCCCB@rivervalleyinternet.net>
 <20160704134911.4B07A4D44E1E@rock.dv.isc.org>
 <F8C84099-590B-40BA-AD85-811AE6CABF70@rivervalleyinternet.net>
 <alpine.DEB.2.02.1607041753350.2309@uplift.swm.pp.se>
 <0FBDAE88-1762-4792-B8A3-F1CC499A8CD7@rivervalleyinternet.net>
Message-ID: <CAL9jLaaqXk9zot5x98JDCGjBDitGtUnwL89ECsxXHkbmpbPrzg@mail.gmail.com>

On Mon, Jul 4, 2016 at 12:28 PM, Matt Hoppes <
mattlists at rivervalleyinternet.net> wrote:

> Except the lady will eventually downsize. The college student will want
> more and lease the space.
>
> Also, the 49,000 Sq ft office space that has been leased for 10 years and
> never occupied will be taken back and released to someone who will actually
> develop it.
>

and as has been covered numerous times here and other places the lifetime
of a /8 in the global pool is ~1month.

so.. you bought essentially nothing. The math that matters is: 7b people -
3b ips == 4b lost connections.

From hugo at slabnet.com  Mon Jul  4 16:49:53 2016
From: hugo at slabnet.com (Hugo Slabbert)
Date: Mon, 4 Jul 2016 09:49:53 -0700
Subject: IPv6 deployment excuses
In-Reply-To: <CAL9jLaaqXk9zot5x98JDCGjBDitGtUnwL89ECsxXHkbmpbPrzg@mail.gmail.com>
References: <CANdN9jaxP_i22-TtRv1=Brj8pysBpqVyZdDp_PE4gnHW34QN9g@mail.gmail.com>
 <1eebdf61-b0e2-c0f7-9e81-9f00a7a218ae@seacom.mu>
 <20160703153415.051e7eed@envy.e1.y.home>
 <5d01aa51-4402-3a73-a006-30e23351f24b@seacom.mu>
 <B9CDA0F3-AE6F-435D-9904-C2AE05BCCCCB@rivervalleyinternet.net>
 <20160704134911.4B07A4D44E1E@rock.dv.isc.org>
 <F8C84099-590B-40BA-AD85-811AE6CABF70@rivervalleyinternet.net>
 <alpine.DEB.2.02.1607041753350.2309@uplift.swm.pp.se>
 <0FBDAE88-1762-4792-B8A3-F1CC499A8CD7@rivervalleyinternet.net>
 <CAL9jLaaqXk9zot5x98JDCGjBDitGtUnwL89ECsxXHkbmpbPrzg@mail.gmail.com>
Message-ID: <20160704164953.GC1586@bamboo.slabnet.com>


On Mon 2016-Jul-04 12:42:33 -0400, Christopher Morrow <morrowc.lists at gmail.com> wrote:

>On Mon, Jul 4, 2016 at 12:28 PM, Matt Hoppes <
>mattlists at rivervalleyinternet.net> wrote:
>
>> Except the lady will eventually downsize. The college student will want
>> more and lease the space.
>>
>> Also, the 49,000 Sq ft office space that has been leased for 10 years and
>> never occupied will be taken back and released to someone who will actually
>> develop it.
>>
>
>and as has been covered numerous times here and other places the lifetime
>of a /8 in the global pool is ~1month.
>
>so.. you bought essentially nothing. The math that matters is: 7b people -
>3b ips == 4b lost connections.

...and even that is generous as it assumes 1 device per person and strictly 
peer-to-peer traffic with no servers or even any addresses on routers and 
their interfaces.

Reference to NAT as a saviour in 3...2...1...

-- 
Hugo Slabbert       | email, xmpp/jabber: hugo at slabnet.com
pgp key: B178313E   | also on Signal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160704/5bfd8389/attachment.pgp>

From tmorizot at gmail.com  Mon Jul  4 16:51:52 2016
From: tmorizot at gmail.com (Scott Morizot)
Date: Mon, 4 Jul 2016 11:51:52 -0500
Subject: IPv6 deployment excuses
In-Reply-To: <0FBDAE88-1762-4792-B8A3-F1CC499A8CD7@rivervalleyinternet.net>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
 <0def83fa-8188-5d52-2129-e0f1ba96f330@seacom.mu>
 <CANdN9jaxP_i22-TtRv1=Brj8pysBpqVyZdDp_PE4gnHW34QN9g@mail.gmail.com>
 <1eebdf61-b0e2-c0f7-9e81-9f00a7a218ae@seacom.mu>
 <20160703153415.051e7eed@envy.e1.y.home>
 <5d01aa51-4402-3a73-a006-30e23351f24b@seacom.mu>
 <B9CDA0F3-AE6F-435D-9904-C2AE05BCCCCB@rivervalleyinternet.net>
 <20160704134911.4B07A4D44E1E@rock.dv.isc.org>
 <F8C84099-590B-40BA-AD85-811AE6CABF70@rivervalleyinternet.net>
 <alpine.DEB.2.02.1607041753350.2309@uplift.swm.pp.se>
 <0FBDAE88-1762-4792-B8A3-F1CC499A8CD7@rivervalleyinternet.net>
Message-ID: <CAFy81rm0fJOh2L3YiMAhvgaky1YfoYYnZVg6UYjiDW-R03t80w@mail.gmail.com>

On Mon, Jul 4, 2016 at 11:28 AM, Matt Hoppes <
mattlists at rivervalleyinternet.net> wrote:

> Except the lady will eventually downsize. The college student will want
> more and lease the space.
>
> Also, the 49,000 Sq ft office space that has been leased for 10 years and
> never occupied will be taken back and released to someone who will actually
> develop it.
>

I'm not particularly fond of metaphors using physical resources like land
because physical changes do tend to happen slowly and carry substantial
inertia. As a result such metaphors break down pretty quickly. Internet
numbers are an abstraction with no physical component. As such, their
utility depends on how all the different players on the Internet behave.
Given that, it becomes a classic game theory problem.

It makes little practical difference if there are "enough" IPv4 numbers
theoretically available to serve the demand if only better allocated or
not. I agree with those who believe there aren't given the demands on the
infrastructure and the rate of growth, but that's largely irrelevant. Even
if there theoretically were 'enough' legacy numbers to fit some definition
of 'enough', do you actually believe the many and varied players on the
Internet will converge on that optimal utilization?

I certainly don't.

Nor is that the behavior we're seeing. We see players who have 'more than
enough' by some theoretical optimum utilization scheme conserving the
resources they have for transition. We see large players, who have the most
influence on the direction software and hardware makers move, somewhere in
transition to IPv6. Some are very advanced in their deployment, others are
earlier in it, but pretty much all of them are moving in that direction.

Given that reality and the way the Internet works, at some point in the not
too distant future we're more likely to see the Internet tip toward IPv6
than not. Nothing's certain, but that seems to be where the game is headed.
Once that happens, those caught behind the curve are more likely to suffer
loss than not. The safe bet is to be prepared beforehand, especially since
it's neither particularly difficult nor expensive to deploy IPv6. It's a
comparatively low cost hedge.

Of course, as more people hedge their bets that way, the likelihood that
IPv6 will also turn out to be the 'winning' bet increases, so it starts to
become a self-fulfilling prophecy.

But some people prefer risky bets. It's not clear to me what you actually
gain if you bet the farm on IPv4 and its utility remains more or less the
same for a decade. Any cost-savings over deploying IPv6 are likely going to
be more than consumed in renumbering efforts, purchasing IPv4 number
resources, and deploying/administering CGN equipment. So it actually looks
like a lose/lose scenario to me. But if you see some hypothetical advantage
you wish to pursue, go for it.

But if that hypothetical advantage depends on getting everyone on the
Internet to play along with your scheme for optimal IPv4 number
utilization? Well, good luck with that one.

Scott

From jacques.latour at cira.ca  Mon Jul  4 16:55:39 2016
From: jacques.latour at cira.ca (Jacques Latour)
Date: Mon, 4 Jul 2016 16:55:39 +0000
Subject: IPv6 deployment excuses - IPv6 only resources
Message-ID: <C059877D829F76429F49E0B48705D888DE005CBB@EXCH-02.CORP.CIRA.CA>


Is there a list of IPv6 only ISP or services?  I'd be curious to trend that somehow, by geography, service type, etc... if any.

>-----Original Message-----
>From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mark Andrews
>Sent: July-04-16 9:49 AM
>To: Matt Hoppes
>Cc: Tore Anderson; nanog at nanog.org
>Subject: Re: IPv6 deployment excuses
>
>
>In message <B9CDA0F3-AE6F-435D-9904-
>C2AE05BCCCCB at rivervalleyinternet.net>, Matt  Hoppes writes:
>> I disagree. Any data center or hosting provider is going to continue
>> to offer IPv4 lest they island themselves from subscribers who have
>> IPv4 only - which no data center is going to do.
>>
>> One can not run IPv6 only because there are sites that are only IPv4.
>>
>> Thus, as an ISP you can safely continue to run IPv4. Ipv4 won't be
>> going away for at least ten years or more - if ever.
>>
>> I'm not saying don't be ready for IPv6. I'm not saying don't
>> understand how it works. But doomsday isn't here.
>
>There are ISP's that are essentially IPv6 only today as they do not have enough
>IPv4 addresses to give all their customers a public
>IPv4 address.
>
>Once you need to run a GGN you may as well run DS-Lite, MAP* or
>(shudder) DNS64/NAT64 as NAT444.  There is no need to talk IPv4 to your
>customers today.  You still need a small number of IPv4 address to talk to
>legacy IPv4 servers on the internet.  Just because there owners don't know they
>are legacy servers doesn't mean they aren't.
>
>Mark
>--
>Mark Andrews, ISC
>1 Seymour St., Dundas Valley, NSW 2117, Australia
>PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

From mohta at necom830.hpcl.titech.ac.jp  Mon Jul  4 17:21:04 2016
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Tue, 5 Jul 2016 02:21:04 +0900
Subject: IPv6 deployment excuses
In-Reply-To: <577A38C1.5000407@fhrnet.eu>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <3e1b229.kqhkiG.155a8439000@slabnet.com>
 <2634D4B9-A92B-408F-87C8-AA9C0A8CCEFB@puck.nether.net>
 <13e05110-89bf-a000-f7e3-1b7c39ad8588@necom830.hpcl.titech.ac.jp>
 <C352698F-3520-4405-86B7-6150815352A7@puck.nether.net>
 <2ae7bdc3-eeaa-9a3b-b8bd-013086b8bb95@necom830.hpcl.titech.ac.jp>
 <577A38C1.5000407@fhrnet.eu>
Message-ID: <12804ae6-ed04-7154-ab91-6e658bdebc4e@necom830.hpcl.titech.ac.jp>

Filip Hruska wrote:

> Without firewalls, internet is not very secure, regardless of protocol used.

Irrelevant.

The point of the Internet with end to end transparency is that
if end users want to have the end to end transparency, they
can have it.

If they don't, they don't have to.

							Masataka Ohta

> On 07/04/2016 11:41 AM, Masataka Ohta wrote:
>> Jared Mauch wrote:
>>
>>> Actually they are not that great. Look at the DDoS mess that UPnP has
>>> created and problems for IoT (I call it Internet of trash, as most
>>> devices are poorly implemented without safety in mind) folks on all
>>> sides.
>>
>> Are you saying, without NAT or something like that to restrict
>> reachable ports, the Internet, regardless of whether it is with
>> IPv4 or IPv6, is not very secure?
>>
>> With end to end NAT, you can still configure your UPnP capable NAT
>> boxes to restrict port forwarding.
>>
>>> The fact that I go to a hotel and that AT&T mobility have limited
>>> internet reach is a technology problem that we all must work to fix.
>>
>> Want to run a server at the hotel?
>>
>> IP mobility helps you, if you have a home agent at your home and
>> you can use IP over UDP/TCP over IP as mobility tunnel.
>>
>>                          Masataka Ohta
>>>
>>>
>>> Jared Mauch
>>>
>>>> On Jul 1, 2016, at 11:49 PM, Masataka Ohta
>>>> <mohta at necom830.hpcl.titech.ac.jp> wrote:
>>>>
>>>> And, to applications running over TCP/UDP, UPnP capable legacy NATs
>>>> are transparent, if host TCP/UDP are modified to perform reverse
>>>> NAT, information to do so is provided by UPnP.
>>>
>>>
>>>
>>
>
>


From tmorizot at gmail.com  Mon Jul  4 17:25:25 2016
From: tmorizot at gmail.com (Scott Morizot)
Date: Mon, 4 Jul 2016 12:25:25 -0500
Subject: IPv6 deployment excuses - IPv6 only resources
In-Reply-To: <C059877D829F76429F49E0B48705D888DE005CBB@EXCH-02.CORP.CIRA.CA>
References: <C059877D829F76429F49E0B48705D888DE005CBB@EXCH-02.CORP.CIRA.CA>
Message-ID: <CAFy81rmi2_YLfHXx3gnuNKDBv3P0cyNzMO-xiqLSOi_906RovQ@mail.gmail.com>

On Mon, Jul 4, 2016 at 11:55 AM, Jacques Latour <jacques.latour at cira.ca>
wrote:

>
> Is there a list of IPv6 only ISP or services?  I'd be curious to trend
> that somehow, by geography, service type, etc... if any.
>

Since "IPv6 only" right now is primarily about those portions of the
network that are under a single organization's control, the rest of us will
only know about them, for the most part, from reports from those
organizations. As such, I doubt there's a list, per se, though somebody may
be collecting one.

Off the top of my head, Facebook has reported moving to IPv6 only below
their edge. T-Mobile's cellular data is IPv6 only for newer handset and
will become fully IPv6-only when the older handsets age off. IPv4 Internet
access is provided through some combination of NAT64/DNS64/464xlat. Comcast
isn't (to the best of my knowledge) hasn't yet made any moves in that
direction, but have presented on moving to IPv6 only offering IPv4 as a
service on top of it. Starting this past June 1 (from what I've heard)
Apple is requiring all apps submitted to their app store to support IPv6
only networks. The US Federal CIO is expanding IPv6 transition focus to
government enterprise networks from the previous, more Internet-based focus.

Again, those are just a handful of the large-scale efforts I've personally
heard about. But those are all some pretty significant players on the
Internet. And there are likely to be many more who aren't publicizing their
efforts. Of course, I happen to mostly pay attention to activity in the US,
so there's that selection bias in play as well.

Scott

From jra at baylink.com  Mon Jul  4 17:54:21 2016
From: jra at baylink.com (Jay R. Ashworth)
Date: Mon, 4 Jul 2016 17:54:21 +0000 (UTC)
Subject: New ICANN registrant change process
Message-ID: <800550479.18808.1467654861589.JavaMail.zimbra@baylink.com>

I'll go ahead and assume I wasn't the last person to get this memo (courtesy
Lauren Weinstein's PRIVACY Digest):

https://opensrs.com/blog/2016/06/icanns-new-transfer-policy-will-impact-business-customers/

It does seem that this is going to make life difficult for a bunch of pretty
normal business processes.

If you didn't know about it either... ask yourself why not.

Cheers,
-- jra

-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274

From baldur.norddahl at gmail.com  Mon Jul  4 18:29:41 2016
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Mon, 4 Jul 2016 20:29:41 +0200
Subject: IPv6 deployment excuses
In-Reply-To: <2ae7bdc3-eeaa-9a3b-b8bd-013086b8bb95@necom830.hpcl.titech.ac.jp>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <3e1b229.kqhkiG.155a8439000@slabnet.com>
 <2634D4B9-A92B-408F-87C8-AA9C0A8CCEFB@puck.nether.net>
 <13e05110-89bf-a000-f7e3-1b7c39ad8588@necom830.hpcl.titech.ac.jp>
 <C352698F-3520-4405-86B7-6150815352A7@puck.nether.net>
 <2ae7bdc3-eeaa-9a3b-b8bd-013086b8bb95@necom830.hpcl.titech.ac.jp>
Message-ID: <CAPkb-7Cxq0XZ663ysMbHCGfK_QTCfkSBgDf_tV-1c-QB+9Y+Rg@mail.gmail.com>

On 4 July 2016 at 11:41, Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
wrote:

> With end to end NAT, you can still configure your UPnP capable NAT
> boxes to restrict port forwarding.
>

Only if you by NAT mean "home network NAT". No large ISP has or will deploy
a carrier NAT router that will respect UPnP. That does not scale and is a
security nightmare besides.

We could deploy MAP
https://en.wikipedia.org/wiki/Mapping_of_Address_and_Port (which scales)
and the user could then use the belowed "end to end NAT" method on that.
But why would they? MAP requires IPv6 so they already have end to end
transparency using IPv6.

Regards,

Baldur

From mel at beckman.org  Mon Jul  4 18:35:37 2016
From: mel at beckman.org (Mel Beckman)
Date: Mon, 4 Jul 2016 18:35:37 +0000
Subject: New ICANN registrant change process
In-Reply-To: <800550479.18808.1467654861589.JavaMail.zimbra@baylink.com>
References: <800550479.18808.1467654861589.JavaMail.zimbra@baylink.com>
Message-ID: <8D804E82-D9EF-4FF6-A0EA-796F7AB76780@beckman.org>

I've worked behind the scenes for more than one of these outfits. I can tell you that domain registrars are basically printing money. On the other hand, I've also been the victim of domain hijacking. I can tell you that the domain registrars involved were less than useless in reversing the obviously fraudulent transactions. They basically said "Not our problem. Deal with it."

That's on top of the other obviously unethical practices by registrars, such as seizing nonexistent domain names following a prospective buyer's whois search, sluggardly unlocking of domains, etc.

Something had to be done. Now it has been.   

To the registers whining about this change: 

       Not my problem. Deal with it. 

 -mel beckman

> On Jul 4, 2016, at 10:55 AM, Jay R. Ashworth <jra at baylink.com> wrote:
> 
> I'll go ahead and assume I wasn't the last person to get this memo (courtesy
> Lauren Weinstein's PRIVACY Digest):
> 
> https://opensrs.com/blog/2016/06/icanns-new-transfer-policy-will-impact-business-customers/
> 
> It does seem that this is going to make life difficult for a bunch of pretty
> normal business processes.
> 
> If you didn't know about it either... ask yourself why not.
> 
> Cheers,
> -- jra
> 
> -- 
> Jay R. Ashworth                  Baylink                       jra at baylink.com
> Designer                     The Things I Think                       RFC 2100
> Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
> St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274

From rubensk at gmail.com  Mon Jul  4 18:43:35 2016
From: rubensk at gmail.com (Rubens Kuhl)
Date: Mon, 4 Jul 2016 15:43:35 -0300
Subject: New ICANN registrant change process
In-Reply-To: <800550479.18808.1467654861589.JavaMail.zimbra@baylink.com>
References: <800550479.18808.1467654861589.JavaMail.zimbra@baylink.com>
Message-ID: <CAGFn2k2Xa4Y-BMYmCgJaWGpUgpTTc1QuTpVd3LPSF7nm=mYOQw@mail.gmail.com>

On Mon, Jul 4, 2016 at 2:54 PM, Jay R. Ashworth <jra at baylink.com> wrote:

> I'll go ahead and assume I wasn't the last person to get this memo
> (courtesy
> Lauren Weinstein's PRIVACY Digest):
>
>
> https://opensrs.com/blog/2016/06/icanns-new-transfer-policy-will-impact-business-customers/
>
> It does seem that this is going to make life difficult for a bunch of
> pretty
> normal business processes.
>
> If you didn't know about it either... ask yourself why not.
>

Although I'm not a member of the WG that defined such policy, having seen
the many occasions where domain hijacks occurred, I'm totally fine with the
outcome. I only see real impact for "wholesale" registrars, like OpenSRS,
eNom and Endurance, since they have to figure out a way to be compliant
with policy without actually having contact with the registrants, and this
kind of problem will continue to haunt them as they just operate a way for
companies to operate in the gTLD market outside of its framework.


Rubens

From cb.list6 at gmail.com  Mon Jul  4 18:50:06 2016
From: cb.list6 at gmail.com (Ca By)
Date: Mon, 4 Jul 2016 11:50:06 -0700
Subject: IPv6 deployment excuses
In-Reply-To: <CAPkb-7Cxq0XZ663ysMbHCGfK_QTCfkSBgDf_tV-1c-QB+9Y+Rg@mail.gmail.com>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <3e1b229.kqhkiG.155a8439000@slabnet.com>
 <2634D4B9-A92B-408F-87C8-AA9C0A8CCEFB@puck.nether.net>
 <13e05110-89bf-a000-f7e3-1b7c39ad8588@necom830.hpcl.titech.ac.jp>
 <C352698F-3520-4405-86B7-6150815352A7@puck.nether.net>
 <2ae7bdc3-eeaa-9a3b-b8bd-013086b8bb95@necom830.hpcl.titech.ac.jp>
 <CAPkb-7Cxq0XZ663ysMbHCGfK_QTCfkSBgDf_tV-1c-QB+9Y+Rg@mail.gmail.com>
Message-ID: <CAD6AjGSpSN_1PXVTxnG+jTrppbEhLXEZpAcu9dpb12-WM-5x5g@mail.gmail.com>

On Monday, July 4, 2016, Baldur Norddahl <baldur.norddahl at gmail.com
<javascript:_e(%7B%7D,'cvml','baldur.norddahl at gmail.com');>> wrote:

> On 4 July 2016 at 11:41, Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
> wrote:
>
> > With end to end NAT, you can still configure your UPnP capable NAT
> > boxes to restrict port forwarding.
> >
>
> Only if you by NAT mean "home network NAT". No large ISP has or will deploy
> a carrier NAT router that will respect UPnP. That does not scale and is a
> security nightmare besides.
>
> We could deploy MAP
> https://en.wikipedia.org/wiki/Mapping_of_Address_and_Port (which scales)
> and the user could then use the belowed "end to end NAT" method on that.
> But why would they? MAP requires IPv6 so they already have end to end
> transparency using IPv6.
>
> Regards,
>
> Baldur
>

Always so funny how people love talking how great MAP scales, yet it has
never been deployed at scale. 464XLAT and ds-lite have been deployed at
real scale, so has 6RD.

MAP is like beta max. Technically great, but reality is poor.

From jra at baylink.com  Mon Jul  4 19:03:53 2016
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 04 Jul 2016 15:03:53 -0400
Subject: New ICANN registrant change process
In-Reply-To: <8D804E82-D9EF-4FF6-A0EA-796F7AB76780@beckman.org>
References: <800550479.18808.1467654861589.JavaMail.zimbra@baylink.com>
 <8D804E82-D9EF-4FF6-A0EA-796F7AB76780@beckman.org>
Message-ID: <6C958391-E2F3-413A-98ED-C689B819F42E@baylink.com>

Seems to me that the proper thing to be done would have been for Registries to deauthorize registrars on the grounds of continuous streams of complaints.

On July 4, 2016 2:35:37 PM EDT, Mel Beckman <mel at beckman.org> wrote:
>I've worked behind the scenes for more than one of these outfits. I can
>tell you that domain registrars are basically printing money. On the
>other hand, I've also been the victim of domain hijacking. I can tell
>you that the domain registrars involved were less than useless in
>reversing the obviously fraudulent transactions. They basically said
>"Not our problem. Deal with it."
>
>That's on top of the other obviously unethical practices by registrars,
>such as seizing nonexistent domain names following a prospective
>buyer's whois search, sluggardly unlocking of domains, etc.
>
>Something had to be done. Now it has been.   
>
>To the registers whining about this change: 
>
>       Not my problem. Deal with it. 
>
> -mel beckman
>
>> On Jul 4, 2016, at 10:55 AM, Jay R. Ashworth <jra at baylink.com> wrote:
>> 
>> I'll go ahead and assume I wasn't the last person to get this memo
>(courtesy
>> Lauren Weinstein's PRIVACY Digest):
>> 
>>
>https://opensrs.com/blog/2016/06/icanns-new-transfer-policy-will-impact-business-customers/
>> 
>> It does seem that this is going to make life difficult for a bunch of
>pretty
>> normal business processes.
>> 
>> If you didn't know about it either... ask yourself why not.
>> 
>> Cheers,
>> -- jra
>> 
>> -- 
>> Jay R. Ashworth                  Baylink                      
>jra at baylink.com
>> Designer                     The Things I Think                      
>RFC 2100
>> Ashworth & Associates       http://www.bcp38.info          2000 Land
>Rover DII
>> St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727
>647 1274

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From mark.tinka at seacom.mu  Mon Jul  4 20:53:20 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Mon, 4 Jul 2016 22:53:20 +0200
Subject: IPv6 deployment excuses
In-Reply-To: <B9CDA0F3-AE6F-435D-9904-C2AE05BCCCCB@rivervalleyinternet.net>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
 <0def83fa-8188-5d52-2129-e0f1ba96f330@seacom.mu>
 <CANdN9jaxP_i22-TtRv1=Brj8pysBpqVyZdDp_PE4gnHW34QN9g@mail.gmail.com>
 <1eebdf61-b0e2-c0f7-9e81-9f00a7a218ae@seacom.mu>
 <20160703153415.051e7eed@envy.e1.y.home>
 <5d01aa51-4402-3a73-a006-30e23351f24b@seacom.mu>
 <B9CDA0F3-AE6F-435D-9904-C2AE05BCCCCB@rivervalleyinternet.net>
Message-ID: <b656096b-1d33-ebe0-91d9-9a339f666b20@seacom.mu>



On 4/Jul/16 14:44, Matt Hoppes wrote:

> I disagree. Any data center or hosting provider is going to continue to offer IPv4 lest they island themselves from subscribers who have IPv4 only - which no data center is going to do. 

But that's what I said...

Mark.

From mark.tinka at seacom.mu  Mon Jul  4 20:56:07 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Mon, 4 Jul 2016 22:56:07 +0200
Subject: IPv6 deployment excuses
In-Reply-To: <DAC3BF99-FB01-4E1A-8303-E30DF296E856@rivervalleyinternet.net>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
 <0def83fa-8188-5d52-2129-e0f1ba96f330@seacom.mu>
 <CANdN9jaxP_i22-TtRv1=Brj8pysBpqVyZdDp_PE4gnHW34QN9g@mail.gmail.com>
 <1eebdf61-b0e2-c0f7-9e81-9f00a7a218ae@seacom.mu>
 <20160703153415.051e7eed@envy.e1.y.home>
 <5d01aa51-4402-3a73-a006-30e23351f24b@seacom.mu>
 <B9CDA0F3-AE6F-435D-9904-C2AE05BCCCCB@rivervalleyinternet.net>
 <CAFy81r=+n5S2RPvbFCE5BXgW9boJ021CcXFPkWtHC5x63bVXeQ@mail.gmail.com>
 <DAC3BF99-FB01-4E1A-8303-E30DF296E856@rivervalleyinternet.net>
Message-ID: <6d2880ee-ac61-83cf-f2f0-ff50884c2e4f@seacom.mu>



On 4/Jul/16 16:33, Matt Hoppes wrote:

> Except that IPv4 is not exhausted. That's the doomsday message that was preached over and over. 
>
> The simple fact that there is/are IP broker exchanges now simply proves there are surplus IPs to go around. 
>
> We have an efficiency utilization issue - not an exhaustion issue. 

As a global Internet community, which is easier to do? Going around
looking for inefficiencies in holders' allocations, or getting on with
the job of deploying IPv6?

Mark.

From mark.tinka at seacom.mu  Mon Jul  4 20:57:40 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Mon, 4 Jul 2016 22:57:40 +0200
Subject: IPv6 deployment excuses
In-Reply-To: <0FBDAE88-1762-4792-B8A3-F1CC499A8CD7@rivervalleyinternet.net>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <CAAAas8HKyPkHXYdAHGMefh8kd71Ocxv5Nmo3Pb2gzLeHwUcNdQ@mail.gmail.com>
 <CANdN9jZ=5LkmTwEd-yBnhmKmqJCwSOMDy9H0rEnTqC0QY7b0rA@mail.gmail.com>
 <0def83fa-8188-5d52-2129-e0f1ba96f330@seacom.mu>
 <CANdN9jaxP_i22-TtRv1=Brj8pysBpqVyZdDp_PE4gnHW34QN9g@mail.gmail.com>
 <1eebdf61-b0e2-c0f7-9e81-9f00a7a218ae@seacom.mu>
 <20160703153415.051e7eed@envy.e1.y.home>
 <5d01aa51-4402-3a73-a006-30e23351f24b@seacom.mu>
 <B9CDA0F3-AE6F-435D-9904-C2AE05BCCCCB@rivervalleyinternet.net>
 <20160704134911.4B07A4D44E1E@rock.dv.isc.org>
 <F8C84099-590B-40BA-AD85-811AE6CABF70@rivervalleyinternet.net>
 <alpine.DEB.2.02.1607041753350.2309@uplift.swm.pp.se>
 <0FBDAE88-1762-4792-B8A3-F1CC499A8CD7@rivervalleyinternet.net>
Message-ID: <3a38efa8-cf7a-004f-32be-2ee1ab2f23a9@seacom.mu>



On 4/Jul/16 18:28, Matt Hoppes wrote:

> Except the lady will eventually downsize. The college student will want more and lease the space. 
>
> Also, the 49,000 Sq ft office space that has been leased for 10 years and never occupied will be taken back and released to someone who will actually develop it. 

Can we trade worlds :-)?

Mark.

From baldur.norddahl at gmail.com  Mon Jul  4 21:50:19 2016
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Mon, 4 Jul 2016 23:50:19 +0200
Subject: IPv6 deployment excuses
In-Reply-To: <CAD6AjGSpSN_1PXVTxnG+jTrppbEhLXEZpAcu9dpb12-WM-5x5g@mail.gmail.com>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <3e1b229.kqhkiG.155a8439000@slabnet.com>
 <2634D4B9-A92B-408F-87C8-AA9C0A8CCEFB@puck.nether.net>
 <13e05110-89bf-a000-f7e3-1b7c39ad8588@necom830.hpcl.titech.ac.jp>
 <C352698F-3520-4405-86B7-6150815352A7@puck.nether.net>
 <2ae7bdc3-eeaa-9a3b-b8bd-013086b8bb95@necom830.hpcl.titech.ac.jp>
 <CAPkb-7Cxq0XZ663ysMbHCGfK_QTCfkSBgDf_tV-1c-QB+9Y+Rg@mail.gmail.com>
 <CAD6AjGSpSN_1PXVTxnG+jTrppbEhLXEZpAcu9dpb12-WM-5x5g@mail.gmail.com>
Message-ID: <CAPkb-7DeW31M1dpOAU2hGmXkPBrQ_Nfj-LYWE-fp02663WmF9A@mail.gmail.com>

On 2016-07-04 20:50, Ca By wrote:


Always so funny how people love talking how great MAP scales, yet it has
never been deployed at scale. 464XLAT and ds-lite have been deployed at
real scale, so has 6RD.

MAP is like beta max. Technically great, but reality is poor.


The two MAP RFCs are dated July 2015 just one year old. The world does not
move that fast and especially not "large deployments".

6RD is dated August 2010
DS-LITE is dated August 2011
464XLAT is dated April 2013

Someone from Comcast just said at the recent RIPE conference in Copenhagen
that they are considering MAP. Now Comcast were also one the larger 6RD
deployments. Why the switch? Because those technologies do not solve the
same problem.

6RD is a short term technology fix to get some IPv6 out to the customers
quickly in a network that is otherwise pure IPv4.

MAP is a long term solution to deliver some IPv4 in a world where IPv4 is
deprecated and IPv6 is the main protocol. It is meant to deployed in a
network that is otherwise pure IPv6, the exact opposite to 6RD.

The two other technologies mentioned do the same as MAP more or less, but
both requires carrier NAT, which is expensive for the ISP and has a lack of
control as seen from the end user point of view (no port forwarding etc).

I for one is going to continue to demand that my vendors implement MAP, so
I do not have to pay for a carrier NAT solution that always is going to be
in need of upgrade, will be under DDoS attack every tuesday and just
plainly is not a necessary element in the network. MAP on the other hand is
stateless and it is very simple to tack on an encapsulating header. Any
router that can do GRE should also be able to do MAP.

Regards,

Baldur

From cb.list6 at gmail.com  Mon Jul  4 22:42:24 2016
From: cb.list6 at gmail.com (Ca By)
Date: Mon, 4 Jul 2016 15:42:24 -0700
Subject: IPv6 deployment excuses
In-Reply-To: <CAPkb-7DeW31M1dpOAU2hGmXkPBrQ_Nfj-LYWE-fp02663WmF9A@mail.gmail.com>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <3e1b229.kqhkiG.155a8439000@slabnet.com>
 <2634D4B9-A92B-408F-87C8-AA9C0A8CCEFB@puck.nether.net>
 <13e05110-89bf-a000-f7e3-1b7c39ad8588@necom830.hpcl.titech.ac.jp>
 <C352698F-3520-4405-86B7-6150815352A7@puck.nether.net>
 <2ae7bdc3-eeaa-9a3b-b8bd-013086b8bb95@necom830.hpcl.titech.ac.jp>
 <CAPkb-7Cxq0XZ663ysMbHCGfK_QTCfkSBgDf_tV-1c-QB+9Y+Rg@mail.gmail.com>
 <CAD6AjGSpSN_1PXVTxnG+jTrppbEhLXEZpAcu9dpb12-WM-5x5g@mail.gmail.com>
 <CAPkb-7DeW31M1dpOAU2hGmXkPBrQ_Nfj-LYWE-fp02663WmF9A@mail.gmail.com>
Message-ID: <CAD6AjGQtexSOEJpMsTHaEOFqrYY-C_Vim2SoQi5Mjkn=WY6pVA@mail.gmail.com>

On Monday, July 4, 2016, Baldur Norddahl <baldur.norddahl at gmail.com> wrote:

> On 2016-07-04 20:50, Ca By wrote:
>
>
> Always so funny how people love talking how great MAP scales, yet it has
> never been deployed at scale. 464XLAT and ds-lite have been deployed at
> real scale, so has 6RD.
>
> MAP is like beta max. Technically great, but reality is poor.
>
>
> The two MAP RFCs are dated July 2015 just one year old. The world does not
> move that fast and especially not "large deployments".
>
> 6RD is dated August 2010
> DS-LITE is dated August 2011
> 464XLAT is dated April 2013
>
>
Funny thing about that is that 464XLAT IETF work started after MAP and
finshed before MAP, despite MAP being the path of the true believers.

Seems MAP running code has been around for 3 years

https://ripe67.ripe.net/presentations/136-ripe_20_dollar_cgn.pdf



> Someone from Comcast just said at the recent RIPE conference in Copenhagen
> that they are considering MAP. Now Comcast were also one the larger 6RD
> deployments. Why the switch? Because those technologies do not solve the
> same problem.
>
>
No, comcast never did a production deployment of 6RD. I was on their beta
6RD many moons ago. Not good.


> 6RD is a short term technology fix to get some IPv6 out to the customers
> quickly in a network that is otherwise pure IPv4.
>
> MAP is a long term solution to deliver some IPv4 in a world where IPv4 is
> deprecated and IPv6 is the main protocol. It is meant to deployed in a
> network that is otherwise pure IPv6, the exact opposite to 6RD.
>
> The two other technologies mentioned do the same as MAP more or less, but
> both requires carrier NAT, which is expensive for the ISP and has a lack of
> control as seen from the end user point of view (no port forwarding etc).
>
> I for one is going to continue to demand that my vendors implement MAP, so
> I do not have to pay for a carrier NAT solution that always is going to be
> in need of upgrade, will be under DDoS attack every tuesday and just
> plainly is not a necessary element in the network. MAP on the other hand is
> stateless and it is very simple to tack on an encapsulating header. Any
> router that can do GRE should also be able to do MAP.
>
> Regards,
>
> Baldur
>

I look forward to your deployment report.

Sometimes folks underestimate the complexity of the dhcpv6 coordination to
assign ports (state) or overstate the IPv4 efficiency in MAP, but i am sure
you have that figured out and accounted.

My point , which i believe is a statement of fact, is that there are MAP
fans, and no deployments at scale to demonstrate real world success.

I am sure that will change, someone will deploy MAP at scale

CB

From jared at puck.Nether.net  Tue Jul  5 01:00:19 2016
From: jared at puck.Nether.net (Jared Mauch)
Date: Mon, 4 Jul 2016 21:00:19 -0400
Subject: IPv6 deployment excuses
In-Reply-To: <2ae7bdc3-eeaa-9a3b-b8bd-013086b8bb95@necom830.hpcl.titech.ac.jp>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <3e1b229.kqhkiG.155a8439000@slabnet.com>
 <2634D4B9-A92B-408F-87C8-AA9C0A8CCEFB@puck.nether.net>
 <13e05110-89bf-a000-f7e3-1b7c39ad8588@necom830.hpcl.titech.ac.jp>
 <C352698F-3520-4405-86B7-6150815352A7@puck.nether.net>
 <2ae7bdc3-eeaa-9a3b-b8bd-013086b8bb95@necom830.hpcl.titech.ac.jp>
Message-ID: <20160705010018.GC8803@puck.nether.net>

On Mon, Jul 04, 2016 at 06:41:00PM +0900, Masataka Ohta wrote:
> Jared Mauch wrote:
> 
> > Actually they are not that great. Look at the DDoS mess that UPnP has
> > created and problems for IoT (I call it Internet of trash, as most
> > devices are poorly implemented without safety in mind) folks on all
> > sides.
> 
> Are you saying, without NAT or something like that to restrict
> reachable ports, the Internet, regardless of whether it is with
> IPv4 or IPv6, is not very secure?

	I'm saying two things:

	1) UPnP is a security nightmare and nobody (at scale)
will let you register ports with their CGN/edge.

	2) We are an industry in transition.  Internet connectivity
will soon be defined by v6 + v4, not v4+ sometimes v6.

	There are challenges still, AWS, UBNT UniFi and things like
the CableWifi/xfinitywifi don't do V6 currently.

	I've heard most of these are coming.  There are still a
lot of self-proclaimed "IT Experts" that say stuff like "why use
DNS", or the well meaning "Cybermoon CEO Amitay Dan" who says
you should use an IP address to manage your home router.  Of course
when people see that, I'm sure they all are thinking IPv4 vs using
a .local domain name.

	Much of this is because we're technical people and most users
are non-technical, they just want their stuff(tm) to work.  We must
make it seamless, and this will mean providing them a method to have
their technology work.

	Take how most people copy files between devices today.  I
may go and SFTP or SCP files around, know the paths, set my prompt
but others?  USB or a service like Dropbox.  It's about the technology
as a tool.

	If you fail to see IPv6 as part of that tool to fix things
and think that everyone will do the right thing, you will face hurdles.

	Our services need to work for the broadest set of users.  Many
people are now used to the non-e2e results of a NAT/CGN environment.
They work around it with other solutions.  Soon?  IPv4AAS will be
abundant to bridge those who lack full internet access.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from jared at puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

From mohta at necom830.hpcl.titech.ac.jp  Tue Jul  5 02:16:31 2016
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Tue, 5 Jul 2016 11:16:31 +0900
Subject: IPv6 deployment excuses
In-Reply-To: <CAPkb-7Cxq0XZ663ysMbHCGfK_QTCfkSBgDf_tV-1c-QB+9Y+Rg@mail.gmail.com>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <3e1b229.kqhkiG.155a8439000@slabnet.com>
 <2634D4B9-A92B-408F-87C8-AA9C0A8CCEFB@puck.nether.net>
 <13e05110-89bf-a000-f7e3-1b7c39ad8588@necom830.hpcl.titech.ac.jp>
 <C352698F-3520-4405-86B7-6150815352A7@puck.nether.net>
 <2ae7bdc3-eeaa-9a3b-b8bd-013086b8bb95@necom830.hpcl.titech.ac.jp>
 <CAPkb-7Cxq0XZ663ysMbHCGfK_QTCfkSBgDf_tV-1c-QB+9Y+Rg@mail.gmail.com>
Message-ID: <9276b70b-09fd-3521-99a0-12d8045ba6eb@necom830.hpcl.titech.ac.jp>

Baldur Norddahl wrote:

>> With end to end NAT, you can still configure your UPnP capable NAT
>> boxes to restrict port forwarding.

> Only if you by NAT mean "home network NAT". No large ISP has or will deploy
> a carrier NAT router that will respect UPnP.

A large ISP should just set up usual NAT. In addition, the ISP
tells its subscriber a global IP address, a private IP address
and a small range of port numbers the subscriber can use and
set up *static* bi-directional port forwarding.

If each subscriber is allocated 64 ports, effective address
space is 1000 times more than that of IPv4, which should be
large enough.

Then, if a subscriber want transparency, he can set up his
home router make use of the bi-directional port forwarding
and his host reverse translation by nested port forwarding.

> That does not scale and is a
> security nightmare besides.

It is merely because you think you must do it dynamically.

But, if you want to run a server at fixed IP address
and port, port forwarding must be static.

						Masataka Ohta

From sryan at arbor.net  Tue Jul  5 02:30:42 2016
From: sryan at arbor.net (Spencer Ryan)
Date: Mon, 4 Jul 2016 22:30:42 -0400
Subject: IPv6 deployment excuses
In-Reply-To: <9276b70b-09fd-3521-99a0-12d8045ba6eb@necom830.hpcl.titech.ac.jp>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <3e1b229.kqhkiG.155a8439000@slabnet.com>
 <2634D4B9-A92B-408F-87C8-AA9C0A8CCEFB@puck.nether.net>
 <13e05110-89bf-a000-f7e3-1b7c39ad8588@necom830.hpcl.titech.ac.jp>
 <C352698F-3520-4405-86B7-6150815352A7@puck.nether.net>
 <2ae7bdc3-eeaa-9a3b-b8bd-013086b8bb95@necom830.hpcl.titech.ac.jp>
 <CAPkb-7Cxq0XZ663ysMbHCGfK_QTCfkSBgDf_tV-1c-QB+9Y+Rg@mail.gmail.com>
 <9276b70b-09fd-3521-99a0-12d8045ba6eb@necom830.hpcl.titech.ac.jp>
Message-ID: <CA+HzidQR-wAjrQa_tVFowQ45_E-jd3Enswd6thnt4P3t9HAmmQ@mail.gmail.com>

Or how about we just avoid anything that uses the terms like "Mappings" and
"NAT" and speed the adoption of IPv6 everywhere which already solves all of
these problems.


*Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net
*Arbor Networks*
+1.734.794.5033 (d) | +1.734.846.2053 (m)
www.arbornetworks.com

On Mon, Jul 4, 2016 at 10:16 PM, Masataka Ohta <
mohta at necom830.hpcl.titech.ac.jp> wrote:

> Baldur Norddahl wrote:
>
> With end to end NAT, you can still configure your UPnP capable NAT
>>> boxes to restrict port forwarding.
>>>
>>
> Only if you by NAT mean "home network NAT". No large ISP has or will deploy
>> a carrier NAT router that will respect UPnP.
>>
>
> A large ISP should just set up usual NAT. In addition, the ISP
> tells its subscriber a global IP address, a private IP address
> and a small range of port numbers the subscriber can use and
> set up *static* bi-directional port forwarding.
>
> If each subscriber is allocated 64 ports, effective address
> space is 1000 times more than that of IPv4, which should be
> large enough.
>
> Then, if a subscriber want transparency, he can set up his
> home router make use of the bi-directional port forwarding
> and his host reverse translation by nested port forwarding.
>
> That does not scale and is a
>> security nightmare besides.
>>
>
> It is merely because you think you must do it dynamically.
>
> But, if you want to run a server at fixed IP address
> and port, port forwarding must be static.
>
>                                                 Masataka Ohta
>

From mattlists at rivervalleyinternet.net  Tue Jul  5 02:32:47 2016
From: mattlists at rivervalleyinternet.net (Matt Hoppes)
Date: Mon, 4 Jul 2016 22:32:47 -0400
Subject: IPv6 deployment excuses
In-Reply-To: <20160705010018.GC8803@puck.nether.net>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <3e1b229.kqhkiG.155a8439000@slabnet.com>
 <2634D4B9-A92B-408F-87C8-AA9C0A8CCEFB@puck.nether.net>
 <13e05110-89bf-a000-f7e3-1b7c39ad8588@necom830.hpcl.titech.ac.jp>
 <C352698F-3520-4405-86B7-6150815352A7@puck.nether.net>
 <2ae7bdc3-eeaa-9a3b-b8bd-013086b8bb95@necom830.hpcl.titech.ac.jp>
 <20160705010018.GC8803@puck.nether.net>
Message-ID: <38CAAADF-ADDC-415A-9AD3-C9E55ECD8ADC@rivervalleyinternet.net>

Jared,
The issue I have with the whole DNS IPv6 thing is IPs are static (on infrastructure), DNS can get munged up and is another database we have to maintain. 

So now rather than just maintaining an IP database we have to maintain a database for DNS to IP and the IP. 

And Ina subscriber network things like cpe12232.domain.com are worthless for identifying the end user so I'm referencing the Ip back to something else anyway. 

From mohta at necom830.hpcl.titech.ac.jp  Tue Jul  5 02:34:17 2016
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Tue, 5 Jul 2016 11:34:17 +0900
Subject: IPv6 deployment excuses
In-Reply-To: <20160705010018.GC8803@puck.nether.net>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <3e1b229.kqhkiG.155a8439000@slabnet.com>
 <2634D4B9-A92B-408F-87C8-AA9C0A8CCEFB@puck.nether.net>
 <13e05110-89bf-a000-f7e3-1b7c39ad8588@necom830.hpcl.titech.ac.jp>
 <C352698F-3520-4405-86B7-6150815352A7@puck.nether.net>
 <2ae7bdc3-eeaa-9a3b-b8bd-013086b8bb95@necom830.hpcl.titech.ac.jp>
 <20160705010018.GC8803@puck.nether.net>
Message-ID: <c8f9b782-9f65-f761-7cbe-4ebe645045f0@necom830.hpcl.titech.ac.jp>

Jared Mauch wrote:

>> Are you saying, without NAT or something like that to restrict
>> reachable ports, the Internet, regardless of whether it is with
>> IPv4 or IPv6, is not very secure?
>
> 	I'm saying two things:
>
> 	1) UPnP is a security nightmare and nobody (at scale)
> will let you register ports with their CGN/edge.

Don't do that. Just have static port forwarding. UPnP
may be used as a channel to advertise the forwarding
information but you can also do it manually (for reverse
translation, configuring a global IP address and a range
of port numbers is enough).

> 	2) We are an industry in transition.  Internet connectivity
> will soon be defined by v6 + v4, not v4+ sometimes v6.

Yeah, we have been so for these 20 years.

> 	Our services need to work for the broadest set of users.  Many
> people are now used to the non-e2e results of a NAT/CGN environment.

Exactly. And, as e2e transparency over NAT can be offered to
exceptional people, we can live with IPv4 forever.

							Masataka Ohta


From jared at puck.nether.net  Tue Jul  5 02:47:42 2016
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 4 Jul 2016 22:47:42 -0400
Subject: IPv6 deployment excuses
In-Reply-To: <38CAAADF-ADDC-415A-9AD3-C9E55ECD8ADC@rivervalleyinternet.net>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <3e1b229.kqhkiG.155a8439000@slabnet.com>
 <2634D4B9-A92B-408F-87C8-AA9C0A8CCEFB@puck.nether.net>
 <13e05110-89bf-a000-f7e3-1b7c39ad8588@necom830.hpcl.titech.ac.jp>
 <C352698F-3520-4405-86B7-6150815352A7@puck.nether.net>
 <2ae7bdc3-eeaa-9a3b-b8bd-013086b8bb95@necom830.hpcl.titech.ac.jp>
 <20160705010018.GC8803@puck.nether.net>
 <38CAAADF-ADDC-415A-9AD3-C9E55ECD8ADC@rivervalleyinternet.net>
Message-ID: <BE670C64-040E-4827-A090-1A99E4FA9413@puck.nether.net>


> On Jul 4, 2016, at 10:32 PM, Matt Hoppes <mattlists at rivervalleyinternet.net> wrote:
> 
> Jared,
> The issue I have with the whole DNS IPv6 thing is IPs are static (on infrastructure), DNS can get munged up and is another database we have to maintain. 

I?m not sure I understand your point.  DNS is DNS.  It?s not the 1990s anymore and people should not be doing this without automation.

> So now rather than just maintaining an IP database we have to maintain a database for DNS to IP and the IP. 

This should be done at the same time.  There?s plenty of people who have done this, so you shouldn?t have to build it yourself either, but you may want to.

> And Ina subscriber network things like cpe12232.domain.com are worthless for identifying the end user so I'm referencing the Ip back to something else anyway.

Your central unit should be the subscriber and they should have the relevant attributes associated with them, be it IP history as well as account history.  You can have the DNS system sign on the fly if you have DNSSEC and that?s your concern.  IPv6 hosts still leave something to be desired for dynamic DNS entries, but looking at what happens behind Comcast as an example, there are no PTR records, eg:

2601:401:4:3000:71d1:cf8e:a951:xxxx -> x.x.x.x.1.5.9.a.e.8.f.c.1.d.1.7.0.0.0.3.4.0.0.0.1.0.4.0.1.0.6.2.ip6.arpa not found: 3(NXDOMAIN)

If you want to make it more user friendly, you can overload it like this:

openresolverproject.org has address 204.42.254.206
openresolverproject.org has IPv6 address 2001:418::7011:204:42:254:206

- Jared

From Valdis.Kletnieks at vt.edu  Tue Jul  5 04:00:56 2016
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 05 Jul 2016 00:00:56 -0400
Subject: IPv6 deployment excuses
In-Reply-To: <9276b70b-09fd-3521-99a0-12d8045ba6eb@necom830.hpcl.titech.ac.jp>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <3e1b229.kqhkiG.155a8439000@slabnet.com>
 <2634D4B9-A92B-408F-87C8-AA9C0A8CCEFB@puck.nether.net>
 <13e05110-89bf-a000-f7e3-1b7c39ad8588@necom830.hpcl.titech.ac.jp>
 <C352698F-3520-4405-86B7-6150815352A7@puck.nether.net>
 <2ae7bdc3-eeaa-9a3b-b8bd-013086b8bb95@necom830.hpcl.titech.ac.jp>
 <CAPkb-7Cxq0XZ663ysMbHCGfK_QTCfkSBgDf_tV-1c-QB+9Y+Rg@mail.gmail.com>
 <9276b70b-09fd-3521-99a0-12d8045ba6eb@necom830.hpcl.titech.ac.jp>
Message-ID: <50534.1467691256@turing-police.cc.vt.edu>

On Tue, 05 Jul 2016 11:16:31 +0900, Masataka Ohta said:

> A large ISP should just set up usual NAT. In addition, the ISP
> tells its subscriber a global IP address, a private IP address
> and a small range of port numbers the subscriber can use and
> set up *static* bi-directional port forwarding.

Thus almost guaranteeing a call to the support desk for each and every single
game console, because the PS3 and PS4 doesn't have a configuration interface
for that, and the XBox probably doesn't either (and if it does, it's probably
something that Joe Sixpack can't do without help).

> It is merely because you think you must do it dynamically.
>
> But, if you want to run a server at fixed IP address
> and port, port forwarding must be static.

A laudable network design for my competitors.  Feel free to deploy it at a
realistic sized ISP and let us know how it works out.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160705/1d23a461/attachment.pgp>

From mohta at necom830.hpcl.titech.ac.jp  Tue Jul  5 04:22:59 2016
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Tue, 5 Jul 2016 13:22:59 +0900
Subject: IPv6 deployment excuses
In-Reply-To: <50534.1467691256@turing-police.cc.vt.edu>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <3e1b229.kqhkiG.155a8439000@slabnet.com>
 <2634D4B9-A92B-408F-87C8-AA9C0A8CCEFB@puck.nether.net>
 <13e05110-89bf-a000-f7e3-1b7c39ad8588@necom830.hpcl.titech.ac.jp>
 <C352698F-3520-4405-86B7-6150815352A7@puck.nether.net>
 <2ae7bdc3-eeaa-9a3b-b8bd-013086b8bb95@necom830.hpcl.titech.ac.jp>
 <CAPkb-7Cxq0XZ663ysMbHCGfK_QTCfkSBgDf_tV-1c-QB+9Y+Rg@mail.gmail.com>
 <9276b70b-09fd-3521-99a0-12d8045ba6eb@necom830.hpcl.titech.ac.jp>
 <50534.1467691256@turing-police.cc.vt.edu>
Message-ID: <59c05275-721b-f62b-7089-0dad82d4eeac@necom830.hpcl.titech.ac.jp>

Valdis.Kletnieks at vt.edu wrote:

>> A large ISP should just set up usual NAT. In addition,

> Thus almost guaranteeing a call to the support desk for each and every single
> game console, because the PS3 and PS4 doesn't have a configuration interface
> for that, and the XBox probably doesn't either (and if it does, it's probably
> something that Joe Sixpack can't do without help).

With usual NAT? That is not my problem.

>> But, if you want to run a server at fixed IP address
>> and port, port forwarding must be static.
>
> A laudable network design for my competitors.  Feel free to deploy it at a
> realistic sized ISP and let us know how it works out.

Are you saying there is no realistic sized ISP offering fixed
IP addresses without NAT?

If not, additional setup of static port forwarding on NAT boxes
can not be a problem.

						Masataka Ohta



From swmike at swm.pp.se  Tue Jul  5 05:27:31 2016
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Tue, 5 Jul 2016 07:27:31 +0200 (CEST)
Subject: IPv6 deployment excuses
In-Reply-To: <CAPkb-7DeW31M1dpOAU2hGmXkPBrQ_Nfj-LYWE-fp02663WmF9A@mail.gmail.com>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <3e1b229.kqhkiG.155a8439000@slabnet.com>
 <2634D4B9-A92B-408F-87C8-AA9C0A8CCEFB@puck.nether.net>
 <13e05110-89bf-a000-f7e3-1b7c39ad8588@necom830.hpcl.titech.ac.jp>
 <C352698F-3520-4405-86B7-6150815352A7@puck.nether.net>
 <2ae7bdc3-eeaa-9a3b-b8bd-013086b8bb95@necom830.hpcl.titech.ac.jp>
 <CAPkb-7Cxq0XZ663ysMbHCGfK_QTCfkSBgDf_tV-1c-QB+9Y+Rg@mail.gmail.com>
 <CAD6AjGSpSN_1PXVTxnG+jTrppbEhLXEZpAcu9dpb12-WM-5x5g@mail.gmail.com>
 <CAPkb-7DeW31M1dpOAU2hGmXkPBrQ_Nfj-LYWE-fp02663WmF9A@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1607050725420.2309@uplift.swm.pp.se>

On Mon, 4 Jul 2016, Baldur Norddahl wrote:

> The two other technologies mentioned do the same as MAP more or less, 
> but both requires carrier NAT, which is expensive for the ISP and has a 
> lack of control as seen from the end user point of view (no port 
> forwarding etc).

What it does however, is make things like GRE work. Some are surprised 
that there is actually non A+P protocols being used by customers. For 
instance legacy PPTP uses this, so some business VPNs run into problem 
with MAP or LW4o6.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se

From baldur.norddahl at gmail.com  Tue Jul  5 08:36:34 2016
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Tue, 5 Jul 2016 10:36:34 +0200
Subject: IPv6 deployment excuses
In-Reply-To: <alpine.DEB.2.02.1607050725420.2309@uplift.swm.pp.se>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <3e1b229.kqhkiG.155a8439000@slabnet.com>
 <2634D4B9-A92B-408F-87C8-AA9C0A8CCEFB@puck.nether.net>
 <13e05110-89bf-a000-f7e3-1b7c39ad8588@necom830.hpcl.titech.ac.jp>
 <C352698F-3520-4405-86B7-6150815352A7@puck.nether.net>
 <2ae7bdc3-eeaa-9a3b-b8bd-013086b8bb95@necom830.hpcl.titech.ac.jp>
 <CAPkb-7Cxq0XZ663ysMbHCGfK_QTCfkSBgDf_tV-1c-QB+9Y+Rg@mail.gmail.com>
 <CAD6AjGSpSN_1PXVTxnG+jTrppbEhLXEZpAcu9dpb12-WM-5x5g@mail.gmail.com>
 <CAPkb-7DeW31M1dpOAU2hGmXkPBrQ_Nfj-LYWE-fp02663WmF9A@mail.gmail.com>
 <alpine.DEB.2.02.1607050725420.2309@uplift.swm.pp.se>
Message-ID: <CAPkb-7B9AhtLvpn+tzYX_4PEcehaUE7k+dXX7HhmbyVeuYr8mQ@mail.gmail.com>

On 5 July 2016 at 07:27, Mikael Abrahamsson <swmike at swm.pp.se> wrote:

> On Mon, 4 Jul 2016, Baldur Norddahl wrote:
>
> The two other technologies mentioned do the same as MAP more or less, but
>> both requires carrier NAT, which is expensive for the ISP and has a lack of
>> control as seen from the end user point of view (no port forwarding etc).
>>
>
> What it does however, is make things like GRE work. Some are surprised
> that there is actually non A+P protocols being used by customers. For
> instance legacy PPTP uses this, so some business VPNs run into problem with
> MAP or LW4o6.


We will tell you to use IPv6 for that or make you pay extra for a dedicated
IPv4 address. Everyone else do not need to help pay for a CGN solution just
because you did not move ahead with IPv6.

To clarify, right now at this moment we are pure dual stack with everyone
have both their own IPv4 and a /48 IPv6 prefix. But I can see some time in
the not too distant future where there will be market acceptance of a
solution with crippled IPv4 MAP style NAT plus full connectivity using
IPv6. In fact I believe we are already there as most people really do not
care as long their gmail and Facebook works.

The only thing that stops me from deploying MAP is lack of vendor support.
I am working on that.

Regards,

Baldur

From swmike at swm.pp.se  Tue Jul  5 08:55:47 2016
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Tue, 5 Jul 2016 10:55:47 +0200 (CEST)
Subject: IPv6 deployment excuses
In-Reply-To: <CAPkb-7B9AhtLvpn+tzYX_4PEcehaUE7k+dXX7HhmbyVeuYr8mQ@mail.gmail.com>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <3e1b229.kqhkiG.155a8439000@slabnet.com>
 <2634D4B9-A92B-408F-87C8-AA9C0A8CCEFB@puck.nether.net>
 <13e05110-89bf-a000-f7e3-1b7c39ad8588@necom830.hpcl.titech.ac.jp>
 <C352698F-3520-4405-86B7-6150815352A7@puck.nether.net>
 <2ae7bdc3-eeaa-9a3b-b8bd-013086b8bb95@necom830.hpcl.titech.ac.jp>
 <CAPkb-7Cxq0XZ663ysMbHCGfK_QTCfkSBgDf_tV-1c-QB+9Y+Rg@mail.gmail.com>
 <CAD6AjGSpSN_1PXVTxnG+jTrppbEhLXEZpAcu9dpb12-WM-5x5g@mail.gmail.com>
 <CAPkb-7DeW31M1dpOAU2hGmXkPBrQ_Nfj-LYWE-fp02663WmF9A@mail.gmail.com>
 <alpine.DEB.2.02.1607050725420.2309@uplift.swm.pp.se>
 <CAPkb-7B9AhtLvpn+tzYX_4PEcehaUE7k+dXX7HhmbyVeuYr8mQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1607051047380.2309@uplift.swm.pp.se>

On Tue, 5 Jul 2016, Baldur Norddahl wrote:

> We will tell you to use IPv6 for that or make you pay extra for a 
> dedicated IPv4 address.

That is a good solution to that problem. I hope all ISPs implementing A+P 
protocols does that. It also puts a monthly cost that teleworkers have to 
pay (or their employers have to pay) for not supporting IPv6 on their 
enterprise solutions. Hopefully that'll drive IPv6 interest in the 
enterprise space as well.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se

From nanog at ics-il.net  Tue Jul  5 12:32:43 2016
From: nanog at ics-il.net (Mike Hammett)
Date: Tue, 5 Jul 2016 07:32:43 -0500 (CDT)
Subject: IPv6 deployment excuses
In-Reply-To: <59c05275-721b-f62b-7089-0dad82d4eeac@necom830.hpcl.titech.ac.jp>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <13e05110-89bf-a000-f7e3-1b7c39ad8588@necom830.hpcl.titech.ac.jp>
 <C352698F-3520-4405-86B7-6150815352A7@puck.nether.net>
 <2ae7bdc3-eeaa-9a3b-b8bd-013086b8bb95@necom830.hpcl.titech.ac.jp>
 <CAPkb-7Cxq0XZ663ysMbHCGfK_QTCfkSBgDf_tV-1c-QB+9Y+Rg@mail.gmail.com>
 <9276b70b-09fd-3521-99a0-12d8045ba6eb@necom830.hpcl.titech.ac.jp>
 <50534.1467691256@turing-police.cc.vt.edu>
 <59c05275-721b-f62b-7089-0dad82d4eeac@necom830.hpcl.titech.ac.jp>
Message-ID: <121062489.10372.1467721959654.JavaMail.mhammett@ThunderFuck>

Are you saying that functional game consoles aren't your problem? 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

----- Original Message -----

From: "Masataka Ohta" <mohta at necom830.hpcl.titech.ac.jp> 
To: "Valdis Kletnieks" <Valdis.Kletnieks at vt.edu> 
Cc: nanog at nanog.org 
Sent: Monday, July 4, 2016 11:22:59 PM 
Subject: Re: IPv6 deployment excuses 

Valdis.Kletnieks at vt.edu wrote: 

>> A large ISP should just set up usual NAT. In addition, 

> Thus almost guaranteeing a call to the support desk for each and every single 
> game console, because the PS3 and PS4 doesn't have a configuration interface 
> for that, and the XBox probably doesn't either (and if it does, it's probably 
> something that Joe Sixpack can't do without help). 

With usual NAT? That is not my problem. 

>> But, if you want to run a server at fixed IP address 
>> and port, port forwarding must be static. 
> 
> A laudable network design for my competitors. Feel free to deploy it at a 
> realistic sized ISP and let us know how it works out. 

Are you saying there is no realistic sized ISP offering fixed 
IP addresses without NAT? 

If not, additional setup of static port forwarding on NAT boxes 
can not be a problem. 

Masataka Ohta 




From jason+nanog at lixfeld.ca  Tue Jul  5 13:41:15 2016
From: jason+nanog at lixfeld.ca (Jason Lixfeld)
Date: Tue, 5 Jul 2016 09:41:15 -0400
Subject: Recommendations for used satellite decoder resellers
Message-ID: <C6F876F7-8DF6-4C3A-861B-678BA313CEBF@lixfeld.ca>

Hello,

I?m wondering if anyone can refer me to a company they?ve used in the past who may have (access to) used satellite decoder equipment.  I?m in the market for some used Sencore kit.

Thanks in advance!

From morgan.miskell at caro.net  Fri Jul  1 18:24:47 2016
From: morgan.miskell at caro.net (Morgan A. Miskell)
Date: Fri, 1 Jul 2016 14:24:47 -0400
Subject: XO NOC
Message-ID: <5776B56F.9020306@caro.net>

Anyone from the XO NOC online that can help with a routing issue?
If so, contact me directly off-list please.....oh and due to the routing 
issue you would need to email me at mormis99 at gmail.com.

-- 
Morgan A. Miskell
CaroNet Data Centers
704-643-8330 x206
----------------------------------------------------------------------------
The information contained in this e-mail is confidential and is intended
only for the named recipient(s). If you are not the intended recipient
you must not copy, distribute, or take any action or reliance on it. If
you have received this e-mail in error, please notify the sender. Any
unauthorized disclosure of the information contained in this e-mail is
strictly prohibited.
----------------------------------------------------------------------------


From dredgarcarver at gmail.com  Sat Jul  2 02:28:54 2016
From: dredgarcarver at gmail.com (Edgar Carver)
Date: Fri, 1 Jul 2016 21:28:54 -0500
Subject: NAT firewall for IPv6?
Message-ID: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>

Hello NANOG community. I was directed here by our network administrator
since she is on vacation. Luckily, I minored in Computer Science so I have
some familiarity.

We have a small satellite campus of around 170 devices that share one
external IPv4 and IPv6 address via NAT for internet traffic. Internal
traffic is over an MPLS.

We're having problems where viruses are getting through Firefox, and we
think it's because our Palo Alto firewall is set to bypass filtering for
IPv6. Unfortunately, the network admin couldn't give me the password since
a local consultant set it up, and it seems they went out of business. I
need to think outside the box.

Is there some kind of NAT-based IPv6 firewall I can setup on the router
that can help block viruses? I figure that's the right place to start since
all the traffic gets funneled there. We have a Cisco Catalyst as a
router. Or, ideally, is there an easy way to turn off IPv6 completely? I
really don't see a need for it, any legitimate service should have an IPv4
address.

I'd really appreciate your advice. I plan to drive out there tomorrow,
where I can get the exact model numbers and stuff.

Regards,
Dr. Edgar Carver

From sryan at arbor.net  Tue Jul  5 13:50:25 2016
From: sryan at arbor.net (Spencer Ryan)
Date: Tue, 5 Jul 2016 09:50:25 -0400
Subject: NAT firewall for IPv6?
In-Reply-To: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
Message-ID: <CA+HzidRZKuPik555eg=HmadX_UxS1w-g1oZmjW3cvAs+YyCwRw@mail.gmail.com>

You emailed the wrong list to say this "Or, ideally, is there an easy way
to turn off IPv6 completely? I
really don't see a need for it, any legitimate service should have an IPv4
address."

Turning off IPv6 is not the right solution, nor will it magically fix your
issues.

Fix the Palo Alto, either hire another consultant or just erase it and
start over. Although even PA's Layer7 inspection won't catch everything and
you should have antivirus/antimailware software on the end user computers.


*Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net
*Arbor Networks*
+1.734.794.5033 (d) | +1.734.846.2053 (m)
www.arbornetworks.com

On Fri, Jul 1, 2016 at 10:28 PM, Edgar Carver <dredgarcarver at gmail.com>
wrote:

> Hello NANOG community. I was directed here by our network administrator
> since she is on vacation. Luckily, I minored in Computer Science so I have
> some familiarity.
>
> We have a small satellite campus of around 170 devices that share one
> external IPv4 and IPv6 address via NAT for internet traffic. Internal
> traffic is over an MPLS.
>
> We're having problems where viruses are getting through Firefox, and we
> think it's because our Palo Alto firewall is set to bypass filtering for
> IPv6. Unfortunately, the network admin couldn't give me the password since
> a local consultant set it up, and it seems they went out of business. I
> need to think outside the box.
>
> Is there some kind of NAT-based IPv6 firewall I can setup on the router
> that can help block viruses? I figure that's the right place to start since
> all the traffic gets funneled there. We have a Cisco Catalyst as a
> router. Or, ideally, is there an easy way to turn off IPv6 completely? I
> really don't see a need for it, any legitimate service should have an IPv4
> address.
>
> I'd really appreciate your advice. I plan to drive out there tomorrow,
> where I can get the exact model numbers and stuff.
>
> Regards,
> Dr. Edgar Carver
>

From jackson.tim at gmail.com  Tue Jul  5 14:11:37 2016
From: jackson.tim at gmail.com (Tim Jackson)
Date: Tue, 5 Jul 2016 09:11:37 -0500
Subject: Recommendations for used satellite decoder resellers
In-Reply-To: <C6F876F7-8DF6-4C3A-861B-678BA313CEBF@lixfeld.ca>
References: <C6F876F7-8DF6-4C3A-861B-678BA313CEBF@lixfeld.ca>
Message-ID: <CAK19Y1cdLkvrpKLRa43S2uz95qdT7ctfx2MrOhioNV8Y0K=hpg@mail.gmail.com>

This Yahoo group has a bunch of CATV gear for sale and is still pretty
active.. Shooting a message on here might work:

https://beta.groups.yahoo.com/neo/groups/buyandsellCATV/info

--
Tim

On Tue, Jul 5, 2016 at 8:41 AM, Jason Lixfeld <jason+nanog at lixfeld.ca>
wrote:

> Hello,
>
> I?m wondering if anyone can refer me to a company they?ve used in the past
> who may have (access to) used satellite decoder equipment.  I?m in the
> market for some used Sencore kit.
>
> Thanks in advance!

From SNaslund at medline.com  Tue Jul  5 14:14:11 2016
From: SNaslund at medline.com (Naslund, Steve)
Date: Tue, 5 Jul 2016 14:14:11 +0000
Subject: NAT firewall for IPv6?
In-Reply-To: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
Message-ID: <9578293AE169674F9A048B2BC9A081B401E663D00B@MUNPRDMBXA1.medline.com>

Hard to know where to begin with this one, but let me take a shot at it.

1.  My top priority would be to get into that Palo Alto firewall.  Get Palo Alto on the phone and figure out password recovery with them.  Since you don?t have the password it is possible that firewall is compromised.  Do not be surprised if you have to jump through some hoops with Palo Alto to prove that you own it and what has happened.  Remember their job is to keep people out of your network.  They are probably also going to want you to be current on support.  If you have to pay to get current on support, do it.  You need that help right now badly.

You could ask Palo Alto how to block the v6 while you are at it or even better set up a rules that mirror your v4 protection.   I cannot stress enough how big a security issue it is to not have access to your firewall and not know who does.

2.  There are lots of ways to shut off ipv6 but my suggestion would be to just secure the Palo Alto firewall, to say that any legitimate service should have a ipv4 address is not quite true now and will definitely not be true in the near future.

3.  Just about any kind of firewall or router CPE device can block or firewall ipv4 and ipv6 as long as its firmware is fairly recent.  However, you would most likely have to replace the Palo Alto with it.  You DO NOT WANT THEM BOTH INLINE!  Most likely they are both configured to do ipv4 NAT out of the box and that will not work correctly to have them both inline together.  While it is possible to set up that sort of thing to work correctly, it?s a bad idea and pretty advanced configuration for a temporary network admin.  The interaction of one firewall fronting another can be very difficult to troubleshoot without a deep understanding of what is going on.  Referring back to item 1, you are probably going to need to get the configuration of the current firewall if you seek to replace it (there will be rules in the Palo Alto that you would want to replicate if you are going to replace it).

4.  Cisco Catalyst as the router.....there could be a lot of things going on in there.  The Catalyst is primarily a switch with routing functionality.  It can definitely block ipv6 if configured to do so but we would need to know a lot more about its current configuration to give you the best way to do that.  It could just be a service providers switch on your premise in which case you can't do much with it.  Again, much easier to accomplish Item 1 with Palo Alto and let your firewall do what it is supposed to do.

Steven Naslund
Chicago IL



-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Edgar Carver
Sent: Friday, July 01, 2016 9:29 PM
To: nanog at nanog.org
Subject: NAT firewall for IPv6?

Hello NANOG community. I was directed here by our network administrator since she is on vacation. Luckily, I minored in Computer Science so I have some familiarity.

We have a small satellite campus of around 170 devices that share one external IPv4 and IPv6 address via NAT for internet traffic. Internal traffic is over an MPLS.

We're having problems where viruses are getting through Firefox, and we think it's because our Palo Alto firewall is set to bypass filtering for IPv6. Unfortunately, the network admin couldn't give me the password since a local consultant set it up, and it seems they went out of business. I need to think outside the box.

Is there some kind of NAT-based IPv6 firewall I can setup on the router that can help block viruses? I figure that's the right place to start since all the traffic gets funneled there. We have a Cisco Catalyst as a router. Or, ideally, is there an easy way to turn off IPv6 completely? I really don't see a need for it, any legitimate service should have an IPv4 address.

I'd really appreciate your advice. I plan to drive out there tomorrow, where I can get the exact model numbers and stuff.

Regards,
Dr. Edgar Carver

From SNaslund at medline.com  Tue Jul  5 14:31:35 2016
From: SNaslund at medline.com (Naslund, Steve)
Date: Tue, 5 Jul 2016 14:31:35 +0000
Subject: NAT firewall for IPv6?
In-Reply-To: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
Message-ID: <9578293AE169674F9A048B2BC9A081B401E663D03D@MUNPRDMBXA1.medline.com>

On another note, using a firewall to stop viruses is probably not going to work in general (unless the firewall has some additional malware detection engine).  

Here is the issue in a nutshell.  A firewall primarily controls where people can connect to and from on a network.  The problem with that is that a lot of malware is received from sites that your users intended to go to.  People click on links without knowing where they go and people go to less than reputable web sites (or reputable sites that we recently compromised).  If you, by default, allow your users to access the Internet with a browser they are vulnerable to malware.  Even with malware detection capability you are still vulnerable to signatures and attacks that are not yet able to be detected.

Even if filtering was enabled on your Palo Alto for ipv6 it would not help at this point because you have no idea what signatures it is using to filter with and when the last time those were updated  I doubt your v4 filtering is of much use either at this point.  URL filtering is largely a big game of whack a mole that you will lose eventually.  Malware filtering is based on one or both of the following methods.  

	1.  You filter URLs known to be bad players (you are vulnerable until your protection vendor realizes they are bad players).

	2.  You filter based on adaptive detection of code that looks suspicious.  This is a bit better but still vulnerable because the bad guys are always innovating to pass through these devices.

My recommendation would be network malware detection (possibly through a firewall add-on) as well as good virus/malware detection on the client computers.  Sometimes the malware is easier to detect at the client because it reveals itself by trying to access unauthorized memory, processes, or storage.

Steven Naslund
Chicago IL




-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Edgar Carver
Sent: Friday, July 01, 2016 9:29 PM
To: nanog at nanog.org
Subject: NAT firewall for IPv6?

Hello NANOG community. I was directed here by our network administrator since she is on vacation. Luckily, I minored in Computer Science so I have some familiarity.

We have a small satellite campus of around 170 devices that share one external IPv4 and IPv6 address via NAT for internet traffic. Internal traffic is over an MPLS.

We're having problems where viruses are getting through Firefox, and we think it's because our Palo Alto firewall is set to bypass filtering for IPv6. Unfortunately, the network admin couldn't give me the password since a local consultant set it up, and it seems they went out of business. I need to think outside the box.

Is there some kind of NAT-based IPv6 firewall I can setup on the router that can help block viruses? I figure that's the right place to start since all the traffic gets funneled there. We have a Cisco Catalyst as a router. Or, ideally, is there an easy way to turn off IPv6 completely? I really don't see a need for it, any legitimate service should have an IPv4 address.

I'd really appreciate your advice. I plan to drive out there tomorrow, where I can get the exact model numbers and stuff.

Regards,
Dr. Edgar Carver

From Valdis.Kletnieks at vt.edu  Tue Jul  5 14:33:22 2016
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 05 Jul 2016 10:33:22 -0400
Subject: NAT firewall for IPv6?
In-Reply-To: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
Message-ID: <95791.1467729202@turing-police.cc.vt.edu>

On Fri, 01 Jul 2016 21:28:54 -0500, Edgar Carver said:

> We're having problems where viruses are getting through Firefox, and we
> think it's because our Palo Alto firewall is set to bypass filtering for
> IPv6.

Do you have any actual evidence (device logs, tcpdump, netflow,  etc) that
support that train of thought?

Remember that your Palo Alto isn't stopping 100% of the icky stuff on the
IPv4 side either - the sad truth is that most commercial security software
is only able to identify and block between 30% and 70% of the crap that's
out in the wild. There's also BYOD issues where a laptop comes in and infects
all your systems from behind the firewall (as Marcus Ranum says: "Crunchy on
the outside, soft and chewy inside").

In any case,your first two actions should be to recover the password for the
Palo Alto, and make sure it has updated pattern definitions in effect on both
IPv4 and IPv6 connections.

And your third should be to re-examine your vendor rules of engagement, to
ensure your deliverables include things like passwords and update support
so you're not stuck if your vendor goes belly up..


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160705/29fd9a0d/attachment.pgp>

From bruns at 2mbit.com  Tue Jul  5 14:42:10 2016
From: bruns at 2mbit.com (Brielle Bruns)
Date: Tue, 5 Jul 2016 08:42:10 -0600
Subject: NAT firewall for IPv6?
In-Reply-To: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
Message-ID: <17a54b01-e9b6-87da-bc16-6867211c3444@2mbit.com>

On 7/1/16 8:28 PM, Edgar Carver wrote:
> Unfortunately, the network admin couldn't give me the password since
> a local consultant set it up, and it seems they went out of business. I
> need to think outside the box.

So your network admin didn't bother to get the login/enable password for 
a device that is an integral part of your network?   That's...  a very 
big lapse in their responsibilities.

I had a consultant recently in CO try to pull the same stunt on me for 
one of the companies I consult for - stalling, giving bullshit reasons, 
etc on why they couldn't just hand over the administrative passwords to 
the actual IT people in the company.

Why were we demanding admin access?  Because the company we were paying 
to maintain it we suspected weren't doing their job.  We figured they 
knew exactly why we were asking for the information, and were buying time.

IIRC, we were right about the condition of the firewall, switches, etc.


Anyways, moral of the story, don't let a consultant hold any and all the 
keys to the castle for exactly the situation you have right now.

-- 
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org    /     http://www.ahbl.org

From bruce.curtis at ndsu.edu  Tue Jul  5 14:47:53 2016
From: bruce.curtis at ndsu.edu (Bruce Curtis)
Date: Tue, 5 Jul 2016 14:47:53 +0000
Subject: NAT firewall for IPv6?
In-Reply-To: <95791.1467729202@turing-police.cc.vt.edu>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
 <95791.1467729202@turing-police.cc.vt.edu>
Message-ID: <78FC2185-51C8-4D06-B6EE-881663630871@ndsu.edu>


> On Jul 5, 2016, at 9:33 AM, Valdis.Kletnieks at vt.edu wrote:
> 
> On Fri, 01 Jul 2016 21:28:54 -0500, Edgar Carver said:
> 
>> We're having problems where viruses are getting through Firefox, and we
>> think it's because our Palo Alto firewall is set to bypass filtering for
>> IPv6.
> 
> Do you have any actual evidence (device logs, tcpdump, netflow,  etc) that
> support that train of thought?
> 
> Remember that your Palo Alto isn't stopping 100% of the icky stuff on the
> IPv4 side either - the sad truth is that most commercial security software
> is only able to identify and block between 30% and 70% of the crap that's
> out in the wild.

  That is only the percentage that it identifies from what it can see.  It most likely can not see viruses in encrypted traffic.

"	? A forecast that 70% of global Internet traffic will be encrypted in 2016, with many networks exceeding 80%?

https://www.sandvine.com/pr/2016/2/11/sandvine-70-of-global-internet-traffic-will-be-encrypted-in-2016.html


"In the fourth quarter of 2015 nearly 65 percent of all web connections that Dell observed were encrypted, leading to a lot more under-the-radar attacks, according to the company. Gartner has predicted that 50 percent of all network attacks will take advantage of SSL/TLS by 2017."

http://www.darkreading.com/attacks-breaches/when-encryption-becomes-the-enemys-best-friend/d/d-id/1324580

This article mentions how difficult is it for Sandboxes to detect malware.

https://www.fireeye.com/content/dam/fireeye-www/global/en/current-threats/pdfs/fireeye-hot-knives-through-butter.pdf

This article mentions malware that changes it?s download image every 15 seconds.

http://www.darkreading.com/vulnerabilities---threats/cerber-strikes-with-office-365-zero-day-attacks/d/d-id/1326070?_mc=NL_DR_EDT_DR_weekly_20160630&cid=NL_DR_EDT_DR_weekly_20160630&elqTrackId=1d7f1b5bcdb24c469164471a423f746b&elq=01e6838c279149a08e460cdbe3b8b54a&elqaid=70982&elqat=1&elqCampaignId=21896





> There's also BYOD issues where a laptop comes in and infects
> all your systems from behind the firewall (as Marcus Ranum says: "Crunchy on
> the outside, soft and chewy inside?).

  

> In any case,your first two actions should be to recover the password for the
> Palo Alto, and make sure it has updated pattern definitions in effect on both
> IPv4 and IPv6 connections.
> 
> And your third should be to re-examine your vendor rules of engagement, to
> ensure your deliverables include things like passwords and update support
> so you're not stuck if your vendor goes belly up..
> 
> 

---
Bruce Curtis                         bruce.curtis at ndsu.edu
Certified NetAnalyst II                701-231-8527
North Dakota State University        


From josh at imaginenetworksllc.com  Tue Jul  5 14:49:31 2016
From: josh at imaginenetworksllc.com (Josh Luthman)
Date: Tue, 5 Jul 2016 10:49:31 -0400
Subject: Gmail down
Message-ID: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>

Web interface is broken, downdetector sure sees activity.  This attempt is
from mobile.

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

From josh at imaginenetworksllc.com  Tue Jul  5 14:53:34 2016
From: josh at imaginenetworksllc.com (Josh Luthman)
Date: Tue, 5 Jul 2016 10:53:34 -0400
Subject: Gmail down
In-Reply-To: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
References: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
Message-ID: <CAN9qwJ-Ded_157pWjp7mgVQgWVpNLjY2XEka0SDZ5g2+afG8PQ@mail.gmail.com>

Looks like it's back up for both my personal and work accounts (issue
limited to the web interface).

851 reports and climbing every time I refresh @
http://downdetector.com/status/gmail


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Tue, Jul 5, 2016 at 10:49 AM, Josh Luthman <josh at imaginenetworksllc.com>
wrote:

> Web interface is broken, downdetector sure sees activity.  This attempt is
> from mobile.
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>

From SNaslund at medline.com  Tue Jul  5 14:54:16 2016
From: SNaslund at medline.com (Naslund, Steve)
Date: Tue, 5 Jul 2016 14:54:16 +0000
Subject: NAT firewall for IPv6?
In-Reply-To: <95791.1467729202@turing-police.cc.vt.edu>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
 <95791.1467729202@turing-police.cc.vt.edu>
Message-ID: <9578293AE169674F9A048B2BC9A081B401E663D0C4@MUNPRDMBXA1.medline.com>

That is a good point.  In order for your PCs to be compromised via ipv6, they would have to be able to establish ipv6 connectivity to each other or to an internet location.  

If your network is not configured to support ipv6 it will probably only be possible for your clients to communicate with each other via ipv6 on the local LAN meaning they could only be infecting each other.  In order for your clients to be receiving traffic from the Internet via ipv6 would probably require routing and ipv6 configuration support that it sounds like your network does not have.  If your firewall is passing v6 traffic, it must understand it enough to forward it across interfaces.

At this point it does not much matter whether the transport layer is v4 or v6 because this problem is higher up the protocol stack.  Setting up your firewall to bypass v6 (i.e. just pass it) was a huge tactical error (might be why your consultant is out of business :) and a bit hard for me to understand.  If you want v6 then you would apply the same policies that you do to v4 traffic and if you don't want v6 you would just tell the firewall to drop it.  

I think it is much more probable that you are receiving malware via ipv4 or even executable attachments that the out of control firewall is not detecting.

I can tell you that we use the most current versions of Checkpoint firewalls with all of the malware bells and whistles (megabucks) and they are not still 100% effective all of the time.  We stop thousands of hacking and malware attempts per hour but it only takes one to become a big pain to deal with.


Steven Naslund 
Chicago IL




-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Valdis.Kletnieks at vt.edu
Sent: Tuesday, July 05, 2016 9:33 AM
To: Edgar Carver
Cc: nanog at nanog.org
Subject: Re: NAT firewall for IPv6?

On Fri, 01 Jul 2016 21:28:54 -0500, Edgar Carver said:

> We're having problems where viruses are getting through Firefox, and 
> we think it's because our Palo Alto firewall is set to bypass 
> filtering for IPv6.

Do you have any actual evidence (device logs, tcpdump, netflow,  etc) that support that train of thought?

Remember that your Palo Alto isn't stopping 100% of the icky stuff on the
IPv4 side either - the sad truth is that most commercial security software is only able to identify and block between 30% and 70% of the crap that's out in the wild. There's also BYOD issues where a laptop comes in and infects all your systems from behind the firewall (as Marcus Ranum says: "Crunchy on the outside, soft and chewy inside").

In any case,your first two actions should be to recover the password for the Palo Alto, and make sure it has updated pattern definitions in effect on both
IPv4 and IPv6 connections.

And your third should be to re-examine your vendor rules of engagement, to ensure your deliverables include things like passwords and update support so you're not stuck if your vendor goes belly up..



From nsuan at nonexiste.net  Tue Jul  5 14:54:41 2016
From: nsuan at nonexiste.net (Nicholas Suan)
Date: Tue, 5 Jul 2016 10:54:41 -0400
Subject: Gmail down
In-Reply-To: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
References: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
Message-ID: <CANjRqpZ7Gf4TzUU_qwzDin86sSXgKUU2hww3MTd7SA0iZ88v4A@mail.gmail.com>

I was having issues remaining connected to Gtalk but it seems to have
corrected itself.

On Tue, Jul 5, 2016 at 10:49 AM, Josh Luthman
<josh at imaginenetworksllc.com> wrote:
> Web interface is broken, downdetector sure sees activity.  This attempt is
> from mobile.
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373

From dovid at telecurve.com  Tue Jul  5 14:54:40 2016
From: dovid at telecurve.com (Dovid Bender)
Date: Tue, 5 Jul 2016 14:54:40 +0000
Subject: Gmail down
In-Reply-To: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
References: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
Message-ID: <1539992078-1467730480-cardhu_decombobulator_blackberry.rim.net-846460530-@b12.c1.bise6.blackberry>

Just came back up.


Regards,

Dovid

-----Original Message-----
From: Josh Luthman <josh at imaginenetworksllc.com>
Sender: "NANOG" <nanog-bounces at nanog.org>Date: Tue, 5 Jul 2016 10:49:31 
To: NANOG list<nanog at nanog.org>
Subject: Gmail down

Web interface is broken, downdetector sure sees activity.  This attempt is
from mobile.

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

From josh at kyneticwifi.com  Tue Jul  5 14:56:04 2016
From: josh at kyneticwifi.com (Josh Reynolds)
Date: Tue, 5 Jul 2016 09:56:04 -0500
Subject: Gmail down
In-Reply-To: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
References: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
Message-ID: <CAC6=tfYib26tkmutXn-x=s6JwCXM6RZTLkdfu-y2XWHDs2r8dQ@mail.gmail.com>

What a terrible report.

>From where? What network? Do you see issues through other networks?

- Sent from the gmail web interface

On Tue, Jul 5, 2016 at 9:49 AM, Josh Luthman
<josh at imaginenetworksllc.com> wrote:
> Web interface is broken, downdetector sure sees activity.  This attempt is
> from mobile.
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373

From maxsec at gmail.com  Tue Jul  5 14:56:27 2016
From: maxsec at gmail.com (Martin Hepworth)
Date: Tue, 5 Jul 2016 15:56:27 +0100
Subject: Gmail down
In-Reply-To: <CAN9qwJ-Ded_157pWjp7mgVQgWVpNLjY2XEka0SDZ5g2+afG8PQ@mail.gmail.com>
References: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
 <CAN9qwJ-Ded_157pWjp7mgVQgWVpNLjY2XEka0SDZ5g2+afG8PQ@mail.gmail.com>
Message-ID: <CAGDKor+7M_BrNqmDE+nPdCvkyn_J2VrZ7fvu2x1a43EYKcBMeA@mail.gmail.com>

Ok from here in the UK

-- 
Martin Hepworth, CISSP
Oxford, UK

On 5 July 2016 at 15:53, Josh Luthman <josh at imaginenetworksllc.com> wrote:

> Looks like it's back up for both my personal and work accounts (issue
> limited to the web interface).
>
> 851 reports and climbing every time I refresh @
> http://downdetector.com/status/gmail
>
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
> On Tue, Jul 5, 2016 at 10:49 AM, Josh Luthman <josh at imaginenetworksllc.com
> >
> wrote:
>
> > Web interface is broken, downdetector sure sees activity.  This attempt
> is
> > from mobile.
> >
> > Josh Luthman
> > Office: 937-552-2340
> > Direct: 937-552-2343
> > 1100 Wayne St
> > Suite 1337
> > Troy, OH 45373
> >
>

From josh at imaginenetworksllc.com  Tue Jul  5 14:56:57 2016
From: josh at imaginenetworksllc.com (Josh Luthman)
Date: Tue, 5 Jul 2016 10:56:57 -0400
Subject: Gmail down
In-Reply-To: <CAC6=tfYib26tkmutXn-x=s6JwCXM6RZTLkdfu-y2XWHDs2r8dQ@mail.gmail.com>
References: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
 <CAC6=tfYib26tkmutXn-x=s6JwCXM6RZTLkdfu-y2XWHDs2r8dQ@mail.gmail.com>
Message-ID: <CAN9qwJ8DK3BuBhMw0+NOSHGhKs6eB2csDHrUacvxDmkjv5GJfA@mail.gmail.com>

With an web interface being broken I don't believe that would be network
related.  1500 other people from different networks all saw the same issue.


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Tue, Jul 5, 2016 at 10:56 AM, Josh Reynolds <josh at kyneticwifi.com> wrote:

> What a terrible report.
>
> From where? What network? Do you see issues through other networks?
>
> - Sent from the gmail web interface
>
> On Tue, Jul 5, 2016 at 9:49 AM, Josh Luthman
> <josh at imaginenetworksllc.com> wrote:
> > Web interface is broken, downdetector sure sees activity.  This attempt
> is
> > from mobile.
> >
> > Josh Luthman
> > Office: 937-552-2340
> > Direct: 937-552-2343
> > 1100 Wayne St
> > Suite 1337
> > Troy, OH 45373
>

From josh at kyneticwifi.com  Tue Jul  5 14:59:36 2016
From: josh at kyneticwifi.com (Josh Reynolds)
Date: Tue, 5 Jul 2016 09:59:36 -0500
Subject: Gmail down
In-Reply-To: <CAN9qwJ-Ded_157pWjp7mgVQgWVpNLjY2XEka0SDZ5g2+afG8PQ@mail.gmail.com>
References: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
 <CAN9qwJ-Ded_157pWjp7mgVQgWVpNLjY2XEka0SDZ5g2+afG8PQ@mail.gmail.com>
Message-ID: <CAC6=tfZukVi2mGMa8=PwadG422XOSbByRwx8eCFzwD-mZis7Ug@mail.gmail.com>

There is an outages list @ puck.nether.net that this might have been better
suited for.

In the future, please list:
Time the issue started (followed by timezone)
Nature of the issue
Troubleshooting steps you've tried
Location
Any additional helpful information to replicate the issue
Time of resolution
On Jul 5, 2016 9:56 AM, "Josh Luthman" <josh at imaginenetworksllc.com> wrote:

> Looks like it's back up for both my personal and work accounts (issue
> limited to the web interface).
>
> 851 reports and climbing every time I refresh @
> http://downdetector.com/status/gmail
>
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
> On Tue, Jul 5, 2016 at 10:49 AM, Josh Luthman <josh at imaginenetworksllc.com
> >
> wrote:
>
> > Web interface is broken, downdetector sure sees activity.  This attempt
> is
> > from mobile.
> >
> > Josh Luthman
> > Office: 937-552-2340
> > Direct: 937-552-2343
> > 1100 Wayne St
> > Suite 1337
> > Troy, OH 45373
> >
>

From fhr at fhrnet.eu  Tue Jul  5 15:02:47 2016
From: fhr at fhrnet.eu (Filip Hruska)
Date: Tue, 5 Jul 2016 17:02:47 +0200
Subject: Gmail down
In-Reply-To: <CAGDKor+7M_BrNqmDE+nPdCvkyn_J2VrZ7fvu2x1a43EYKcBMeA@mail.gmail.com>
References: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
 <CAN9qwJ-Ded_157pWjp7mgVQgWVpNLjY2XEka0SDZ5g2+afG8PQ@mail.gmail.com>
 <CAGDKor+7M_BrNqmDE+nPdCvkyn_J2VrZ7fvu2x1a43EYKcBMeA@mail.gmail.com>
Message-ID: <577BCC17.5000006@fhrnet.eu>

Hi,

It's UP for me.
Location: Czech Republic, IPv6 access via TunnelBroker.

Regards,
Filip

On 07/05/2016 04:56 PM, Martin Hepworth wrote:
> Ok from here in the UK
>

From mianosm at gmail.com  Tue Jul  5 15:03:21 2016
From: mianosm at gmail.com (Steven Miano)
Date: Tue, 5 Jul 2016 11:03:21 -0400
Subject: Gmail down
In-Reply-To: <CAN9qwJ-Ded_157pWjp7mgVQgWVpNLjY2XEka0SDZ5g2+afG8PQ@mail.gmail.com>
References: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
 <CAN9qwJ-Ded_157pWjp7mgVQgWVpNLjY2XEka0SDZ5g2+afG8PQ@mail.gmail.com>
Message-ID: <CACkP6k=TM8sdmY4zcKWY3xZH1M6Q8i8y580VufTwz516UPfNBQ@mail.gmail.com>

Nothing being reported by the vendor:

http://www.google.com/appsstatus#hl=en&v=status

Seems all but calendar has been spotless for the past week....

On Tue, Jul 5, 2016 at 10:53 AM, Josh Luthman <josh at imaginenetworksllc.com>
wrote:

> Looks like it's back up for both my personal and work accounts (issue
> limited to the web interface).
>
> 851 reports and climbing every time I refresh @
> http://downdetector.com/status/gmail
>
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
> On Tue, Jul 5, 2016 at 10:49 AM, Josh Luthman <josh at imaginenetworksllc.com
> >
> wrote:
>
> > Web interface is broken, downdetector sure sees activity.  This attempt
> is
> > from mobile.
> >
> > Josh Luthman
> > Office: 937-552-2340
> > Direct: 937-552-2343
> > 1100 Wayne St
> > Suite 1337
> > Troy, OH 45373
> >
>



-- 
Miano, Steven M.
http://stevenmiano.com

From hugo at slabnet.com  Tue Jul  5 15:06:53 2016
From: hugo at slabnet.com (Hugo Slabbert)
Date: Tue, 5 Jul 2016 08:06:53 -0700
Subject: Gmail down
In-Reply-To: <CAN9qwJ-Ded_157pWjp7mgVQgWVpNLjY2XEka0SDZ5g2+afG8PQ@mail.gmail.com>
References: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
 <CAN9qwJ-Ded_157pWjp7mgVQgWVpNLjY2XEka0SDZ5g2+afG8PQ@mail.gmail.com>
Message-ID: <20160705150653.GA1894@bamboo.slabnet.com>


On Tue 2016-Jul-05 10:53:34 -0400, Josh Luthman <josh at imaginenetworksllc.com> wrote:

>Looks like it's back up for both my personal and work accounts (issue
>limited to the web interface).
>
>851 reports and climbing every time I refresh @
>http://downdetector.com/status/gmail
>

No issues from Vancouver, BC.  Reaching over v6 on 2607:f8b0:400a:801::2005 
via peering at the SIX.

>
>On Tue, Jul 5, 2016 at 10:49 AM, Josh Luthman <josh at imaginenetworksllc.com>
>wrote:
>
>> Web interface is broken, downdetector sure sees activity.  This attempt is
>> from mobile.
>>
>> Josh Luthman
>> Office: 937-552-2340
>> Direct: 937-552-2343
>> 1100 Wayne St
>> Suite 1337
>> Troy, OH 45373
>>

-- 
Hugo Slabbert       | email, xmpp/jabber: hugo at slabnet.com
pgp key: B178313E   | also on Signal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160705/cbc793bc/attachment.pgp>

From john-nanog at peachfamily.net  Tue Jul  5 15:18:10 2016
From: john-nanog at peachfamily.net (John Peach)
Date: Tue, 5 Jul 2016 11:18:10 -0400
Subject: Gmail down
In-Reply-To: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
References: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
Message-ID: <20160705111810.1e21df13@jpeach-desktop.anbg.mssm.edu>

https://downforeveryoneorjustme.com/gmail.com


On Tue, 5 Jul 2016 10:49:31 -0400
Josh Luthman <josh at imaginenetworksllc.com> wrote:

> Web interface is broken, downdetector sure sees activity.  This
> attempt is from mobile.
> 
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160705/3beb3630/attachment.pgp>

From josh at imaginenetworksllc.com  Tue Jul  5 15:30:18 2016
From: josh at imaginenetworksllc.com (Josh Luthman)
Date: Tue, 5 Jul 2016 11:30:18 -0400
Subject: Gmail down
In-Reply-To: <CACkP6k=TM8sdmY4zcKWY3xZH1M6Q8i8y580VufTwz516UPfNBQ@mail.gmail.com>
References: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
 <CAN9qwJ-Ded_157pWjp7mgVQgWVpNLjY2XEka0SDZ5g2+afG8PQ@mail.gmail.com>
 <CACkP6k=TM8sdmY4zcKWY3xZH1M6Q8i8y580VufTwz516UPfNBQ@mail.gmail.com>
Message-ID: <CAN9qwJ9QguA3ngwvUaQa21pov6D05pXUuFuV3xy1sqy6BPRtEA@mail.gmail.com>

That's Google Apps.  Not Gmail.  As per the subject, it's Gmail.

http://downdetector.com/status/gmail


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Tue, Jul 5, 2016 at 11:03 AM, Steven Miano <mianosm at gmail.com> wrote:

> Nothing being reported by the vendor:
>
> http://www.google.com/appsstatus#hl=en&v=status
>
> Seems all but calendar has been spotless for the past week....
>
> On Tue, Jul 5, 2016 at 10:53 AM, Josh Luthman <josh at imaginenetworksllc.com
> >
> wrote:
>
> > Looks like it's back up for both my personal and work accounts (issue
> > limited to the web interface).
> >
> > 851 reports and climbing every time I refresh @
> > http://downdetector.com/status/gmail
> >
> >
> > Josh Luthman
> > Office: 937-552-2340
> > Direct: 937-552-2343
> > 1100 Wayne St
> > Suite 1337
> > Troy, OH 45373
> >
> > On Tue, Jul 5, 2016 at 10:49 AM, Josh Luthman <
> josh at imaginenetworksllc.com
> > >
> > wrote:
> >
> > > Web interface is broken, downdetector sure sees activity.  This attempt
> > is
> > > from mobile.
> > >
> > > Josh Luthman
> > > Office: 937-552-2340
> > > Direct: 937-552-2343
> > > 1100 Wayne St
> > > Suite 1337
> > > Troy, OH 45373
> > >
> >
>
>
>
> --
> Miano, Steven M.
> http://stevenmiano.com
>

From josh at imaginenetworksllc.com  Tue Jul  5 15:33:32 2016
From: josh at imaginenetworksllc.com (Josh Luthman)
Date: Tue, 5 Jul 2016 11:33:32 -0400
Subject: Gmail down
In-Reply-To: <20160705111810.1e21df13@jpeach-desktop.anbg.mssm.edu>
References: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
 <20160705111810.1e21df13@jpeach-desktop.anbg.mssm.edu>
Message-ID: <CAN9qwJ-03aZV9f4wBZQ7x+S=KWSWGeYrseaDj43O05w5ZKdiRg@mail.gmail.com>

I believe that only checks for an HTTP response, which would have responded
successfully.  Not relevant to the issue.


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Tue, Jul 5, 2016 at 11:18 AM, John Peach <john-nanog at peachfamily.net>
wrote:

> https://downforeveryoneorjustme.com/gmail.com
>
>
> On Tue, 5 Jul 2016 10:49:31 -0400
> Josh Luthman <josh at imaginenetworksllc.com> wrote:
>
> > Web interface is broken, downdetector sure sees activity.  This
> > attempt is from mobile.
> >
> > Josh Luthman
> > Office: 937-552-2340
> > Direct: 937-552-2343
> > 1100 Wayne St
> > Suite 1337
> > Troy, OH 45373
>
>

From mel at beckman.org  Tue Jul  5 15:37:00 2016
From: mel at beckman.org (Mel Beckman)
Date: Tue, 5 Jul 2016 15:37:00 +0000
Subject: Gmail down
In-Reply-To: <CAN9qwJ9QguA3ngwvUaQa21pov6D05pXUuFuV3xy1sqy6BPRtEA@mail.gmail.com>
References: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
 <CAN9qwJ-Ded_157pWjp7mgVQgWVpNLjY2XEka0SDZ5g2+afG8PQ@mail.gmail.com>
 <CACkP6k=TM8sdmY4zcKWY3xZH1M6Q8i8y580VufTwz516UPfNBQ@mail.gmail.com>
 <CAN9qwJ9QguA3ngwvUaQa21pov6D05pXUuFuV3xy1sqy6BPRtEA@mail.gmail.com>
Message-ID: <376ABB73-2BB4-40E5-943C-11A2475FEE0C@beckman.org>

Josh,

No, that downdetector.com page is specifically for gmail.

 -mel

> On Jul 5, 2016, at 8:30 AM, Josh Luthman <josh at imaginenetworksllc.com> wrote:
> 
> That's Google Apps.  Not Gmail.  As per the subject, it's Gmail.
> 
> http://downdetector.com/status/gmail
> 
> 
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
> 
> On Tue, Jul 5, 2016 at 11:03 AM, Steven Miano <mianosm at gmail.com> wrote:
> 
>> Nothing being reported by the vendor:
>> 
>> http://www.google.com/appsstatus#hl=en&v=status
>> 
>> Seems all but calendar has been spotless for the past week....
>> 
>> On Tue, Jul 5, 2016 at 10:53 AM, Josh Luthman <josh at imaginenetworksllc.com
>>> 
>> wrote:
>> 
>>> Looks like it's back up for both my personal and work accounts (issue
>>> limited to the web interface).
>>> 
>>> 851 reports and climbing every time I refresh @
>>> http://downdetector.com/status/gmail
>>> 
>>> 
>>> Josh Luthman
>>> Office: 937-552-2340
>>> Direct: 937-552-2343
>>> 1100 Wayne St
>>> Suite 1337
>>> Troy, OH 45373
>>> 
>>> On Tue, Jul 5, 2016 at 10:49 AM, Josh Luthman <
>> josh at imaginenetworksllc.com
>>>> 
>>> wrote:
>>> 
>>>> Web interface is broken, downdetector sure sees activity.  This attempt
>>> is
>>>> from mobile.
>>>> 
>>>> Josh Luthman
>>>> Office: 937-552-2340
>>>> Direct: 937-552-2343
>>>> 1100 Wayne St
>>>> Suite 1337
>>>> Troy, OH 45373
>>>> 
>>> 
>> 
>> 
>> 
>> --
>> Miano, Steven M.
>> http://stevenmiano.com
>> 


From josh at imaginenetworksllc.com  Tue Jul  5 15:39:20 2016
From: josh at imaginenetworksllc.com (Josh Luthman)
Date: Tue, 5 Jul 2016 11:39:20 -0400
Subject: Gmail down
In-Reply-To: <376ABB73-2BB4-40E5-943C-11A2475FEE0C@beckman.org>
References: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
 <CAN9qwJ-Ded_157pWjp7mgVQgWVpNLjY2XEka0SDZ5g2+afG8PQ@mail.gmail.com>
 <CACkP6k=TM8sdmY4zcKWY3xZH1M6Q8i8y580VufTwz516UPfNBQ@mail.gmail.com>
 <CAN9qwJ9QguA3ngwvUaQa21pov6D05pXUuFuV3xy1sqy6BPRtEA@mail.gmail.com>
 <376ABB73-2BB4-40E5-943C-11A2475FEE0C@beckman.org>
Message-ID: <CAN9qwJ_=cLePX6TFdiLf3j4cbRqQGT8fVYXgDpDh5VzAst7X7Q@mail.gmail.com>

I know.  That's what I'm saying.


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Tue, Jul 5, 2016 at 11:37 AM, Mel Beckman <mel at beckman.org> wrote:

> Josh,
>
> No, that downdetector.com page is specifically for gmail.
>
>  -mel
>
> > On Jul 5, 2016, at 8:30 AM, Josh Luthman <josh at imaginenetworksllc.com>
> wrote:
> >
> > That's Google Apps.  Not Gmail.  As per the subject, it's Gmail.
> >
> > http://downdetector.com/status/gmail
> >
> >
> > Josh Luthman
> > Office: 937-552-2340
> > Direct: 937-552-2343
> > 1100 Wayne St
> > Suite 1337
> > Troy, OH 45373
> >
> > On Tue, Jul 5, 2016 at 11:03 AM, Steven Miano <mianosm at gmail.com> wrote:
> >
> >> Nothing being reported by the vendor:
> >>
> >> http://www.google.com/appsstatus#hl=en&v=status
> >>
> >> Seems all but calendar has been spotless for the past week....
> >>
> >> On Tue, Jul 5, 2016 at 10:53 AM, Josh Luthman <
> josh at imaginenetworksllc.com
> >>>
> >> wrote:
> >>
> >>> Looks like it's back up for both my personal and work accounts (issue
> >>> limited to the web interface).
> >>>
> >>> 851 reports and climbing every time I refresh @
> >>> http://downdetector.com/status/gmail
> >>>
> >>>
> >>> Josh Luthman
> >>> Office: 937-552-2340
> >>> Direct: 937-552-2343
> >>> 1100 Wayne St
> >>> Suite 1337
> >>> Troy, OH 45373
> >>>
> >>> On Tue, Jul 5, 2016 at 10:49 AM, Josh Luthman <
> >> josh at imaginenetworksllc.com
> >>>>
> >>> wrote:
> >>>
> >>>> Web interface is broken, downdetector sure sees activity.  This
> attempt
> >>> is
> >>>> from mobile.
> >>>>
> >>>> Josh Luthman
> >>>> Office: 937-552-2340
> >>>> Direct: 937-552-2343
> >>>> 1100 Wayne St
> >>>> Suite 1337
> >>>> Troy, OH 45373
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >> Miano, Steven M.
> >> http://stevenmiano.com
> >>
>
>

From ler762 at gmail.com  Tue Jul  5 15:40:31 2016
From: ler762 at gmail.com (Lee)
Date: Tue, 5 Jul 2016 11:40:31 -0400
Subject: NAT firewall for IPv6?
In-Reply-To: <9578293AE169674F9A048B2BC9A081B401E663D00B@MUNPRDMBXA1.medline.com>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E663D00B@MUNPRDMBXA1.medline.com>
Message-ID: <CAD8GWstEJCJOkePCT7O1NDP5BcwJ44VA=Pifqveuafk2_9yMGg@mail.gmail.com>

On 7/5/16, Naslund, Steve <SNaslund at medline.com> wrote:
> Hard to know where to begin with this one, but let me take a shot at it.
>
> 1.  My top priority would be to get into that Palo Alto firewall.  Get Palo
> Alto on the phone and figure out password recovery with them.  Since you
> don?t have the password it is possible that firewall is compromised.  Do not
> be surprised if you have to jump through some hoops with Palo Alto to prove
> that you own it and what has happened.  Remember their job is to keep people
> out of your network.  They are probably also going to want you to be current
> on support.  If you have to pay to get current on support, do it.  You need
> that help right now badly.
>
> You could ask Palo Alto how to block the v6 while you are at it or even
> better set up a rules that mirror your v4 protection.   I cannot stress
> enough how big a security issue it is to not have access to your firewall
> and not know who does.
>
> 2.  There are lots of ways to shut off ipv6 but my suggestion would be to
> just secure the Palo Alto firewall,

Right.  But how long is it going to take to secure the Palo Alto firewall?
If the central Cisco Catalyst really is an IPv6 router, doing a
conf t
ipv6 access-list denyIPv6
  deny ipv6 any any

interface [whatever connects to the ISP]
 ipv6 traffic-filter denyIPv6 in
 ipv6 traffic-filter denyIPv6 out
end
would be a quick fix for the firewall not doing any ipv6 filtering.
It could also break ipv6 enabled web sites or even internal
connectivity, so it'd be better to get someone on the phone w/ Cisco
tech support and have Cisco figure out the best way to block IPv6 for
you.


>  ... to say that any legitimate service
> should have a ipv4 address is not quite true now and will definitely not be
> true in the near future.

True.  But they're in "stop the bleeding" mode and disabling ipv6 is
just a temp work-around until the firewall is fixed.

Regards,
Lee



> 3.  Just about any kind of firewall or router CPE device can block or
> firewall ipv4 and ipv6 as long as its firmware is fairly recent.  However,
> you would most likely have to replace the Palo Alto with it.  You DO NOT
> WANT THEM BOTH INLINE!  Most likely they are both configured to do ipv4 NAT
> out of the box and that will not work correctly to have them both inline
> together.  While it is possible to set up that sort of thing to work
> correctly, it?s a bad idea and pretty advanced configuration for a temporary
> network admin.  The interaction of one firewall fronting another can be very
> difficult to troubleshoot without a deep understanding of what is going on.
> Referring back to item 1, you are probably going to need to get the
> configuration of the current firewall if you seek to replace it (there will
> be rules in the Palo Alto that you would want to replicate if you are going
> to replace it).
>
> 4.  Cisco Catalyst as the router.....there could be a lot of things going on
> in there.  The Catalyst is primarily a switch with routing functionality.
> It can definitely block ipv6 if configured to do so but we would need to
> know a lot more about its current configuration to give you the best way to
> do that.  It could just be a service providers switch on your premise in
> which case you can't do much with it.  Again, much easier to accomplish Item
> 1 with Palo Alto and let your firewall do what it is supposed to do.
>
> Steven Naslund
> Chicago IL
>
>
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Edgar Carver
> Sent: Friday, July 01, 2016 9:29 PM
> To: nanog at nanog.org
> Subject: NAT firewall for IPv6?
>
> Hello NANOG community. I was directed here by our network administrator
> since she is on vacation. Luckily, I minored in Computer Science so I have
> some familiarity.
>
> We have a small satellite campus of around 170 devices that share one
> external IPv4 and IPv6 address via NAT for internet traffic. Internal
> traffic is over an MPLS.
>
> We're having problems where viruses are getting through Firefox, and we
> think it's because our Palo Alto firewall is set to bypass filtering for
> IPv6. Unfortunately, the network admin couldn't give me the password since a
> local consultant set it up, and it seems they went out of business. I need
> to think outside the box.
>
> Is there some kind of NAT-based IPv6 firewall I can setup on the router that
> can help block viruses? I figure that's the right place to start since all
> the traffic gets funneled there. We have a Cisco Catalyst as a router. Or,
> ideally, is there an easy way to turn off IPv6 completely? I really don't
> see a need for it, any legitimate service should have an IPv4 address.
>
> I'd really appreciate your advice. I plan to drive out there tomorrow, where
> I can get the exact model numbers and stuff.
>
> Regards,
> Dr. Edgar Carver
>

From A.L.M.Buxey at lboro.ac.uk  Tue Jul  5 15:40:08 2016
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Tue, 5 Jul 2016 15:40:08 +0000
Subject: NAT firewall for IPv6?
In-Reply-To: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
Message-ID: <20160705154008.GC18980@lboro.ac.uk>

Hi,


I would go through the password recovery options on the PaloAlto.

as a next gen firewall you need to ensure you are getting all the latets rulesets
and detection code through - check your subscription with them


once you've sorted out access you can look at the policies and ensure that
the IPv6 AV filtering rules match that for IPv4 - fairly easy with their interface.
(check your codebase version for feature abilities....once again, you may need to
deal with PA to ensure your codebase is current. these things get OLD quickly


as for NAT for IOV6. nope.   and turning it off ISNT the answer (yes, its an answer...just
the wrong one! ;-) )


alan

From mel at beckman.org  Tue Jul  5 15:42:09 2016
From: mel at beckman.org (Mel Beckman)
Date: Tue, 5 Jul 2016 15:42:09 +0000
Subject: Gmail down
In-Reply-To: <CAN9qwJ_=cLePX6TFdiLf3j4cbRqQGT8fVYXgDpDh5VzAst7X7Q@mail.gmail.com>
References: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
 <CAN9qwJ-Ded_157pWjp7mgVQgWVpNLjY2XEka0SDZ5g2+afG8PQ@mail.gmail.com>
 <CACkP6k=TM8sdmY4zcKWY3xZH1M6Q8i8y580VufTwz516UPfNBQ@mail.gmail.com>
 <CAN9qwJ9QguA3ngwvUaQa21pov6D05pXUuFuV3xy1sqy6BPRtEA@mail.gmail.com>
 <376ABB73-2BB4-40E5-943C-11A2475FEE0C@beckman.org>
 <CAN9qwJ_=cLePX6TFdiLf3j4cbRqQGT8fVYXgDpDh5VzAst7X7Q@mail.gmail.com>
Message-ID: <BBC976B5-CB88-47BC-A0A0-173692196CF2@beckman.org>

Sorry, I misread your post.

Ironically, I can reach Gmail through Level3, but not through Frontier or AT&T. So this may be a global routing issue.

 -mel

On Jul 5, 2016, at 8:39 AM, Josh Luthman <josh at imaginenetworksllc.com<mailto:josh at imaginenetworksllc.com>> wrote:

I know.  That's what I'm saying.


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Tue, Jul 5, 2016 at 11:37 AM, Mel Beckman <mel at beckman.org<mailto:mel at beckman.org>> wrote:
Josh,

No, that downdetector.com<http://downdetector.com/> page is specifically for gmail.

 -mel

> On Jul 5, 2016, at 8:30 AM, Josh Luthman <josh at imaginenetworksllc.com<mailto:josh at imaginenetworksllc.com>> wrote:
>
> That's Google Apps.  Not Gmail.  As per the subject, it's Gmail.
>
> http://downdetector.com/status/gmail
>
>
> Josh Luthman
> Office: 937-552-2340<tel:937-552-2340>
> Direct: 937-552-2343<tel:937-552-2343>
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
> On Tue, Jul 5, 2016 at 11:03 AM, Steven Miano <mianosm at gmail.com<mailto:mianosm at gmail.com>> wrote:
>
>> Nothing being reported by the vendor:
>>
>> http://www.google.com/appsstatus#hl=en&v=status
>>
>> Seems all but calendar has been spotless for the past week....
>>
>> On Tue, Jul 5, 2016 at 10:53 AM, Josh Luthman <josh at imaginenetworksllc.com<mailto:josh at imaginenetworksllc.com>
>>>
>> wrote:
>>
>>> Looks like it's back up for both my personal and work accounts (issue
>>> limited to the web interface).
>>>
>>> 851 reports and climbing every time I refresh @
>>> http://downdetector.com/status/gmail
>>>
>>>
>>> Josh Luthman
>>> Office: 937-552-2340<tel:937-552-2340>
>>> Direct: 937-552-2343<tel:937-552-2343>
>>> 1100 Wayne St
>>> Suite 1337
>>> Troy, OH 45373
>>>
>>> On Tue, Jul 5, 2016 at 10:49 AM, Josh Luthman <
>> josh at imaginenetworksllc.com<mailto:josh at imaginenetworksllc.com>
>>>>
>>> wrote:
>>>
>>>> Web interface is broken, downdetector sure sees activity.  This attempt
>>> is
>>>> from mobile.
>>>>
>>>> Josh Luthman
>>>> Office: 937-552-2340<tel:937-552-2340>
>>>> Direct: 937-552-2343<tel:937-552-2343>
>>>> 1100 Wayne St
>>>> Suite 1337
>>>> Troy, OH 45373
>>>>
>>>
>>
>>
>>
>> --
>> Miano, Steven M.
>> http://stevenmiano.com<http://stevenmiano.com/>
>>




From sryan at arbor.net  Tue Jul  5 15:54:14 2016
From: sryan at arbor.net (Spencer Ryan)
Date: Tue, 5 Jul 2016 11:54:14 -0400
Subject: NAT firewall for IPv6?
In-Reply-To: <20160705154008.GC18980@lboro.ac.uk>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
 <20160705154008.GC18980@lboro.ac.uk>
Message-ID: <CA+HzidS8otKFDvjiT2yRVzTDyQ0T_nv-ZWJuJ0qL8OSHFyWjhw@mail.gmail.com>

The Palo-Alto's also don't support anything but NAT64, so depending on what
you meant by the IPv6 side is sharing "one address" might not be correct.


*Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net
*Arbor Networks*
+1.734.794.5033 (d) | +1.734.846.2053 (m)
www.arbornetworks.com

On Tue, Jul 5, 2016 at 11:40 AM, <A.L.M.Buxey at lboro.ac.uk> wrote:

> Hi,
>
>
> I would go through the password recovery options on the PaloAlto.
>
> as a next gen firewall you need to ensure you are getting all the latets
> rulesets
> and detection code through - check your subscription with them
>
>
> once you've sorted out access you can look at the policies and ensure that
> the IPv6 AV filtering rules match that for IPv4 - fairly easy with their
> interface.
> (check your codebase version for feature abilities....once again, you may
> need to
> deal with PA to ensure your codebase is current. these things get OLD
> quickly
>
>
> as for NAT for IOV6. nope.   and turning it off ISNT the answer (yes, its
> an answer...just
> the wrong one! ;-) )
>
>
> alan
>

From joquendo at e-fensive.net  Tue Jul  5 15:54:18 2016
From: joquendo at e-fensive.net (J. Oquendo)
Date: Tue, 5 Jul 2016 10:54:18 -0500
Subject: Gmail down
In-Reply-To: <376ABB73-2BB4-40E5-943C-11A2475FEE0C@beckman.org>
References: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
 <CAN9qwJ-Ded_157pWjp7mgVQgWVpNLjY2XEka0SDZ5g2+afG8PQ@mail.gmail.com>
 <CACkP6k=TM8sdmY4zcKWY3xZH1M6Q8i8y580VufTwz516UPfNBQ@mail.gmail.com>
 <CAN9qwJ9QguA3ngwvUaQa21pov6D05pXUuFuV3xy1sqy6BPRtEA@mail.gmail.com>
 <376ABB73-2BB4-40E5-943C-11A2475FEE0C@beckman.org>
Message-ID: <20160705155418.GA27619@e-fensive.net>

On Tue, 05 Jul 2016, Mel Beckman wrote:

> Josh,
> 
> No, that downdetector.com page is specifically for gmail.
> 
>  -mel

Unsure about others, but I certainly trust downdetector
and others versus checking out Google's very own service
status dashboard (https://www.google.com/appsstatus#hl=en&v=status)

As an aside, as mentioned this is best reported on the
Outage mailing list versus here on NANOG. $DIETY knows
these threads can become epic length'd noise. So here is
what would have been a better bet versus the good old
'sky is falling' response.

Step 1) Gmail/Hotmail/Whatever doesn't work on your
phone

Step 2) Check it on something OTHER than your phone
where your provider may not be reliable

Step 3) Does it work on something else? If so problem
solved if not go to step 4

Step 4) Find the provider's page (if availble) and
see what others are saying. If others state it is up
for them, but down for you... It may be an issue on
YOUR network, or your providers. 

Step 5) If it is down for EVERYONE on the planet
post it to Outages amongst the other dozen entries

Step 6) Live life ;) World does not stop because
Gmail, Facebook, Twitter, even the stock markets
hiccup.

-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM

"Where ignorance is our master, there is no possibility of
real peace" - Dalai Lama

0B23 595C F07C 6092 8AEB  074B FC83 7AF5 9D8A 4463
https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463

From sryan at arbor.net  Tue Jul  5 15:57:42 2016
From: sryan at arbor.net (Spencer Ryan)
Date: Tue, 5 Jul 2016 11:57:42 -0400
Subject: Gmail down
In-Reply-To: <BBC976B5-CB88-47BC-A0A0-173692196CF2@beckman.org>
References: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
 <CAN9qwJ-Ded_157pWjp7mgVQgWVpNLjY2XEka0SDZ5g2+afG8PQ@mail.gmail.com>
 <CACkP6k=TM8sdmY4zcKWY3xZH1M6Q8i8y580VufTwz516UPfNBQ@mail.gmail.com>
 <CAN9qwJ9QguA3ngwvUaQa21pov6D05pXUuFuV3xy1sqy6BPRtEA@mail.gmail.com>
 <376ABB73-2BB4-40E5-943C-11A2475FEE0C@beckman.org>
 <CAN9qwJ_=cLePX6TFdiLf3j4cbRqQGT8fVYXgDpDh5VzAst7X7Q@mail.gmail.com>
 <BBC976B5-CB88-47BC-A0A0-173692196CF2@beckman.org>
Message-ID: <CA+HzidQ7RD7sNH3ek4FS0Nb9-ybx2tXb6bEkc6DTJ0tTk92jBg@mail.gmail.com>

We've seen issues in the past where our upstream ISP had to de-peer with
Google in the Detroit IX as the Google side seemed to be eating traffic,
sending everything via L3/Chicago usually fixed it.


*Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net
*Arbor Networks*
+1.734.794.5033 (d) | +1.734.846.2053 (m)
www.arbornetworks.com

On Tue, Jul 5, 2016 at 11:42 AM, Mel Beckman <mel at beckman.org> wrote:

> Sorry, I misread your post.
>
> Ironically, I can reach Gmail through Level3, but not through Frontier or
> AT&T. So this may be a global routing issue.
>
>  -mel
>
> On Jul 5, 2016, at 8:39 AM, Josh Luthman <josh at imaginenetworksllc.com
> <mailto:josh at imaginenetworksllc.com>> wrote:
>
> I know.  That's what I'm saying.
>
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
> On Tue, Jul 5, 2016 at 11:37 AM, Mel Beckman <mel at beckman.org<mailto:
> mel at beckman.org>> wrote:
> Josh,
>
> No, that downdetector.com<http://downdetector.com/> page is specifically
> for gmail.
>
>  -mel
>
> > On Jul 5, 2016, at 8:30 AM, Josh Luthman <josh at imaginenetworksllc.com
> <mailto:josh at imaginenetworksllc.com>> wrote:
> >
> > That's Google Apps.  Not Gmail.  As per the subject, it's Gmail.
> >
> > http://downdetector.com/status/gmail
> >
> >
> > Josh Luthman
> > Office: 937-552-2340<tel:937-552-2340>
> > Direct: 937-552-2343<tel:937-552-2343>
> > 1100 Wayne St
> > Suite 1337
> > Troy, OH 45373
> >
> > On Tue, Jul 5, 2016 at 11:03 AM, Steven Miano <mianosm at gmail.com<mailto:
> mianosm at gmail.com>> wrote:
> >
> >> Nothing being reported by the vendor:
> >>
> >> http://www.google.com/appsstatus#hl=en&v=status
> >>
> >> Seems all but calendar has been spotless for the past week....
> >>
> >> On Tue, Jul 5, 2016 at 10:53 AM, Josh Luthman <
> josh at imaginenetworksllc.com<mailto:josh at imaginenetworksllc.com>
> >>>
> >> wrote:
> >>
> >>> Looks like it's back up for both my personal and work accounts (issue
> >>> limited to the web interface).
> >>>
> >>> 851 reports and climbing every time I refresh @
> >>> http://downdetector.com/status/gmail
> >>>
> >>>
> >>> Josh Luthman
> >>> Office: 937-552-2340<tel:937-552-2340>
> >>> Direct: 937-552-2343<tel:937-552-2343>
> >>> 1100 Wayne St
> >>> Suite 1337
> >>> Troy, OH 45373
> >>>
> >>> On Tue, Jul 5, 2016 at 10:49 AM, Josh Luthman <
> >> josh at imaginenetworksllc.com<mailto:josh at imaginenetworksllc.com>
> >>>>
> >>> wrote:
> >>>
> >>>> Web interface is broken, downdetector sure sees activity.  This
> attempt
> >>> is
> >>>> from mobile.
> >>>>
> >>>> Josh Luthman
> >>>> Office: 937-552-2340<tel:937-552-2340>
> >>>> Direct: 937-552-2343<tel:937-552-2343>
> >>>> 1100 Wayne St
> >>>> Suite 1337
> >>>> Troy, OH 45373
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >> Miano, Steven M.
> >> http://stevenmiano.com<http://stevenmiano.com/>
> >>
>
>
>
>

From josh at imaginenetworksllc.com  Tue Jul  5 15:57:45 2016
From: josh at imaginenetworksllc.com (Josh Luthman)
Date: Tue, 5 Jul 2016 11:57:45 -0400
Subject: Gmail down
In-Reply-To: <20160705155418.GA27619@e-fensive.net>
References: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
 <CAN9qwJ-Ded_157pWjp7mgVQgWVpNLjY2XEka0SDZ5g2+afG8PQ@mail.gmail.com>
 <CACkP6k=TM8sdmY4zcKWY3xZH1M6Q8i8y580VufTwz516UPfNBQ@mail.gmail.com>
 <CAN9qwJ9QguA3ngwvUaQa21pov6D05pXUuFuV3xy1sqy6BPRtEA@mail.gmail.com>
 <376ABB73-2BB4-40E5-943C-11A2475FEE0C@beckman.org>
 <20160705155418.GA27619@e-fensive.net>
Message-ID: <CAN9qwJ9Dgjpn2x=pm80HCVwD2cYCxsqA12nxvDwvd+LN8ow-=w@mail.gmail.com>

You're right, I should have posted to Outages.  That was my mistake.


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Tue, Jul 5, 2016 at 11:54 AM, J. Oquendo <joquendo at e-fensive.net> wrote:

> On Tue, 05 Jul 2016, Mel Beckman wrote:
>
> > Josh,
> >
> > No, that downdetector.com page is specifically for gmail.
> >
> >  -mel
>
> Unsure about others, but I certainly trust downdetector
> and others versus checking out Google's very own service
> status dashboard (https://www.google.com/appsstatus#hl=en&v=status)
>
> As an aside, as mentioned this is best reported on the
> Outage mailing list versus here on NANOG. $DIETY knows
> these threads can become epic length'd noise. So here is
> what would have been a better bet versus the good old
> 'sky is falling' response.
>
> Step 1) Gmail/Hotmail/Whatever doesn't work on your
> phone
>
> Step 2) Check it on something OTHER than your phone
> where your provider may not be reliable
>
> Step 3) Does it work on something else? If so problem
> solved if not go to step 4
>
> Step 4) Find the provider's page (if availble) and
> see what others are saying. If others state it is up
> for them, but down for you... It may be an issue on
> YOUR network, or your providers.
>
> Step 5) If it is down for EVERYONE on the planet
> post it to Outages amongst the other dozen entries
>
> Step 6) Live life ;) World does not stop because
> Gmail, Facebook, Twitter, even the stock markets
> hiccup.
>
> --
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
> J. Oquendo
> SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM
>
> "Where ignorance is our master, there is no possibility of
> real peace" - Dalai Lama
>
> 0B23 595C F07C 6092 8AEB  074B FC83 7AF5 9D8A 4463
> https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463
>

From SNaslund at medline.com  Tue Jul  5 16:05:37 2016
From: SNaslund at medline.com (Naslund, Steve)
Date: Tue, 5 Jul 2016 16:05:37 +0000
Subject: NAT firewall for IPv6?
In-Reply-To: <CAD8GWstEJCJOkePCT7O1NDP5BcwJ44VA=Pifqveuafk2_9yMGg@mail.gmail.com>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E663D00B@MUNPRDMBXA1.medline.com>
 <CAD8GWstEJCJOkePCT7O1NDP5BcwJ44VA=Pifqveuafk2_9yMGg@mail.gmail.com>
Message-ID: <9578293AE169674F9A048B2BC9A081B401E663D204@MUNPRDMBXA1.medline.com>

Did you get the impression that this person asking for help was going to be able to set that up?  I didn't (if he was he would probably already know what an ACL is).  I do not know if the Catalyst he is looking at is his or his service providers edge devices (or maybe the consultants didn't give them access to that either),  I don't know that that Catalyst is the primary router for their network (could be an L2 switch behind the firewall).  I also doubt the problem stems from ipv6 as much as it comes from having an out of control firewall. Given what I am hearing about this network I am kind of doubting that it is really ipv6 enabled in any case so your fix prevents ipv6 traffic that is probably not even being routed in the first place.  In my opinion not having control of your own firewall is the five alarm emergency in that network right now.

If the network is ipv6 enabled, blocking all ipv6 traffic at that router is probably not a good idea without knowing more.  If it is not ipv6 enabled then it will have no effect on the reported issue (malware).  


Steven Naslund
Chicago IL


>Right.  But how long is it going to take to secure the Palo Alto firewall?
>If the central Cisco Catalyst really is an IPv6 router, doing a conf t
>ipv6 access-list denyIPv6
>  deny ipv6 any any

>interface [whatever connects to the ISP]
> ipv6 traffic-filter denyIPv6 in
> ipv6 traffic-filter denyIPv6 out
>end
>would be a quick fix for the firewall not doing any ipv6 filtering.
>It could also break ipv6 enabled web sites or even internal connectivity, so it'd be better to get someone on the phone w/ Cisco tech support and have Cisco figure out the best way to block IPv6 for you.

>True.  But they're in "stop the bleeding" mode and disabling ipv6 is just a temp work-around until the firewall is fixed.



From Valdis.Kletnieks at vt.edu  Tue Jul  5 16:18:12 2016
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 05 Jul 2016 12:18:12 -0400
Subject: NAT firewall for IPv6?
In-Reply-To: <CA+HzidS8otKFDvjiT2yRVzTDyQ0T_nv-ZWJuJ0qL8OSHFyWjhw@mail.gmail.com>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
 <20160705154008.GC18980@lboro.ac.uk>
 <CA+HzidS8otKFDvjiT2yRVzTDyQ0T_nv-ZWJuJ0qL8OSHFyWjhw@mail.gmail.com>
Message-ID: <3197.1467735492@turing-police.cc.vt.edu>

On Tue, 05 Jul 2016 11:54:14 -0400, Spencer Ryan said:
> The Palo-Alto's also don't support anything but NAT64,

They don't support proper dual-stack??  Or NAT64 is the only NAT flavor
they support on the v6 side?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160705/7c96887c/attachment.pgp>

From sryan at arbor.net  Tue Jul  5 16:25:15 2016
From: sryan at arbor.net (Spencer Ryan)
Date: Tue, 5 Jul 2016 12:25:15 -0400
Subject: NAT firewall for IPv6?
In-Reply-To: <3197.1467735492@turing-police.cc.vt.edu>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
 <20160705154008.GC18980@lboro.ac.uk>
 <CA+HzidS8otKFDvjiT2yRVzTDyQ0T_nv-ZWJuJ0qL8OSHFyWjhw@mail.gmail.com>
 <3197.1467735492@turing-police.cc.vt.edu>
Message-ID: <CA+HzidSErfCrzNJmFKPTW_agxnDOPcMKdrgKCCb9n2Lzp41zsg@mail.gmail.com>

NAT64 is the only type of IPv6 NAT they support.


*Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net
*Arbor Networks*
+1.734.794.5033 (d) | +1.734.846.2053 (m)
www.arbornetworks.com

On Tue, Jul 5, 2016 at 12:18 PM, <Valdis.Kletnieks at vt.edu> wrote:

> On Tue, 05 Jul 2016 11:54:14 -0400, Spencer Ryan said:
> > The Palo-Alto's also don't support anything but NAT64,
>
> They don't support proper dual-stack??  Or NAT64 is the only NAT flavor
> they support on the v6 side?
>

From drjedgar at outlook.com  Tue Jul  5 16:02:53 2016
From: drjedgar at outlook.com (J Edgar Carver)
Date: Tue, 5 Jul 2016 16:02:53 +0000
Subject: NAT firewall for IPv6?
Message-ID: <VI1PR0601MB21251176B5636073756BFAF7D5390@VI1PR0601MB2125.eurprd06.prod.outlook.com>

On Fri, 1 Jul 2016 21:28:54 -0500
Edgar Carver <dredgarcarver at gmail.com> wrote:

> Hello NANOG community. I was directed here by our network administrator
> since she is on vacation. Luckily, I minored in Computer Science so I have
> some familiarity.

Luckily!

> router. Or, ideally, is there an easy way to turn off IPv6 completely? I
> really don't see a need for it, any legitimate service should have an IPv4
> address.

Obvious troll is obvious after we just spent a week on this ...


From beecher at beecher.cc  Tue Jul  5 14:47:44 2016
From: beecher at beecher.cc (Tom Beecher)
Date: Tue, 5 Jul 2016 10:47:44 -0400
Subject: NAT firewall for IPv6?
In-Reply-To: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
Message-ID: <CAL9Qcx4pKVLZ0kBW8Ar1jsQf74c+6hOHrSu5xrsesU7immgNjw@mail.gmail.com>

Not to belabor the point, because it will likely be made frequently in
responses, but every legitimate service _should_ have both IPv4 and IPv6
addresses.

Get Palo Alto on the horn, and get access to that box. Get it configured
properly.

I won't hammer you since you're just trying to solve a problem, but v6 is
not a second class citizen. You must consider v4 and v6 for these types of
issues, and making one or the other 'go away' is simply collecting some
tech debt that you'll have to eventually pay off.

On Friday, July 1, 2016, Edgar Carver <dredgarcarver at gmail.com> wrote:

> Hello NANOG community. I was directed here by our network administrator
> since she is on vacation. Luckily, I minored in Computer Science so I have
> some familiarity.
>
> We have a small satellite campus of around 170 devices that share one
> external IPv4 and IPv6 address via NAT for internet traffic. Internal
> traffic is over an MPLS.
>
> We're having problems where viruses are getting through Firefox, and we
> think it's because our Palo Alto firewall is set to bypass filtering for
> IPv6. Unfortunately, the network admin couldn't give me the password since
> a local consultant set it up, and it seems they went out of business. I
> need to think outside the box.
>
> Is there some kind of NAT-based IPv6 firewall I can setup on the router
> that can help block viruses? I figure that's the right place to start since
> all the traffic gets funneled there. We have a Cisco Catalyst as a
> router. Or, ideally, is there an easy way to turn off IPv6 completely? I
> really don't see a need for it, any legitimate service should have an IPv4
> address.
>
> I'd really appreciate your advice. I plan to drive out there tomorrow,
> where I can get the exact model numbers and stuff.
>
> Regards,
> Dr. Edgar Carver
>

From mlfreita at mtu.edu  Tue Jul  5 15:41:19 2016
From: mlfreita at mtu.edu (Matt Freitag)
Date: Tue, 5 Jul 2016 11:41:19 -0400
Subject: Gmail down
In-Reply-To: <CAN9qwJ-03aZV9f4wBZQ7x+S=KWSWGeYrseaDj43O05w5ZKdiRg@mail.gmail.com>
References: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
 <20160705111810.1e21df13@jpeach-desktop.anbg.mssm.edu>
 <CAN9qwJ-03aZV9f4wBZQ7x+S=KWSWGeYrseaDj43O05w5ZKdiRg@mail.gmail.com>
Message-ID: <CAJWk1pRqC2Ffv5m3vHY6Ust3ckrsx3uH4o+LC1GcshwMN=0-Fw@mail.gmail.com>

All good in Houghton, MI
[image: Inline image 1]

Matt Freitag
Network Engineer I
Information Technology
Michigan Technological University
(906) 487-3696 <%28906%29%20487-3696>
https://www.mtu.edu/
https://www.it.mtu.edu/

On Tue, Jul 5, 2016 at 11:33 AM, Josh Luthman <josh at imaginenetworksllc.com>
wrote:

> I believe that only checks for an HTTP response, which would have responded
> successfully.  Not relevant to the issue.
>
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
> On Tue, Jul 5, 2016 at 11:18 AM, John Peach <john-nanog at peachfamily.net>
> wrote:
>
> > https://downforeveryoneorjustme.com/gmail.com
> >
> >
> > On Tue, 5 Jul 2016 10:49:31 -0400
> > Josh Luthman <josh at imaginenetworksllc.com> wrote:
> >
> > > Web interface is broken, downdetector sure sees activity.  This
> > > attempt is from mobile.
> > >
> > > Josh Luthman
> > > Office: 937-552-2340
> > > Direct: 937-552-2343
> > > 1100 Wayne St
> > > Suite 1337
> > > Troy, OH 45373
> >
> >
>

From w3yni1 at gmail.com  Tue Jul  5 14:55:08 2016
From: w3yni1 at gmail.com (Charles Mills)
Date: Tue, 5 Jul 2016 10:55:08 -0400
Subject: Gmail down
In-Reply-To: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
References: <CAN9qwJ8FA7uV_4xkkaaS+wUWrBEkEf35=ZDDd8ZjBx7Yj9u20g@mail.gmail.com>
Message-ID: <CAOF0KO8BFtQ_9T0JKd5ogojeq1i5pN6jESKCKPKU7nVNYokTLg@mail.gmail.com>

saw it down as well.   came back for me in < 5 minutes.

On Tue, Jul 5, 2016 at 10:49 AM, Josh Luthman <josh at imaginenetworksllc.com>
wrote:

> Web interface is broken, downdetector sure sees activity.  This attempt is
> from mobile.
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>

From ler762 at gmail.com  Tue Jul  5 17:31:48 2016
From: ler762 at gmail.com (Lee)
Date: Tue, 5 Jul 2016 13:31:48 -0400
Subject: NAT firewall for IPv6?
In-Reply-To: <9578293AE169674F9A048B2BC9A081B401E663D204@MUNPRDMBXA1.medline.com>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E663D00B@MUNPRDMBXA1.medline.com>
 <CAD8GWstEJCJOkePCT7O1NDP5BcwJ44VA=Pifqveuafk2_9yMGg@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E663D204@MUNPRDMBXA1.medline.com>
Message-ID: <CAD8GWstesmdZ5jJWLLzsBztE_L70AarYV=f4_AqZy-P0DRx0Kw@mail.gmail.com>

On 7/5/16, Naslund, Steve <SNaslund at medline.com> wrote:
> Did you get the impression that this person asking for help was going to be
> able to set that up?

Yes, I think the OP could create & apply the acl.  Which is why I said
it could break their network & suggested they get Cisco tech support
on the phone to figure out how to safely turn off IPv6.

I'm also giving them the benefit of the doubt that IPv6 really is the
malware infection vector.

>  I didn't (if he was he would probably already know
> what an ACL is).  I do not know if the Catalyst he is looking at is his or
> his service providers edge devices (or maybe the consultants didn't give
> them access to that either),  I don't know that that Catalyst is the primary
> router for their network (could be an L2 switch behind the firewall).  I
> also doubt the problem stems from ipv6 as much as it comes from having an
> out of control firewall. Given what I am hearing about this network I am
> kind of doubting that it is really ipv6 enabled in any case so your fix
> prevents ipv6 traffic that is probably not even being routed in the first
> place.  In my opinion not having control of your own firewall is the five
> alarm emergency in that network right now.

Maybe I wasn't clear that the call to Cisco tech support should be a
parallel effort?

> If the network is ipv6 enabled, blocking all ipv6 traffic at that router is
> probably not a good idea without knowing more.

Which is why I suggested getting Cisco tech support involved.  A
mailing list is not where they should be going for help right now.

Best Regards,
Lee


> ...  If it is not ipv6 enabled
> then it will have no effect on the reported issue (malware).
>
>
> Steven Naslund
> Chicago IL
>
>
>>Right.  But how long is it going to take to secure the Palo Alto firewall?
>>If the central Cisco Catalyst really is an IPv6 router, doing a conf t
>>ipv6 access-list denyIPv6
>>  deny ipv6 any any
>
>>interface [whatever connects to the ISP]
>> ipv6 traffic-filter denyIPv6 in
>> ipv6 traffic-filter denyIPv6 out
>>end
>>would be a quick fix for the firewall not doing any ipv6 filtering.
>>It could also break ipv6 enabled web sites or even internal connectivity,
>> so it'd be better to get someone on the phone w/ Cisco tech support and
>> have Cisco figure out the best way to block IPv6 for you.
>
>>True.  But they're in "stop the bleeding" mode and disabling ipv6 is just a
>> temp work-around until the firewall is fixed.
>
>
>

From baldur.norddahl at gmail.com  Tue Jul  5 19:22:15 2016
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Tue, 5 Jul 2016 21:22:15 +0200
Subject: NAT firewall for IPv6?
In-Reply-To: <CAD8GWstEJCJOkePCT7O1NDP5BcwJ44VA=Pifqveuafk2_9yMGg@mail.gmail.com>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E663D00B@MUNPRDMBXA1.medline.com>
 <CAD8GWstEJCJOkePCT7O1NDP5BcwJ44VA=Pifqveuafk2_9yMGg@mail.gmail.com>
Message-ID: <CAPkb-7A3CySqybHo8+gbaz0Y_s20TtKTJuMaXds5afY716vTZA@mail.gmail.com>

On 5 July 2016 at 17:40, Lee <ler762 at gmail.com> wrote:

>
> Right.  But how long is it going to take to secure the Palo Alto firewall?
> If the central Cisco Catalyst really is an IPv6 router, doing a
> conf t
> ipv6 access-list denyIPv6
>   deny ipv6 any any
>
> interface [whatever connects to the ISP]
>  ipv6 traffic-filter denyIPv6 in
>  ipv6 traffic-filter denyIPv6 out
> end
> would be a quick fix for the firewall not doing any ipv6 filtering.
>

Nope, that is not going to stop his IPv6 address from appearing, which I
will bet you good money is in the range of fe80::/64.

From A.L.M.Buxey at lboro.ac.uk  Tue Jul  5 19:44:07 2016
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Tue, 5 Jul 2016 19:44:07 +0000
Subject: NAT firewall for IPv6?
In-Reply-To: <3197.1467735492@turing-police.cc.vt.edu>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
 <20160705154008.GC18980@lboro.ac.uk>
 <CA+HzidS8otKFDvjiT2yRVzTDyQ0T_nv-ZWJuJ0qL8OSHFyWjhw@mail.gmail.com>
 <3197.1467735492@turing-police.cc.vt.edu>
Message-ID: <20160705194407.GD19487@lboro.ac.uk>

Hi,

> > The Palo-Alto's also don't support anything but NAT64,
> 
> They don't support proper dual-stack??  Or NAT64 is the only NAT flavor

of course they support native IPv6 ...or IPv4 with IPv6 in dual-stack.

i believe the comment was related to the 6/4 xlat stuff - ie just NAT64 and not 464XLAT etc - 
I've not looked into that myself as we do dual stack

alan

From A.L.M.Buxey at lboro.ac.uk  Tue Jul  5 19:45:38 2016
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Tue, 5 Jul 2016 19:45:38 +0000
Subject: NAT firewall for IPv6?
In-Reply-To: <CAD8GWstEJCJOkePCT7O1NDP5BcwJ44VA=Pifqveuafk2_9yMGg@mail.gmail.com>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E663D00B@MUNPRDMBXA1.medline.com>
 <CAD8GWstEJCJOkePCT7O1NDP5BcwJ44VA=Pifqveuafk2_9yMGg@mail.gmail.com>
Message-ID: <20160705194538.GE19487@lboro.ac.uk>

Hi,

> Right.  But how long is it going to take to secure the Palo Alto firewall?

around 5 minutes?

recover password, restart, log in, fix rules.

https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Reset-the-Administrator-Password/ta-p/57581


obviously the firewall is also blocking google access! ;-)

alan

From octalnanog at alvarezp.org  Tue Jul  5 19:47:36 2016
From: octalnanog at alvarezp.org (Octavio Alvarez)
Date: Tue, 5 Jul 2016 12:47:36 -0700
Subject: NAT firewall for IPv6?
In-Reply-To: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
Message-ID: <577C0ED8.60706@alvarezp.org>

On 07/01/2016 07:28 PM, Edgar Carver wrote:
> Is there some kind of NAT-based IPv6 firewall I can setup on the router
> that can help block viruses?

You need layer-7 firewalls for this. NAT-based "firewalls"
(pseudo-firewalls, really) are layer-4 only. Those will not help you
block typical viruses, as people will usually get infected from
connecting to a compromised Website, or from an e-mail attachments. And
even more, if connections are encrypted, an L7 firewall will not be able
to do anything (whether IPv4 or v6) unless... better not open a can of
worms.

They will just help you block *some* attack vectors, though: those that
rely on starting connections to your hosts from the outside.

My guess is that, with regard to e-mail attachments and compromised
Websites, IPv4 hosts are still attacked more than IPv6 ones, so, even if
you turn off IPv6 you will still get attacked through IPv4.

Everything else has been already said by others: fixing the Palo Alto is
still your best bet.

Good luck!

From baldur.norddahl at gmail.com  Tue Jul  5 20:09:11 2016
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Tue, 5 Jul 2016 22:09:11 +0200
Subject: NAT firewall for IPv6?
In-Reply-To: <577C0ED8.60706@alvarezp.org>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
 <577C0ED8.60706@alvarezp.org>
Message-ID: <CAPkb-7CCJ_6LT=MLrPvF1n6-2CA_Ei7qw2BOhsGDweTeCr5DrA@mail.gmail.com>

On 5 July 2016 at 21:47, Octavio Alvarez <octalnanog at alvarezp.org> wrote:

> Everything else has been already said by others: fixing the Palo Alto is
> still your best bet.
>


No while that is also needed, it is very unlikely to fix his issue. The
issue at hand is that some of their computers have become virus infected.
The fix for that is to upgrade the virus scanner and making sure that all
software upgrades are done.

Someone comes to you and says his Firefox is getting infected through IPv6.
If your support is worth anything, you will not take that at face value and
bill him for a ton work related to IPv6. No, you will go find out what the
real issue is and solve that. The only thing we know right now is that he
is confused.

Regards,

Baldur

From dovid at telecurve.com  Tue Jul  5 20:31:37 2016
From: dovid at telecurve.com (Dovid Bender)
Date: Tue, 5 Jul 2016 16:31:37 -0400
Subject: NAT firewall for IPv6?
In-Reply-To: <9578293AE169674F9A048B2BC9A081B401E663D03D@MUNPRDMBXA1.medline.com>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E663D03D@MUNPRDMBXA1.medline.com>
Message-ID: <CAM3TTh3RAcLYrQSfWycamXf3wvzbi-9S1m8Rx9Xd-rV39B_yow@mail.gmail.com>

You may want to look into a new product by Ixia
https://www.ixiacom.com/products/threatarmor (seems their site is under
maint atm).


On Tue, Jul 5, 2016 at 10:31 AM, Naslund, Steve <SNaslund at medline.com>
wrote:

> On another note, using a firewall to stop viruses is probably not going to
> work in general (unless the firewall has some additional malware detection
> engine).
>
> Here is the issue in a nutshell.  A firewall primarily controls where
> people can connect to and from on a network.  The problem with that is that
> a lot of malware is received from sites that your users intended to go to.
> People click on links without knowing where they go and people go to less
> than reputable web sites (or reputable sites that we recently
> compromised).  If you, by default, allow your users to access the Internet
> with a browser they are vulnerable to malware.  Even with malware detection
> capability you are still vulnerable to signatures and attacks that are not
> yet able to be detected.
>
> Even if filtering was enabled on your Palo Alto for ipv6 it would not help
> at this point because you have no idea what signatures it is using to
> filter with and when the last time those were updated  I doubt your v4
> filtering is of much use either at this point.  URL filtering is largely a
> big game of whack a mole that you will lose eventually.  Malware filtering
> is based on one or both of the following methods.
>
>         1.  You filter URLs known to be bad players (you are vulnerable
> until your protection vendor realizes they are bad players).
>
>         2.  You filter based on adaptive detection of code that looks
> suspicious.  This is a bit better but still vulnerable because the bad guys
> are always innovating to pass through these devices.
>
> My recommendation would be network malware detection (possibly through a
> firewall add-on) as well as good virus/malware detection on the client
> computers.  Sometimes the malware is easier to detect at the client because
> it reveals itself by trying to access unauthorized memory, processes, or
> storage.
>
> Steven Naslund
> Chicago IL
>
>
>
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Edgar Carver
> Sent: Friday, July 01, 2016 9:29 PM
> To: nanog at nanog.org
> Subject: NAT firewall for IPv6?
>
> Hello NANOG community. I was directed here by our network administrator
> since she is on vacation. Luckily, I minored in Computer Science so I have
> some familiarity.
>
> We have a small satellite campus of around 170 devices that share one
> external IPv4 and IPv6 address via NAT for internet traffic. Internal
> traffic is over an MPLS.
>
> We're having problems where viruses are getting through Firefox, and we
> think it's because our Palo Alto firewall is set to bypass filtering for
> IPv6. Unfortunately, the network admin couldn't give me the password since
> a local consultant set it up, and it seems they went out of business. I
> need to think outside the box.
>
> Is there some kind of NAT-based IPv6 firewall I can setup on the router
> that can help block viruses? I figure that's the right place to start since
> all the traffic gets funneled there. We have a Cisco Catalyst as a router.
> Or, ideally, is there an easy way to turn off IPv6 completely? I really
> don't see a need for it, any legitimate service should have an IPv4 address.
>
> I'd really appreciate your advice. I plan to drive out there tomorrow,
> where I can get the exact model numbers and stuff.
>
> Regards,
> Dr. Edgar Carver
>

From SNaslund at medline.com  Tue Jul  5 20:41:07 2016
From: SNaslund at medline.com (Naslund, Steve)
Date: Tue, 5 Jul 2016 20:41:07 +0000
Subject: NAT firewall for IPv6?
In-Reply-To: <CAPkb-7CCJ_6LT=MLrPvF1n6-2CA_Ei7qw2BOhsGDweTeCr5DrA@mail.gmail.com>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
 <577C0ED8.60706@alvarezp.org>
 <CAPkb-7CCJ_6LT=MLrPvF1n6-2CA_Ei7qw2BOhsGDweTeCr5DrA@mail.gmail.com>
Message-ID: <9578293AE169674F9A048B2BC9A081B401E663D72E@MUNPRDMBXA1.medline.com>

It is all about defense in depth.  The engineers here are speaking to the network pieces (the second N in NANOG is network, right :) and we have told this person that it is unlikely that v6 in the only vector and I myself talked about malware handling on the clients themselves.  From a network engineering perspective many of us agreed that the biggest single threat to his network was a firewall in an unknown state with an unknown administrator password that could be owned by anyone on earth at this point.  That single piece threatens the entire network as a whole and is a ticking time bomb ready to blow his entire LAN off the Internet if it fails.  

He probably does not own the entire environment himself, he is filling in for a vacationing network engineer.  So he is working on the network piece and is probably not responsible for the anti-malware software on the clients (if anyone is, see below).

Our "support" as you call it was a response to this person questions about blocking v6 as an attack vector in the first place.  We answered his question but then told him that was unlikely to be the problem and what he should do about taking back his firewall, securing v6 via the firewall, and handling the malware at the client.  Seems solid advise to me so far.

BTW we did not bill him for anything.  He got a lot of free advice from a lot of people he could not even begin to afford to employ, so not a bad deal for him.  You also have to understand that this gentleman seems to be in an educational environment which usually means lots of clients he does not have control over so having some kind of network based malware control is helpful.  Clients in this type of environment have to defend themselves from each other and he will likely have stuff brought in from the outside.  Good malware detection in the network can help identify clients that contain malware and are a threat to other devices.  Fancier network gear/IDS/IDP would actually remove offending clients from the network or at least segments them into an isolation area.

Let me re-iterate:

	1. 	Take back ownership of your firewall and bring it up to date including new malware signatures.  If you don't have current support, get it...........directly so if your consultant bails you are not dead meat.  This will ensure that the outside world will not own or control stuff inside your network while you put the fires out.  At the very least it can help malware infected machines from phoning home to their command and control servers which sometimes prevents a lot of damage.
	2.	Make your v6 rules mirror at least the security level of your v4 rules.  Passing v6 unchallenged is unacceptable.  If your firewall won't do it replace it with one that will.
	3.	Ensure all clients under your control have current anti-virus/anti-malware detection.  Clients have to defend themselves from threats internal to the firewall as well as ones outside.  Don't be hard on the outside with a soft chewy center.
	4.  	Never, ever accept anything less than full administrative control passwords and accounts from your consultants, before you give them final payment.  I actually prefer to lock them out when they complete an install until I need them to help with something.  This prevents them from holding you hostage or one of their "postal" employees from wiping you out as well as preventing them from using your network for experimentation without you knowing it.  It is an important part of change control to ensure that outsiders cannot modify your configuration without contacting you first.  We usually give our consultants highly logged VPN accounts that we can disable or enable as needed.

Steven Naslund
Chicago IL



>>No while that is also needed, it is very unlikely to fix his issue. The issue at hand is that some of their computers have become virus infected.
>>The fix for that is to upgrade the virus scanner and making sure that all software upgrades are done.

>>Someone comes to you and says his Firefox is getting infected through IPv6.
>>If your support is worth anything, you will not take that at face value and bill him for a ton work related to IPv6. No, you will go find out what the real issue is and solve that. The only thing we know right now is that he is >>confused.
>>
>>Regards,
>>
>>Baldur

From ryan at finnesey.com  Tue Jul  5 21:30:53 2016
From: ryan at finnesey.com (Ryan Finnesey)
Date: Tue, 5 Jul 2016 21:30:53 +0000
Subject: Office 365
Message-ID: <BLUPR05MB59516C752E9E946FD8D4779B4390@BLUPR05MB595.namprd05.prod.outlook.com>

I was hoping to touch base with providers that are offering office 365 or would like to offer office 365.  Please ping me off list I have a few questions.

Cheers
Ryan


From madsushi at gmail.com  Tue Jul  5 22:24:44 2016
From: madsushi at gmail.com (Chase Christian)
Date: Tue, 5 Jul 2016 15:24:44 -0700
Subject: NAT firewall for IPv6?
In-Reply-To: <9578293AE169674F9A048B2BC9A081B401E663D72E@MUNPRDMBXA1.medline.com>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
 <577C0ED8.60706@alvarezp.org>
 <CAPkb-7CCJ_6LT=MLrPvF1n6-2CA_Ei7qw2BOhsGDweTeCr5DrA@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E663D72E@MUNPRDMBXA1.medline.com>
Message-ID: <CAPX=P3ttYCG6Nsm40JZ=7QHXxQGyE57t-E6p2HqXrpiiE-NJ8g@mail.gmail.com>

The original email was not a serious question, but a joke:

https://twitter.com/SwiftOnSecurity/status/749059605360062464
https://twitter.com/SwiftOnSecurity/status/749062835687174144
https://twitter.com/SwiftOnSecurity/status/749068172460847105



On Tue, Jul 5, 2016 at 1:41 PM, Naslund, Steve <SNaslund at medline.com> wrote:

> It is all about defense in depth.  The engineers here are speaking to the
> network pieces (the second N in NANOG is network, right :) and we have told
> this person that it is unlikely that v6 in the only vector and I myself
> talked about malware handling on the clients themselves.  From a network
> engineering perspective many of us agreed that the biggest single threat to
> his network was a firewall in an unknown state with an unknown
> administrator password that could be owned by anyone on earth at this
> point.  That single piece threatens the entire network as a whole and is a
> ticking time bomb ready to blow his entire LAN off the Internet if it fails.
>
> He probably does not own the entire environment himself, he is filling in
> for a vacationing network engineer.  So he is working on the network piece
> and is probably not responsible for the anti-malware software on the
> clients (if anyone is, see below).
>
> Our "support" as you call it was a response to this person questions about
> blocking v6 as an attack vector in the first place.  We answered his
> question but then told him that was unlikely to be the problem and what he
> should do about taking back his firewall, securing v6 via the firewall, and
> handling the malware at the client.  Seems solid advise to me so far.
>
> BTW we did not bill him for anything.  He got a lot of free advice from a
> lot of people he could not even begin to afford to employ, so not a bad
> deal for him.  You also have to understand that this gentleman seems to be
> in an educational environment which usually means lots of clients he does
> not have control over so having some kind of network based malware control
> is helpful.  Clients in this type of environment have to defend themselves
> from each other and he will likely have stuff brought in from the outside.
> Good malware detection in the network can help identify clients that
> contain malware and are a threat to other devices.  Fancier network
> gear/IDS/IDP would actually remove offending clients from the network or at
> least segments them into an isolation area.
>
> Let me re-iterate:
>
>         1.      Take back ownership of your firewall and bring it up to
> date including new malware signatures.  If you don't have current support,
> get it...........directly so if your consultant bails you are not dead
> meat.  This will ensure that the outside world will not own or control
> stuff inside your network while you put the fires out.  At the very least
> it can help malware infected machines from phoning home to their command
> and control servers which sometimes prevents a lot of damage.
>         2.      Make your v6 rules mirror at least the security level of
> your v4 rules.  Passing v6 unchallenged is unacceptable.  If your firewall
> won't do it replace it with one that will.
>         3.      Ensure all clients under your control have current
> anti-virus/anti-malware detection.  Clients have to defend themselves from
> threats internal to the firewall as well as ones outside.  Don't be hard on
> the outside with a soft chewy center.
>         4.      Never, ever accept anything less than full administrative
> control passwords and accounts from your consultants, before you give them
> final payment.  I actually prefer to lock them out when they complete an
> install until I need them to help with something.  This prevents them from
> holding you hostage or one of their "postal" employees from wiping you out
> as well as preventing them from using your network for experimentation
> without you knowing it.  It is an important part of change control to
> ensure that outsiders cannot modify your configuration without contacting
> you first.  We usually give our consultants highly logged VPN accounts that
> we can disable or enable as needed.
>
> Steven Naslund
> Chicago IL
>
>
>
> >>No while that is also needed, it is very unlikely to fix his issue. The
> issue at hand is that some of their computers have become virus infected.
> >>The fix for that is to upgrade the virus scanner and making sure that
> all software upgrades are done.
>
> >>Someone comes to you and says his Firefox is getting infected through
> IPv6.
> >>If your support is worth anything, you will not take that at face value
> and bill him for a ton work related to IPv6. No, you will go find out what
> the real issue is and solve that. The only thing we know right now is that
> he is >>confused.
> >>
> >>Regards,
> >>
> >>Baldur
>

From sethm at rollernet.us  Tue Jul  5 22:39:14 2016
From: sethm at rollernet.us (Seth Mattinen)
Date: Tue, 5 Jul 2016 15:39:14 -0700
Subject: NAT firewall for IPv6?
In-Reply-To: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
Message-ID: <1889bab6-bf5c-5c76-1626-51b1fb91edd2@rollernet.us>

On 7/1/16 19:28, Edgar Carver wrote:
> Hello NANOG community. I was directed here by our network administrator
> since she is on vacation. Luckily, I minored in Computer Science so I have
> some familiarity.
>

This is not legit, ya'll are being trolled.

~Seth

From surfer at mauigateway.com  Tue Jul  5 22:49:02 2016
From: surfer at mauigateway.com (Scott Weeks)
Date: Tue, 5 Jul 2016 15:49:02 -0700
Subject: NAT firewall for IPv6?
Message-ID: <20160705154902.761D3792@m0086238.ppops.net>



--- sethm at rollernet.us wrote:
From: Seth Mattinen <sethm at rollernet.us>

On 7/1/16 19:28, Edgar Carver wrote:
> Hello NANOG community. I was directed here 
> by our network administrator since she is 
> on vacation. Luckily, I minored in Computer 
> Science so I have some familiarity.


:: This is not legit, ya'll are being trolled.
--------------------------------------------


Luckily, I can't imagine having such a sh!++y
life that this is seen as fun.  

Apparently, the high school kids got tired of 
ordering pizza to the next door neighbors 
house and watching them get mad.

scott



From larrysheldon at cox.net  Tue Jul  5 22:51:07 2016
From: larrysheldon at cox.net (Larry Sheldon)
Date: Tue, 5 Jul 2016 17:51:07 -0500
Subject: NAT firewall for IPv6?
In-Reply-To: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
Message-ID: <97862a73-84a7-bdba-caac-01f430734a8a@cox.net>

My how the world has changed!

On 7/1/2016 21:28, Edgar Carver wrote:
> Hello NANOG community. I was directed here by our network administrator
> since she is on vacation.

I am Old School, I guess.  In my day Step One would be "Fire the 
administrator."  The job is by nature a 24 X 7 X 52 job and "On Call" 
the rest of the time.  "Vacation" is never a reason to leave your 
assignment insecure.

"NAT-based firewall"?  Really?

How long has the consultant been out of business?

Luckily, I minored in Computer Science so I have
> some familiarity.
>
> We have a small satellite campus of around 170 devices that share one
> external IPv4 and IPv6 address via NAT for internet traffic. Internal
> traffic is over an MPLS.
>
> We're having problems where viruses are getting through Firefox, and we
> think it's because our Palo Alto firewall is set to bypass filtering for
> IPv6. Unfortunately, the network admin couldn't give me the password since
> a local consultant set it up, and it seems they went out of business. I
> need to think outside the box.
>
> Is there some kind of NAT-based IPv6 firewall I can setup on the router
> that can help block viruses? I figure that's the right place to start since
> all the traffic gets funneled there. We have a Cisco Catalyst as a
> router. Or, ideally, is there an easy way to turn off IPv6 completely? I
> really don't see a need for it, any legitimate service should have an IPv4
> address.
>
> I'd really appreciate your advice. I plan to drive out there tomorrow,
> where I can get the exact model numbers and stuff.
>
> Regards,
> Dr. Edgar Carver
>

-- 
"Everybody is a genius.  But if you judge a fish by
its ability to climb a tree, it will live its whole
life believing that it is stupid."

--Albert Einstein

 From Larry's Cox account.

From larrysheldon at cox.net  Tue Jul  5 22:55:06 2016
From: larrysheldon at cox.net (Larry Sheldon)
Date: Tue, 5 Jul 2016 17:55:06 -0500
Subject: NAT firewall for IPv6?
In-Reply-To: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
Message-ID: <d920eb79-b9d5-7969-7473-65a0fd6d77cf@cox.net>

My how the world has changed!

On 7/1/2016 21:28, Edgar Carver wrote:
> Hello NANOG community. I was directed here by our network administrator
> since she is on vacation.

I am Old School, I guess.  In my day Step One would be "Fire the 
administrator."  The job is by nature a 24 X 7 X 52 job and "On Call" 
the rest of the time.  "Vacation" is never a reason to leave your 
assignment insecure.

"NAT-based firewall"?  Really?

How long has the consultant been out of business?

Luckily, I minored in Computer Science so I have
> some familiarity.

I have no idea how I fat-fingered a "send" at this point/

I started to write that you have an emergency on your hands and you need 
to focus your attention of finding a person or firm that can take charge 
and fix problems you don't even know about yet.

A "Dear Abby" approach is going do way more harm than good.

-- 
"Everybody is a genius.  But if you judge a fish by
its ability to climb a tree, it will live its whole
life believing that it is stupid."

--Albert Einstein

  From Larry's Cox account.

From eric.kuhnke at gmail.com  Tue Jul  5 23:05:08 2016
From: eric.kuhnke at gmail.com (Eric Kuhnke)
Date: Tue, 5 Jul 2016 16:05:08 -0700
Subject: NAT firewall for IPv6?
In-Reply-To: <CAPX=P3ttYCG6Nsm40JZ=7QHXxQGyE57t-E6p2HqXrpiiE-NJ8g@mail.gmail.com>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
 <577C0ED8.60706@alvarezp.org>
 <CAPkb-7CCJ_6LT=MLrPvF1n6-2CA_Ei7qw2BOhsGDweTeCr5DrA@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E663D72E@MUNPRDMBXA1.medline.com>
 <CAPX=P3ttYCG6Nsm40JZ=7QHXxQGyE57t-E6p2HqXrpiiE-NJ8g@mail.gmail.com>
Message-ID: <CAB69EHhCfaHaCswssAuGyiw+hAW1NQrxyFa-F+PeTO-CfXGPyg@mail.gmail.com>

You know the cosmological model that the earth is balanced on the back of a
giant turtle, which is supported by successive lower tiers of other turtles?

https://en.wikipedia.org/wiki/Turtles_all_the_way_down

It's like that, except it's trolls all the way down.



On Tue, Jul 5, 2016 at 3:24 PM, Chase Christian <madsushi at gmail.com> wrote:

> The original email was not a serious question, but a joke:
>
> https://twitter.com/SwiftOnSecurity/status/749059605360062464
> https://twitter.com/SwiftOnSecurity/status/749062835687174144
> https://twitter.com/SwiftOnSecurity/status/749068172460847105
>
>
>
> On Tue, Jul 5, 2016 at 1:41 PM, Naslund, Steve <SNaslund at medline.com>
> wrote:
>
> > It is all about defense in depth.  The engineers here are speaking to the
> > network pieces (the second N in NANOG is network, right :) and we have
> told
> > this person that it is unlikely that v6 in the only vector and I myself
> > talked about malware handling on the clients themselves.  From a network
> > engineering perspective many of us agreed that the biggest single threat
> to
> > his network was a firewall in an unknown state with an unknown
> > administrator password that could be owned by anyone on earth at this
> > point.  That single piece threatens the entire network as a whole and is
> a
> > ticking time bomb ready to blow his entire LAN off the Internet if it
> fails.
> >
> > He probably does not own the entire environment himself, he is filling in
> > for a vacationing network engineer.  So he is working on the network
> piece
> > and is probably not responsible for the anti-malware software on the
> > clients (if anyone is, see below).
> >
> > Our "support" as you call it was a response to this person questions
> about
> > blocking v6 as an attack vector in the first place.  We answered his
> > question but then told him that was unlikely to be the problem and what
> he
> > should do about taking back his firewall, securing v6 via the firewall,
> and
> > handling the malware at the client.  Seems solid advise to me so far.
> >
> > BTW we did not bill him for anything.  He got a lot of free advice from a
> > lot of people he could not even begin to afford to employ, so not a bad
> > deal for him.  You also have to understand that this gentleman seems to
> be
> > in an educational environment which usually means lots of clients he does
> > not have control over so having some kind of network based malware
> control
> > is helpful.  Clients in this type of environment have to defend
> themselves
> > from each other and he will likely have stuff brought in from the
> outside.
> > Good malware detection in the network can help identify clients that
> > contain malware and are a threat to other devices.  Fancier network
> > gear/IDS/IDP would actually remove offending clients from the network or
> at
> > least segments them into an isolation area.
> >
> > Let me re-iterate:
> >
> >         1.      Take back ownership of your firewall and bring it up to
> > date including new malware signatures.  If you don't have current
> support,
> > get it...........directly so if your consultant bails you are not dead
> > meat.  This will ensure that the outside world will not own or control
> > stuff inside your network while you put the fires out.  At the very least
> > it can help malware infected machines from phoning home to their command
> > and control servers which sometimes prevents a lot of damage.
> >         2.      Make your v6 rules mirror at least the security level of
> > your v4 rules.  Passing v6 unchallenged is unacceptable.  If your
> firewall
> > won't do it replace it with one that will.
> >         3.      Ensure all clients under your control have current
> > anti-virus/anti-malware detection.  Clients have to defend themselves
> from
> > threats internal to the firewall as well as ones outside.  Don't be hard
> on
> > the outside with a soft chewy center.
> >         4.      Never, ever accept anything less than full administrative
> > control passwords and accounts from your consultants, before you give
> them
> > final payment.  I actually prefer to lock them out when they complete an
> > install until I need them to help with something.  This prevents them
> from
> > holding you hostage or one of their "postal" employees from wiping you
> out
> > as well as preventing them from using your network for experimentation
> > without you knowing it.  It is an important part of change control to
> > ensure that outsiders cannot modify your configuration without contacting
> > you first.  We usually give our consultants highly logged VPN accounts
> that
> > we can disable or enable as needed.
> >
> > Steven Naslund
> > Chicago IL
> >
> >
> >
> > >>No while that is also needed, it is very unlikely to fix his issue. The
> > issue at hand is that some of their computers have become virus infected.
> > >>The fix for that is to upgrade the virus scanner and making sure that
> > all software upgrades are done.
> >
> > >>Someone comes to you and says his Firefox is getting infected through
> > IPv6.
> > >>If your support is worth anything, you will not take that at face value
> > and bill him for a ton work related to IPv6. No, you will go find out
> what
> > the real issue is and solve that. The only thing we know right now is
> that
> > he is >>confused.
> > >>
> > >>Regards,
> > >>
> > >>Baldur
> >
>

From mpalmer at hezmatt.org  Tue Jul  5 23:46:51 2016
From: mpalmer at hezmatt.org (Matt Palmer)
Date: Wed, 6 Jul 2016 09:46:51 +1000
Subject: NAT firewall for IPv6?
In-Reply-To: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
Message-ID: <20160705234651.GJ22102@hezmatt.org>

On Fri, Jul 01, 2016 at 09:28:54PM -0500, Edgar Carver wrote:
> Hello NANOG community. I was directed here by our network administrator
> since she is on vacation. Luckily, I minored in Computer Science so I have
> some familiarity.

Well played, Tay.  Well played.

For everyone else:

https://twitter.com/SwiftOnSecurity/status/749062835687174144

- Matt


From larrysheldon at cox.net  Wed Jul  6 00:32:48 2016
From: larrysheldon at cox.net (Larry Sheldon)
Date: Tue, 5 Jul 2016 19:32:48 -0500
Subject: NAT firewall for IPv6?
In-Reply-To: <20160705234651.GJ22102@hezmatt.org>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
 <20160705234651.GJ22102@hezmatt.org>
Message-ID: <1d2697d9-901a-d5cf-da02-15fc2bb81ffe@cox.net>



On 7/5/2016 18:46, Matt Palmer wrote:
> On Fri, Jul 01, 2016 at 09:28:54PM -0500, Edgar Carver wrote:
>> Hello NANOG community. I was directed here by our network administrator
>> since she is on vacation. Luckily, I minored in Computer Science so I have
>> some familiarity.
>
> Well played, Tay.  Well played.

I was suspicious at the "minored" announcement, but it looked so much 
like traffic here.....

I guess the reality is that for legitimate traffic, this list is used 
only as a "calling frequency" with the "working frequency" being 
somewhere secret.

Sad.

>
> For everyone else:
>
> https://twitter.com/SwiftOnSecurity/status/749062835687174144

-- 
"Everybody is a genius.  But if you judge a fish by
its ability to climb a tree, it will live its whole
life believing that it is stupid."

--Albert Einstein

 From Larry's Cox account.

From nanog at ics-il.net  Wed Jul  6 12:42:14 2016
From: nanog at ics-il.net (Mike Hammett)
Date: Wed, 6 Jul 2016 07:42:14 -0500 (CDT)
Subject: Experience on Wanguard for 'anti' DDOS solutions
In-Reply-To: <CAJj1h3GPmc0yyL5TLN=2SfUFrMOjckWoTsVN9L01z6vXXyQK9w@mail.gmail.com>
References: <1117637696.1801282.1439189885305.JavaMail.yahoo@mail.yahoo.com>
 <CAJj1h3GPmc0yyL5TLN=2SfUFrMOjckWoTsVN9L01z6vXXyQK9w@mail.gmail.com>
Message-ID: <727585518.11809.1467808933778.JavaMail.mhammett@ThunderFuck>

(I debated starting a new thread, only to have someone point me to previous ones vs. replying to an old post. I thought the latter was less offensive.) 

Did you find anything else near the price range that didn't have these deficiencies? 
As an eyeball network, would I have much to worry about regarding non-layer3/4 attacks? 
"Considering how easy it is to blocklayer 3/4 attacks on your own, their filtering clusters don't offer much value." I am aware of manual ACLs, but are there other automated methods (near this price range) to handle the 3/4 attacks? 
"it runs out of memory quickly" How much memory are we talking here? Reasonable to mitigate that downside by just stuffing more RAM in the box? 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

----- Original Message -----

From: "Richard Hesse" <richard.hesse at weebly.com> 
To: "NANOG Mailing List" <nanog at nanog.org> 
Sent: Friday, August 28, 2015 1:23:01 PM 
Subject: Re: Experience on Wanguard for 'anti' DDOS solutions 

We've tried their products off an on for the past 3-4 years. Here are 
my impressions: 

* UI stuck in 1999. Can't click zoom, drill down, etc. 
* Inflexible UI. Want a bandwidth graph with only egress or ingress? Too bad. 
* Inexpensive. I don't like that it's licensed yearly, but it's not 
too much money. 
* Inaccurate flow processing. Do you have iBGP peering sessions 
between border routers? WANGuard will struggle mightily to correctly 
classify the traffic as internal or external. 
* Yes, it runs out of memory quickly during a spoofed SYN flood with 
many sources. This is due to setting the Top generator to Full. If you 
just want to mitigate and not have any insight into network data, set 
this to Extended and you'll be fine. But if you want to use 
WANGuard/WANSight as a network intelligence tool as well, you need to 
set the generator to Full and it will fall over. 
* Doesn't process IPFIX flow data properly. There's an old thread on 
the j-nsp list about this. Basically their support claims Juniper is 
broken (which I don't doubt) but then refuses to work around the 
issue. None of our other flow processing tools have these problems. 
* Support is responsive at times and is always cranky. I brought them 
two bonafide bugs in their product that they refused to admit. It got 
to the point where I asked for my money back and I think someone in 
sales lit up their support team. I get the feeling that the support 
team is staffed with employees who really don't like their job or 
working with customers. A bad combination. 
* The TAP generators with Myricom cards work well. The docs say you 
can use SolarFlare for TAPs but they don't work at all. Again, they 
blame SolarFlare and say that the cards are too complicated....but 
fail to update their documentation saying this. 
* Doesn't support any kind of layer 7 detection or filtering. It's all 
very rudimentary layer 3-4 stuff. Considering how easy it is to block 
layer 3/4 attacks on your own, their filtering clusters don't offer 
much value. 
* No real scale out solution on the detection side. It's basically 
scale up your server or use clunky tech like NFS to share out 
directories across managers. 
* Works well enough to get you a rough idea of what's going on. It's 
also decently cheap. 

We use it as one part of our attack detection toolset. We don't use it 
for on-site attack mitigation. I'd recommend it if you don't want to 
use flow data and only want to use it for intelligence on TAP ports. 

-richard 

On Mon, Aug 10, 2015 at 6:58 AM, Marcel Duregards 
<marcel.duregards at yahoo.fr> wrote: 
> Dear Nogers, 
> We are currently evaluating some DDOS detection/mitigation solutions. 
> Do you have any inputs/experiences on Wanguard from Andrisoft, please ?https://www.andrisoft.com/software/wanguard 
> Currently we are just interested on the packets/flows sensors with the console for detection and RTBH trigger. Maybe the packet filtering (for scrubbing) will come later. 
> Best Regards,-Marcel Duregards 
> 
> 
> 


From morrowc.lists at gmail.com  Wed Jul  6 17:23:04 2016
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 6 Jul 2016 13:23:04 -0400
Subject: New ICANN registrant change process
In-Reply-To: <6C958391-E2F3-413A-98ED-C689B819F42E@baylink.com>
References: <800550479.18808.1467654861589.JavaMail.zimbra@baylink.com>
 <8D804E82-D9EF-4FF6-A0EA-796F7AB76780@beckman.org>
 <6C958391-E2F3-413A-98ED-C689B819F42E@baylink.com>
Message-ID: <CAL9jLabTmTQM6z--F75=f4Xy7-AT5ane0SLznRMoMvHzQQNZyw@mail.gmail.com>

On Mon, Jul 4, 2016 at 3:03 PM, Jay Ashworth <jra at baylink.com> wrote:

> Seems to me that the proper thing to be done would have been for
> Registries to deauthorize registrars on the grounds of continuous streams
> of complaints.
>
>
<devils advocate hat>
On what metric? Pure volume? Percent of registrations? type of complaint by
similar x/y?
</devils advocate hat>

there are 'lots of complaints' against some registrars, but if you have
~20% of the .TLD market you're prone to get more volume than a 1%er, right?
Also, this isn't REALLY the registrY's problem is it?

i love how icann makes avoiding blame so easy.

From drc at virtualized.org  Wed Jul  6 18:53:30 2016
From: drc at virtualized.org (David Conrad)
Date: Wed, 6 Jul 2016 08:53:30 -1000
Subject: New ICANN registrant change process
In-Reply-To: <CAL9jLabTmTQM6z--F75=f4Xy7-AT5ane0SLznRMoMvHzQQNZyw@mail.gmail.com>
References: <800550479.18808.1467654861589.JavaMail.zimbra@baylink.com>
 <8D804E82-D9EF-4FF6-A0EA-796F7AB76780@beckman.org>
 <6C958391-E2F3-413A-98ED-C689B819F42E@baylink.com>
 <CAL9jLabTmTQM6z--F75=f4Xy7-AT5ane0SLznRMoMvHzQQNZyw@mail.gmail.com>
Message-ID: <D17509E2-9C25-46BA-958C-E63D9B37A804@virtualized.org>

On Jul 6, 2016, at 7:23 AM, Christopher Morrow <morrowc.lists at gmail.com> wrote:
> On Mon, Jul 4, 2016 at 3:03 PM, Jay Ashworth <jra at baylink.com> wrote:
>> Seems to me that the proper thing to be done would have been for
>> Registries to deauthorize registrars on the grounds of continuous streams
>> of complaints.
>> 
>> 
> <devils advocate hat>
> On what metric? Pure volume? Percent of registrations? type of complaint by
> similar x/y?
> </devils advocate hat>

By the terms the Registry sets in the Registry/Registrar Agreement and to which the Registrar agrees in order to sell the Registry's names.

> there are 'lots of complaints' against some registrars, but if you have
> ~20% of the .TLD market you're prone to get more volume than a 1%er, right?

There's this concept called "normalization", e.g., complaints per 100 delegations or some such.

> Also, this isn't REALLY the registrY's problem is it?

Depends on whether or not the Registry wants their TLD to be associated with spam/malware distribution/botnet C&C/phishing/pharming and be removed at resolvers via RPZ or similar. Ultimately, the Registries are responsible for the pool the Registrars are peeing in -- it's the Registry's namespace, is it not?

> i love how icann makes avoiding blame so easy.

I love how people love to blame ICANN.

Regards,
-drc
(speaking only for myself)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160706/75fe4b39/attachment.pgp>

From blake at ispn.net  Wed Jul  6 19:47:02 2016
From: blake at ispn.net (Blake Hudson)
Date: Wed, 6 Jul 2016 14:47:02 -0500
Subject: New ICANN registrant change process
In-Reply-To: <800550479.18808.1467654861589.JavaMail.zimbra@baylink.com>
References: <800550479.18808.1467654861589.JavaMail.zimbra@baylink.com>
Message-ID: <5d703dcd-25ec-963f-7211-b6947c8e2c0a@ispn.net>

As a customer of OpenSRS they sent us a notice about the change. The 
notice, and this page you linked, speak to their customer communication 
about policy changes.

To be honest, I just breezed the email message and noted that it seemed 
like a positive change (without knowing the reasons that prompted the 
change). We rarely update registrant information and rarely transfer 
domains. We also know our customers. I expect this will have zero impact 
on our day to day operations other than potentially preventing some 
hijackings (we have had some customers experience hijackings in the days 
when all it took was a fax on letterhead to NetSol to get your domain 
info changed).



Jay R. Ashworth wrote on 7/4/2016 12:54 PM:
> I'll go ahead and assume I wasn't the last person to get this memo (courtesy
> Lauren Weinstein's PRIVACY Digest):
>
> https://opensrs.com/blog/2016/06/icanns-new-transfer-policy-will-impact-business-customers/
>
> It does seem that this is going to make life difficult for a bunch of pretty
> normal business processes.
>
> If you didn't know about it either... ask yourself why not.
>
> Cheers,
> -- jra
>


From morrowc.lists at gmail.com  Wed Jul  6 19:48:32 2016
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 6 Jul 2016 15:48:32 -0400
Subject: New ICANN registrant change process
In-Reply-To: <D17509E2-9C25-46BA-958C-E63D9B37A804@virtualized.org>
References: <800550479.18808.1467654861589.JavaMail.zimbra@baylink.com>
 <8D804E82-D9EF-4FF6-A0EA-796F7AB76780@beckman.org>
 <6C958391-E2F3-413A-98ED-C689B819F42E@baylink.com>
 <CAL9jLabTmTQM6z--F75=f4Xy7-AT5ane0SLznRMoMvHzQQNZyw@mail.gmail.com>
 <D17509E2-9C25-46BA-958C-E63D9B37A804@virtualized.org>
Message-ID: <CAL9jLabWuZY3rfs=kcOiK1N6-907H1Es2P_TQG7trrTGHAxmfQ@mail.gmail.com>

On Wed, Jul 6, 2016 at 2:53 PM, David Conrad <drc at virtualized.org> wrote:

> On Jul 6, 2016, at 7:23 AM, Christopher Morrow <morrowc.lists at gmail.com>
> wrote:
> > On Mon, Jul 4, 2016 at 3:03 PM, Jay Ashworth <jra at baylink.com> wrote:
> >> Seems to me that the proper thing to be done would have been for
> >> Registries to deauthorize registrars on the grounds of continuous
> streams
> >> of complaints.
> >>
> >>
> > <devils advocate hat>
> > On what metric? Pure volume? Percent of registrations? type of complaint
> by
> > similar x/y?
> > </devils advocate hat>
>
> By the terms the Registry sets in the Registry/Registrar Agreement and to
> which the Registrar agrees in order to sell the Registry's names.
>
>
ok, neat!


> > there are 'lots of complaints' against some registrars, but if you have
> > ~20% of the .TLD market you're prone to get more volume than a 1%er,
> right?
>
> There's this concept called "normalization", e.g., complaints per 100
> delegations or some such.
>
>
that's something I expected, yes... some rate that works out if I  just
registrar for 10 domains vs 10million. cool.


> > Also, this isn't REALLY the registrY's problem is it?
>
> Depends on whether or not the Registry wants their TLD to be associated
> with spam/malware distribution/botnet C&C/phishing/pharming and be removed
> at resolvers via RPZ or similar. Ultimately, the Registries are responsible
> for the pool the Registrars are peeing in -- it's the Registry's namespace,
> is it not?
>
>
it's not clear, to me, that any of those hammers have real effect.


> > i love how icann makes avoiding blame so easy.
>
> I love how people love to blame ICANN.
>

but, they are the names and numbers authority, no? it says so in their
name.

From Valdis.Kletnieks at vt.edu  Wed Jul  6 19:48:49 2016
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 06 Jul 2016 15:48:49 -0400
Subject: New ICANN registrant change process
In-Reply-To: <CAL9jLabTmTQM6z--F75=f4Xy7-AT5ane0SLznRMoMvHzQQNZyw@mail.gmail.com>
References: <800550479.18808.1467654861589.JavaMail.zimbra@baylink.com>
 <8D804E82-D9EF-4FF6-A0EA-796F7AB76780@beckman.org>
 <6C958391-E2F3-413A-98ED-C689B819F42E@baylink.com>
 <CAL9jLabTmTQM6z--F75=f4Xy7-AT5ane0SLznRMoMvHzQQNZyw@mail.gmail.com>
Message-ID: <26957.1467834529@turing-police.cc.vt.edu>

On Wed, 06 Jul 2016 13:23:04 -0400, Christopher Morrow said:
> On Mon, Jul 4, 2016 at 3:03 PM, Jay Ashworth <jra at baylink.com> wrote:
>
> > Seems to me that the proper thing to be done would have been for
> > Registries to deauthorize registrars on the grounds of continuous streams
> > of complaints.
> >
> >
> <devils advocate hat>
> On what metric? Pure volume? Percent of registrations? type of complaint by
> similar x/y?
> </devils advocate hat>
>
> there are 'lots of complaints' against some registrars, but if you have
> ~20% of the .TLD market you're prone to get more volume than a 1%er, right?
> Also, this isn't REALLY the registrY's problem is it?

Jay definitely said 'registRARS'.  And yes, it *is* the registrar's problem
to ensure they aren't selling thousands of domain registrations to known
spammers and other miscreants.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160706/d8bb68ce/attachment.pgp>

From drc at virtualized.org  Wed Jul  6 20:04:40 2016
From: drc at virtualized.org (David Conrad)
Date: Wed, 6 Jul 2016 10:04:40 -1000
Subject: New ICANN registrant change process
In-Reply-To: <CAL9jLabWuZY3rfs=kcOiK1N6-907H1Es2P_TQG7trrTGHAxmfQ@mail.gmail.com>
References: <800550479.18808.1467654861589.JavaMail.zimbra@baylink.com>
 <8D804E82-D9EF-4FF6-A0EA-796F7AB76780@beckman.org>
 <6C958391-E2F3-413A-98ED-C689B819F42E@baylink.com>
 <CAL9jLabTmTQM6z--F75=f4Xy7-AT5ane0SLznRMoMvHzQQNZyw@mail.gmail.com>
 <D17509E2-9C25-46BA-958C-E63D9B37A804@virtualized.org>
 <CAL9jLabWuZY3rfs=kcOiK1N6-907H1Es2P_TQG7trrTGHAxmfQ@mail.gmail.com>
Message-ID: <03019797-0F7F-4213-886C-8C08AB47D8A5@virtualized.org>

> Depends on whether or not the Registry wants their TLD to be associated with spam/malware distribution/botnet C&C/phishing/pharming and be removed at resolvers via RPZ or similar. Ultimately, the Registries are responsible for the pool the Registrars are peeing in -- it's the Registry's namespace, is it not?
> it's not clear, to me, that any of those hammers have real effect.

Not sure the RPZ hammer has been brought out in force yet. I've seen a few recommendations on various mailing lists, but no concerted effort. Unfortunately, there is no easy/scalable way to determine who a registrar for a given name is, so the hammer has to be applied to the TLD as a whole, which has unfortunate side effects...

>>  I love how people love to blame ICANN.
> 
> but, they are the names and numbers authority, no? it says so in their name.

"Internet Corporation for Assigned Names and Numbers" -- Don't see "authority" in that name. :)

Regards,
-drc
(speaking only for myself)



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160706/f312e04f/attachment.pgp>

From morrowc.lists at gmail.com  Wed Jul  6 20:41:58 2016
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 6 Jul 2016 16:41:58 -0400
Subject: New ICANN registrant change process
In-Reply-To: <03019797-0F7F-4213-886C-8C08AB47D8A5@virtualized.org>
References: <800550479.18808.1467654861589.JavaMail.zimbra@baylink.com>
 <8D804E82-D9EF-4FF6-A0EA-796F7AB76780@beckman.org>
 <6C958391-E2F3-413A-98ED-C689B819F42E@baylink.com>
 <CAL9jLabTmTQM6z--F75=f4Xy7-AT5ane0SLznRMoMvHzQQNZyw@mail.gmail.com>
 <D17509E2-9C25-46BA-958C-E63D9B37A804@virtualized.org>
 <CAL9jLabWuZY3rfs=kcOiK1N6-907H1Es2P_TQG7trrTGHAxmfQ@mail.gmail.com>
 <03019797-0F7F-4213-886C-8C08AB47D8A5@virtualized.org>
Message-ID: <CAL9jLaa=+s9NYGYHNWrJpdVGNoMBzhY-4u=i0YLirNiDJrm1UA@mail.gmail.com>

On Wed, Jul 6, 2016 at 4:04 PM, David Conrad <drc at virtualized.org> wrote:

> Depends on whether or not the Registry wants their TLD to be associated
>> with spam/malware distribution/botnet C&C/phishing/pharming and be removed
>> at resolvers via RPZ or similar. Ultimately, the Registries are responsible
>> for the pool the Registrars are peeing in -- it's the Registry's namespace,
>> is it not?
>
> it's not clear, to me, that any of those hammers have real effect.
>
>
> Not sure the RPZ hammer has been brought out in force yet. I've seen a few
> recommendations on various mailing lists, but no concerted effort.
> Unfortunately, there is no easy/scalable way to determine who a registrar
> for a given name is, so the hammer has to be applied to the TLD as a whole,
> which has unfortunate side effects...
>
>
it's a fun game of chicken :( There have been some actions taken by
registries in the past (I think .TK did this at some point) to try and make
their cone more clean/neat, for a time .science was also being abused but
isn't (today) anymore. Perhaps this all self-polices?


>  I love how people love to blame ICANN.
>
> but, they are the names and numbers authority, no? it says so in their
> name.
>
>
> "Internet Corporation for Assigned Names and Numbers" -- Don't see
> "authority" in that name. :)
>
>
I hate it when you are right :)

From jroberts at rrsdc.com  Tue Jul  5 19:59:03 2016
From: jroberts at rrsdc.com (Jason R)
Date: Tue, 5 Jul 2016 12:59:03 -0700
Subject: NAT firewall for IPv6?
In-Reply-To: <20160705194538.GE19487@lboro.ac.uk>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E663D00B@MUNPRDMBXA1.medline.com>
 <CAD8GWstEJCJOkePCT7O1NDP5BcwJ44VA=Pifqveuafk2_9yMGg@mail.gmail.com>
 <20160705194538.GE19487@lboro.ac.uk>
Message-ID: <CAEJ-UQvY=5kdK8+=GuOmwAyjUf5x1qM+TKOoMD6pF4fdNUwvdw@mail.gmail.com>

FYI

There is no way to reset the password on a PAN without doing a factory
reset if you do not know the password of any previous config release
version.

If you do a reset then you will have to reconfigure the fw rules, ip
addresses, routes, nat, inspection policy's, and other basic functions
depending on if it in layer3 mode or layer2 from scratch. Also are you sure
the exploit vector is from ipv6 and not from traffic that the PAN cannot
see such as TLS traffic?

Also are you sure IPv6 is working? You can test connectivity over IPv6 here
http://test-ipv6.com/

On Tue, Jul 5, 2016 at 12:47 PM, Octavio Alvarez <octalnanog at alvarezp.org>
wrote:

> On 07/01/2016 07:28 PM, Edgar Carver wrote:
> > Is there some kind of NAT-based IPv6 firewall I can setup on the router
> > that can help block viruses?
>
> You need layer-7 firewalls for this. NAT-based "firewalls"
> (pseudo-firewalls, really) are layer-4 only. Those will not help you
> block typical viruses, as people will usually get infected from
> connecting to a compromised Website, or from an e-mail attachments. And
> even more, if connections are encrypted, an L7 firewall will not be able
> to do anything (whether IPv4 or v6) unless... better not open a can of
> worms.
>
> They will just help you block *some* attack vectors, though: those that
> rely on starting connections to your hosts from the outside.
>
> My guess is that, with regard to e-mail attachments and compromised
> Websites, IPv4 hosts are still attacked more than IPv6 ones, so, even if
> you turn off IPv6 you will still get attacked through IPv4.
>
> Everything else has been already said by others: fixing the Palo Alto is
> still your best bet.
>
> Good luck!
>


On Tue, Jul 5, 2016 at 12:45 PM, <A.L.M.Buxey at lboro.ac.uk> wrote:

> Hi,
>
> > Right.  But how long is it going to take to secure the Palo Alto
> firewall?
>
> around 5 minutes?
>
> recover password, restart, log in, fix rules.
>
>
> https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Reset-the-Administrator-Password/ta-p/57581
>
>
> obviously the firewall is also blocking google access! ;-)
>
> alan
>

From rubensk at gmail.com  Thu Jul  7 00:20:09 2016
From: rubensk at gmail.com (Rubens Kuhl)
Date: Wed, 6 Jul 2016 21:20:09 -0300
Subject: New ICANN registrant change process
In-Reply-To: <03019797-0F7F-4213-886C-8C08AB47D8A5@virtualized.org>
References: <800550479.18808.1467654861589.JavaMail.zimbra@baylink.com>
 <8D804E82-D9EF-4FF6-A0EA-796F7AB76780@beckman.org>
 <6C958391-E2F3-413A-98ED-C689B819F42E@baylink.com>
 <CAL9jLabTmTQM6z--F75=f4Xy7-AT5ane0SLznRMoMvHzQQNZyw@mail.gmail.com>
 <D17509E2-9C25-46BA-958C-E63D9B37A804@virtualized.org>
 <CAL9jLabWuZY3rfs=kcOiK1N6-907H1Es2P_TQG7trrTGHAxmfQ@mail.gmail.com>
 <03019797-0F7F-4213-886C-8C08AB47D8A5@virtualized.org>
Message-ID: <CAGFn2k0c5fWxnMx=Cwe+Ya_g1GDzjBBUsLpLEgS-z_oNVYkF7g@mail.gmail.com>

>
> Not sure the RPZ hammer has been brought out in force yet. I've seen a few
> recommendations on various mailing lists, but no concerted effort.
> Unfortunately, there is no easy/scalable way to determine who a registrar
> for a given name is,



That is called RDAP, but ICANN currently blocks gTLD registries from
offering RDAP.


Rubens

From drc at virtualized.org  Thu Jul  7 02:13:25 2016
From: drc at virtualized.org (David Conrad)
Date: Wed, 6 Jul 2016 16:13:25 -1000
Subject: New ICANN registrant change process
In-Reply-To: <CAGFn2k0c5fWxnMx=Cwe+Ya_g1GDzjBBUsLpLEgS-z_oNVYkF7g@mail.gmail.com>
References: <800550479.18808.1467654861589.JavaMail.zimbra@baylink.com>
 <8D804E82-D9EF-4FF6-A0EA-796F7AB76780@beckman.org>
 <6C958391-E2F3-413A-98ED-C689B819F42E@baylink.com>
 <CAL9jLabTmTQM6z--F75=f4Xy7-AT5ane0SLznRMoMvHzQQNZyw@mail.gmail.com>
 <D17509E2-9C25-46BA-958C-E63D9B37A804@virtualized.org>
 <CAL9jLabWuZY3rfs=kcOiK1N6-907H1Es2P_TQG7trrTGHAxmfQ@mail.gmail.com>
 <03019797-0F7F-4213-886C-8C08AB47D8A5@virtualized.org>
 <CAGFn2k0c5fWxnMx=Cwe+Ya_g1GDzjBBUsLpLEgS-z_oNVYkF7g@mail.gmail.com>
Message-ID: <22D1E303-C130-4C60-B7B0-2081D1DF31D3@virtualized.org>

Rubens,

On Jul 6, 2016, at 2:20 PM, Rubens Kuhl <rubensk at gmail.com> wrote:
>> Not sure the RPZ hammer has been brought out in force yet. I've seen a few recommendations on various mailing lists, but no concerted effort. Unfortunately, there is no easy/scalable way to determine who a registrar for a given name is,
> That is called RDAP,

I said "scalable".

Given RDAP is based on TCP and there is this concept known as "registration data lookup rate limiting", I'm somewhat skeptical RDAP is the appropriate choice for (e.g.,) a "DNS Block List"-like solution that would (say) dump email that came from domains registered via operator-specified registrars.

> but ICANN currently blocks gTLD registries from offering RDAP.


Ignoring the above, and as I'm sure you're aware, the community has not determined the policies by which RDAP may be offered as an official registry service using production data, e.g., whether and how differentiated services will be permitted among other details.  As such, it is more accurate to say that registries are not permitted to deploy new services because of contractual obligations the registries entered into that requires them to have new services evaluated to ensure those services don't impact DNS security, stability or competition, something the community required ICANN enforce as a result of the SiteFinder episode ages ago. Registries can, of course, request that evaluation and I'm told some have and are actually offering RDAP.

But I would agree it is much easier to simply blame ICANN.

Regards,
-drc
(speaking only for myself)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160706/90af6db1/attachment.pgp>

From drc at virtualized.org  Thu Jul  7 02:17:13 2016
From: drc at virtualized.org (David Conrad)
Date: Wed, 6 Jul 2016 16:17:13 -1000
Subject: New ICANN registrant change process
In-Reply-To: <CAL9jLaa=+s9NYGYHNWrJpdVGNoMBzhY-4u=i0YLirNiDJrm1UA@mail.gmail.com>
References: <800550479.18808.1467654861589.JavaMail.zimbra@baylink.com>
 <8D804E82-D9EF-4FF6-A0EA-796F7AB76780@beckman.org>
 <6C958391-E2F3-413A-98ED-C689B819F42E@baylink.com>
 <CAL9jLabTmTQM6z--F75=f4Xy7-AT5ane0SLznRMoMvHzQQNZyw@mail.gmail.com>
 <D17509E2-9C25-46BA-958C-E63D9B37A804@virtualized.org>
 <CAL9jLabWuZY3rfs=kcOiK1N6-907H1Es2P_TQG7trrTGHAxmfQ@mail.gmail.com>
 <03019797-0F7F-4213-886C-8C08AB47D8A5@virtualized.org>
 <CAL9jLaa=+s9NYGYHNWrJpdVGNoMBzhY-4u=i0YLirNiDJrm1UA@mail.gmail.com>
Message-ID: <E7552F64-AA5B-4F29-A7CF-BE9F7ACA8DF9@virtualized.org>

On Jul 6, 2016, at 10:41 AM, Christopher Morrow <morrowc.lists at gmail.com> wrote:
> Perhaps this all self-polices?

I figure either it does or governments get involved and that most likely ends in tears.

>  I hate it when you are right :)

Don't worry: very rarely happens.

Regards,
-drc
(speaking only for myself)



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160706/4a859e6c/attachment.pgp>

From morrowc.lists at gmail.com  Thu Jul  7 02:35:38 2016
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 6 Jul 2016 22:35:38 -0400
Subject: New ICANN registrant change process
In-Reply-To: <E7552F64-AA5B-4F29-A7CF-BE9F7ACA8DF9@virtualized.org>
References: <800550479.18808.1467654861589.JavaMail.zimbra@baylink.com>
 <8D804E82-D9EF-4FF6-A0EA-796F7AB76780@beckman.org>
 <6C958391-E2F3-413A-98ED-C689B819F42E@baylink.com>
 <CAL9jLabTmTQM6z--F75=f4Xy7-AT5ane0SLznRMoMvHzQQNZyw@mail.gmail.com>
 <D17509E2-9C25-46BA-958C-E63D9B37A804@virtualized.org>
 <CAL9jLabWuZY3rfs=kcOiK1N6-907H1Es2P_TQG7trrTGHAxmfQ@mail.gmail.com>
 <03019797-0F7F-4213-886C-8C08AB47D8A5@virtualized.org>
 <CAL9jLaa=+s9NYGYHNWrJpdVGNoMBzhY-4u=i0YLirNiDJrm1UA@mail.gmail.com>
 <E7552F64-AA5B-4F29-A7CF-BE9F7ACA8DF9@virtualized.org>
Message-ID: <CAL9jLaYS1iZWwG8WLYgyTJ5OSKgUc7H7AapSpjd1ZXnwupXjyA@mail.gmail.com>

On Wed, Jul 6, 2016 at 10:17 PM, David Conrad <drc at virtualized.org> wrote:

> On Jul 6, 2016, at 10:41 AM, Christopher Morrow <morrowc.lists at gmail.com>
> wrote:
> > Perhaps this all self-polices?
>
> I figure either it does or governments get involved and that most likely
> ends in tears.
>
>
I can't wait for our gov't overloads to discover that they might be able to
regulate/legislate the internets... Wait, doesn't ICE already do that? Oh,
and also some Brexit oriented group as well?


> >  I hate it when you are right :)
>
> Don't worry: very rarely happens.
>

see it's already not happening.

From jaap at NLnetLabs.nl  Thu Jul  7 06:52:47 2016
From: jaap at NLnetLabs.nl (Jaap Akkerhuis)
Date: Thu, 07 Jul 2016 08:52:47 +0200
Subject: New ICANN registrant change process
In-Reply-To: <22D1E303-C130-4C60-B7B0-2081D1DF31D3@virtualized.org>
References: <800550479.18808.1467654861589.JavaMail.zimbra@baylink.com>
 <8D804E82-D9EF-4FF6-A0EA-796F7AB76780@beckman.org>
 <6C958391-E2F3-413A-98ED-C689B819F42E@baylink.com>
 <CAL9jLabTmTQM6z--F75=f4Xy7-AT5ane0SLznRMoMvHzQQNZyw@mail.gmail.com>
 <D17509E2-9C25-46BA-958C-E63D9B37A804@virtualized.org>
 <CAL9jLabWuZY3rfs=kcOiK1N6-907H1Es2P_TQG7trrTGHAxmfQ@mail.gmail.com>
 <03019797-0F7F-4213-886C-8C08AB47D8A5@virtualized.org>
 <CAGFn2k0c5fWxnMx=Cwe+Ya_g1GDzjBBUsLpLEgS-z_oNVYkF7g@mail.gmail.com>
 <22D1E303-C130-4C60-B7B0-2081D1DF31D3@virtualized.org>
Message-ID: <201607070652.u676qldW098207@bela.nlnetlabs.nl>

 David Conrad writes:

 >  <SNIP>
 > 
 > But I would agree it is much easier to simply blame ICANN.
 > 

Yeah, I always blame ICANN for the bad weather :-).

	jaap

From rubensk at gmail.com  Thu Jul  7 09:23:08 2016
From: rubensk at gmail.com (Rubens Kuhl)
Date: Thu, 7 Jul 2016 06:23:08 -0300
Subject: New ICANN registrant change process
In-Reply-To: <22D1E303-C130-4C60-B7B0-2081D1DF31D3@virtualized.org>
References: <800550479.18808.1467654861589.JavaMail.zimbra@baylink.com>
 <8D804E82-D9EF-4FF6-A0EA-796F7AB76780@beckman.org>
 <6C958391-E2F3-413A-98ED-C689B819F42E@baylink.com>
 <CAL9jLabTmTQM6z--F75=f4Xy7-AT5ane0SLznRMoMvHzQQNZyw@mail.gmail.com>
 <D17509E2-9C25-46BA-958C-E63D9B37A804@virtualized.org>
 <CAL9jLabWuZY3rfs=kcOiK1N6-907H1Es2P_TQG7trrTGHAxmfQ@mail.gmail.com>
 <03019797-0F7F-4213-886C-8C08AB47D8A5@virtualized.org>
 <CAGFn2k0c5fWxnMx=Cwe+Ya_g1GDzjBBUsLpLEgS-z_oNVYkF7g@mail.gmail.com>
 <22D1E303-C130-4C60-B7B0-2081D1DF31D3@virtualized.org>
Message-ID: <CAGFn2k12xc+OaiUU6=2BT+z__rQgmKtD04uShrKTspV-_zhq1w@mail.gmail.com>

On Wed, Jul 6, 2016 at 11:13 PM, David Conrad <drc at virtualized.org> wrote:

> Rubens,
>
> On Jul 6, 2016, at 2:20 PM, Rubens Kuhl <rubensk at gmail.com> wrote:
> >> Not sure the RPZ hammer has been brought out in force yet. I've seen a
> few recommendations on various mailing lists, but no concerted effort.
> Unfortunately, there is no easy/scalable way to determine who a registrar
> for a given name is,
> > That is called RDAP,
>
> I said "scalable".
>
> Given RDAP is based on TCP and there is this concept known as
> "registration data lookup rate limiting", I'm somewhat skeptical RDAP is
> the appropriate choice for (e.g.,) a "DNS Block List"-like solution that
> would (say) dump email that came from domains registered via
> operator-specified registrars.
>

Fair enough. There are though non-standard UDP-based domain lookup
implementations like isavail that could address both this use case and
provide faster availability searches.


> > but ICANN currently blocks gTLD registries from offering RDAP.
>
>
> Ignoring the above, and as I'm sure you're aware, the community has not
> determined the policies by which RDAP may be offered as an official
> registry service using production data, e.g., whether and how
> differentiated services will be permitted among other details.  As such, it
> is more accurate to say that registries are not permitted to deploy new
> services because of contractual obligations the registries entered into
> that requires them to have new services evaluated to ensure those services
> don't impact DNS security, stability or competition, something the
> community required ICANN enforce as a result of the SiteFinder episode ages
> ago. Registries can, of course, request that evaluation and I'm told some
> have and are actually offering RDAP.
>
> But I would agree it is much easier to simply blame ICANN.
>
>
RDAP is totally different from other possible registry services since it's
already baked into registries contracts...
https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-09jan14-en.htm
specification 4. It's basically the same service already offered thru
WHOIS, RDDS, over a different protocol.

The contract already allows ICANN to trigger a requirement to support RDAP,
but doesn't allow registries to support if before they are required. ICANN
could have, and has been suggested to, allow it before it triggers the
requirement in order to have willing registries support it, and hasn't done
it.

So in this particular case I don't have any problems blaming ICANN... and
the great level of transparency of ICANN meetings being recorded and
transcribed provides plenty of evidence in that regard.

As for gTLD registries offering RDAP, I couldn't find any at
https://www.icann.org/resources/pages/rsep-2014-02-19-en, the page where
new registry services are described and published for comments... the only
registries I know deploying RDAP are ccTLDs, which do not operate inside
ICANN gTLD policy framework.
https://rdap.registro.br/domain/icannsaopaulo.br
https://rdap.nic.cz/domain/nic.cz



Rubens

From jmaimon at ttec.com  Thu Jul  7 14:15:59 2016
From: jmaimon at ttec.com (Joe Maimon)
Date: Thu, 7 Jul 2016 10:15:59 -0400
Subject: google routing noc/looking glass/contact
Message-ID: <577E641F.5060409@ttec.com>

I would appreciate it if anyone could put me in touch or send me any 
tips to deal with packet loss and problems routing to google, but only 
along certain paths from certain points in the network (like as in ecmp 
problems) from as21719

I would like to rule out local issues if possible and that would 
certainly help.

Joe

From akg1330 at gmail.com  Thu Jul  7 16:59:37 2016
From: akg1330 at gmail.com (Andrew Gallo)
Date: Thu, 7 Jul 2016 12:59:37 -0400
Subject: Leap Second planned for 2016
Message-ID: <c8258e7b-d53c-6a31-b2a4-57b44cbc79e6@gmail.com>

Looks like we'll have another second in 2016:
http://www.space.com/33361-leap-second-2016-atomic-clocks.html


Time to start preparing


From phillip.lynn at netwolves.com  Thu Jul  7 19:17:40 2016
From: phillip.lynn at netwolves.com (Phillip Lynn)
Date: Thu, 7 Jul 2016 15:17:40 -0400
Subject: packet loss question
Message-ID: <577EAAD4.5010405@netwolves.com>

Hi all,

   I am writing because I do not understand what is happening.  I ran 
mtr against our email server and www.teco.comand below are the results.  
I am not a network engineer so I am at a loss.  I think what I am seeing 
is maybe a hand off issue, between Frontier and Level3Miami2. If I am 
correct then what can I do?

   My system is running Centos 6.5 Linux.

Thanks,

Phillip



(! 1011)-> sudo mtr -r netwolves.securence.com
HOST: xxxxx at netwolves.comLoss%   Snt   Last   Avg Best  Wrst StDev
   1. 172.24.109.1                  0.0%    10    0.6 0.6 0.6   0.7   0.0
   2. lo0-100.TAMPFL-VFTTP-322.gni  0.0%    10    3.2 2.0 1.0   4.3   1.2
   3. 172.99.44.214                 0.0%    10    4.0 4.9 2.3   6.9   1.5
   4. ae8---0.scr02.mias.fl.fronti  0.0%    10    9.3 9.1 7.5   9.8   1.0
   5. ae1---0.cbr01.mias.fl.fronti  0.0%    10    8.9   9.1   7.6 9.7 0.7
   6. lag-101.ear3.Miami2.Level3.n 80.0%    10    9.0   8.9   8.8 9.0 0.1
   7. 10ge9-14.core1.mia1.he.net    0.0%    10   14.3 13.0 7.6  18.1   4.3
   8. 10ge1-1.core1.atl1.he.net     0.0%    10   25.6  33.2 22.4  99.7  
23.6
   9. 10ge10-4.core1.chi1.he.net    0.0%    10   45.6  51.8 45.5  82.7  
12.5
  10. 100ge14-2.core1.msp1.he.net   0.0%    10   53.6  63.9 53.6 125.2  
21.8
  11. t4-2-usi-cr02-mpls-usinterne  0.0%    10   53.2  73.1 53.2 225.6  
54.0
  12. v102.usi-cr04-mtka.usinterne  0.0%    10   53.2  53.9 53.2  55.3   
0.6
  13. netwolves.securence.com       0.0%    10   53.4  53.9 53.4  55.4   
0.7

(! 1014)-> sudo mtr -r www.teco.com
HOST: xxxxx at netwolves.comLoss%   Snt   Last   Avg Best  Wrst StDev
   1. 172.24.109.1                  0.0%    10    0.6 0.6 0.6   0.7   0.0
   2. lo0-100.TAMPFL-VFTTP-322.gni  0.0%    10  104.8 81.4 1.1 113.2  43.2
   3. 172.99.47.198                 0.0%    10  115.0 77.8 2.9 115.0  40.2
   4. ae7---0.scr01.mias.fl.fronti  0.0%    10  111.1 80.2 8.5 113.5  41.3
   5. ae0---0.cbr01.mias.fl.fronti  0.0%    10  105.9  82.2   7.6 115.4 
33.8
   6. lag-101.ear3.Miami2.Level3.n 70.0%    10  116.1  80.2   8.5 116.1 
62.0
   7. NTT-level3-80G.Miami.Level3.  0.0%    10  110.0 81.5 9.0 120.3  41.9
   8. ae-3.r20.miamfl02.us.bb.gin.  0.0%    10  119.8  84.0 10.0 119.8  
38.5
   9. ae-4.r23.asbnva02.us.bb.gin. 10.0%    10  137.4 107.6 30.1 142.7  
45.7
  10. ae-2.r05.asbnva02.us.bb.gin.  0.0%    10  135.0 109.9 36.6 140.0  
39.1
  11. xe-0-9-0-8.r05.asbnva02.us.c  0.0%    10  147.5 125.6 49.4 165.5  
41.1
  12. 24.52.112.21                  0.0%    10  158.6 124.0 49.6 161.3  
41.5
  13. 24.52.112.42                  0.0%    10  151.0 127.7 52.2 159.0  
41.2
  14. ???                          100.0    10    0.0 0.0 0.0   0.0   0.0

-- 
Phillip Lynn
Software Engineer III
NetWolves
Phone:813-579-3214
Fax:813-882-0209
Email: phillip.lynn at netwolves.com
www.netwolves.com


From job at instituut.net  Thu Jul  7 19:32:18 2016
From: job at instituut.net (Job Snijders)
Date: Thu, 7 Jul 2016 21:32:18 +0200
Subject: packet loss question
In-Reply-To: <577EAAD4.5010405@netwolves.com>
References: <577EAAD4.5010405@netwolves.com>
Message-ID: <20160707193218.GA92324@Vurt.local>

Hi Philip,

I can't address your immediate concern, but I do have some hints
regarding traceroute:

1/ Please review the excellent presentation from RA{T,S}:
    https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf
    https://www.youtube.com/watch?v=a1IaRAVGPEE

2/ When you run mtr, make sure to run it with the '-w' argument for
easier to read reverse DNS entries.

Kind regards,

Job

On Thu, Jul 07, 2016 at 03:17:40PM -0400, Phillip Lynn wrote:
>   I am writing because I do not understand what is happening.  I ran mtr
> against our email server and www.teco.comand below are the results.  I am
> not a network engineer so I am at a loss.  I think what I am seeing is maybe
> a hand off issue, between Frontier and Level3Miami2. If I am correct then
> what can I do?
> 
>   My system is running Centos 6.5 Linux.
> 
> Thanks,
> 
> Phillip
> 
> 
> 
> (! 1011)-> sudo mtr -r netwolves.securence.com
> HOST: xxxxx at netwolves.comLoss%   Snt   Last   Avg Best  Wrst StDev
>   1. 172.24.109.1                  0.0%    10    0.6 0.6 0.6   0.7   0.0
>   2. lo0-100.TAMPFL-VFTTP-322.gni  0.0%    10    3.2 2.0 1.0   4.3   1.2
>   3. 172.99.44.214                 0.0%    10    4.0 4.9 2.3   6.9   1.5
>   4. ae8---0.scr02.mias.fl.fronti  0.0%    10    9.3 9.1 7.5   9.8   1.0
>   5. ae1---0.cbr01.mias.fl.fronti  0.0%    10    8.9   9.1   7.6 9.7 0.7
>   6. lag-101.ear3.Miami2.Level3.n 80.0%    10    9.0   8.9   8.8 9.0 0.1
>   7. 10ge9-14.core1.mia1.he.net    0.0%    10   14.3 13.0 7.6  18.1   4.3
>   8. 10ge1-1.core1.atl1.he.net     0.0%    10   25.6  33.2 22.4  99.7  23.6
>   9. 10ge10-4.core1.chi1.he.net    0.0%    10   45.6  51.8 45.5  82.7  12.5
>  10. 100ge14-2.core1.msp1.he.net   0.0%    10   53.6  63.9 53.6 125.2  21.8
>  11. t4-2-usi-cr02-mpls-usinterne  0.0%    10   53.2  73.1 53.2 225.6  54.0
>  12. v102.usi-cr04-mtka.usinterne  0.0%    10   53.2  53.9 53.2  55.3   0.6
>  13. netwolves.securence.com       0.0%    10   53.4  53.9 53.4  55.4   0.7
> 
> (! 1014)-> sudo mtr -r www.teco.com
> HOST: xxxxx at netwolves.comLoss%   Snt   Last   Avg Best  Wrst StDev
>   1. 172.24.109.1                  0.0%    10    0.6 0.6 0.6   0.7   0.0
>   2. lo0-100.TAMPFL-VFTTP-322.gni  0.0%    10  104.8 81.4 1.1 113.2  43.2
>   3. 172.99.47.198                 0.0%    10  115.0 77.8 2.9 115.0  40.2
>   4. ae7---0.scr01.mias.fl.fronti  0.0%    10  111.1 80.2 8.5 113.5  41.3
>   5. ae0---0.cbr01.mias.fl.fronti  0.0%    10  105.9  82.2   7.6 115.4 33.8
>   6. lag-101.ear3.Miami2.Level3.n 70.0%    10  116.1  80.2   8.5 116.1 62.0
>   7. NTT-level3-80G.Miami.Level3.  0.0%    10  110.0 81.5 9.0 120.3  41.9
>   8. ae-3.r20.miamfl02.us.bb.gin.  0.0%    10  119.8  84.0 10.0 119.8  38.5
>   9. ae-4.r23.asbnva02.us.bb.gin. 10.0%    10  137.4 107.6 30.1 142.7  45.7
>  10. ae-2.r05.asbnva02.us.bb.gin.  0.0%    10  135.0 109.9 36.6 140.0  39.1
>  11. xe-0-9-0-8.r05.asbnva02.us.c  0.0%    10  147.5 125.6 49.4 165.5  41.1
>  12. 24.52.112.21                  0.0%    10  158.6 124.0 49.6 161.3  41.5
>  13. 24.52.112.42                  0.0%    10  151.0 127.7 52.2 159.0  41.2
>  14. ???                          100.0    10    0.0 0.0 0.0   0.0   0.0
> 
> -- 
> Phillip Lynn
> Software Engineer III
> NetWolves
> Phone:813-579-3214
> Fax:813-882-0209
> Email: phillip.lynn at netwolves.com
> www.netwolves.com
> 

From math at sizone.org  Thu Jul  7 19:52:47 2016
From: math at sizone.org (Ken Chase)
Date: Thu, 7 Jul 2016 15:52:47 -0400
Subject: packet loss question
In-Reply-To: <577EAAD4.5010405@netwolves.com>
References: <577EAAD4.5010405@netwolves.com>
Message-ID: <20160707195247.GO18345@sizone.org>

No offence, but i swear that mtr should come with a license to use it. I get more
questions from people accusing us of network issues with mtr in hand...

You shoudlnt care that there's 80% packet loss in the middle of your route, unless
you have actual traffic to lag-101.ear3.miami2.level3.net. I suspect you dont.
(If you did, you'd have mtr'd to it directly of course.)

As for your second trace, the sudden jump from 0% on 2nd last hop to 100% last
hop packetloss seems like firewalling to me. (long discussion about the
probabilities of getting 5 0%pl hops in a row and 100% on an unfirewalled
endpoint elided. TL;DR: use more packets in your test -i 0.1 -c 100 thanks).

If you have 0% packetloss to your target endpoint, is there an issue here?
What caused you to mtr?  0% pl is pretty good. You could play quake 1.0
through that pl and ping time. The +20ms ATL<>CHI jump in the route you'd have
to take up with einstein/bill nye/$deity. 

For the 2nd trace, the 1st hop is your latency issue (plus the big jump from
miami<>ashburn, again the limit is c.)

ICMP is allowed to be dropped by intervening routers. Someone will quote an RFC
at us shortly.

Mtr without a return route is not that useful in figuring out packetloss
because pl requires the packet make it there and back. Pl could be anywhere on
the return route, which is probably not symmetrical. The internet stopped
being symetrical about 20+ years ago (if it ever even loosely was), so get a friend
to send you an mtr to your ip from the farside.

(I remember a project long ago, some cgi-bin (yeah that long ago) that was
basically a full-path forward+reverse traceroute you could hit on a selected
server at the provider.  Rather handy. not sure if its still a thing, or what it was
called.)

/kc


On Thu, Jul 07, 2016 at 03:17:40PM -0400, Phillip Lynn said:
  >Hi all,
  >
  >  I am writing because I do not understand what is happening.  I ran mtr
  >against our email server and www.teco.comand below are the results.  I am
  >not a network engineer so I am at a loss.  I think what I am seeing is
  >maybe a hand off issue, between Frontier and Level3Miami2. If I am correct
  >then what can I do?
  >
  >  My system is running Centos 6.5 Linux.
  >
  >Thanks,
  >
  >Phillip
  >
  >
  >
  >(! 1011)-> sudo mtr -r netwolves.securence.com
  >HOST: xxxxx at netwolves.comLoss%   Snt   Last   Avg Best  Wrst StDev
  >  1. 172.24.109.1                  0.0%    10    0.6 0.6 0.6   0.7   0.0
  >  2. lo0-100.TAMPFL-VFTTP-322.gni  0.0%    10    3.2 2.0 1.0   4.3   1.2
  >  3. 172.99.44.214                 0.0%    10    4.0 4.9 2.3   6.9   1.5
  >  4. ae8---0.scr02.mias.fl.fronti  0.0%    10    9.3 9.1 7.5   9.8   1.0
  >  5. ae1---0.cbr01.mias.fl.fronti  0.0%    10    8.9   9.1   7.6 9.7 0.7
  >  6. lag-101.ear3.Miami2.Level3.n 80.0%    10    9.0   8.9   8.8 9.0 0.1
  >  7. 10ge9-14.core1.mia1.he.net    0.0%    10   14.3 13.0 7.6  18.1   4.3
  >  8. 10ge1-1.core1.atl1.he.net     0.0%    10   25.6  33.2 22.4  99.7  23.6
  >  9. 10ge10-4.core1.chi1.he.net    0.0%    10   45.6  51.8 45.5  82.7  12.5
  > 10. 100ge14-2.core1.msp1.he.net   0.0%    10   53.6  63.9 53.6 125.2  21.8
  > 11. t4-2-usi-cr02-mpls-usinterne  0.0%    10   53.2  73.1 53.2 225.6  54.0
  > 12. v102.usi-cr04-mtka.usinterne  0.0%    10   53.2  53.9 53.2  55.3   0.6
  > 13. netwolves.securence.com       0.0%    10   53.4  53.9 53.4  55.4   0.7
  >
  >(! 1014)-> sudo mtr -r www.teco.com
  >HOST: xxxxx at netwolves.comLoss%   Snt   Last   Avg Best  Wrst StDev
  >  1. 172.24.109.1                  0.0%    10    0.6 0.6 0.6   0.7   0.0
  >  2. lo0-100.TAMPFL-VFTTP-322.gni  0.0%    10  104.8 81.4 1.1 113.2  43.2
  >  3. 172.99.47.198                 0.0%    10  115.0 77.8 2.9 115.0  40.2
  >  4. ae7---0.scr01.mias.fl.fronti  0.0%    10  111.1 80.2 8.5 113.5  41.3
  >  5. ae0---0.cbr01.mias.fl.fronti  0.0%    10  105.9  82.2   7.6 115.4 33.8
  >  6. lag-101.ear3.Miami2.Level3.n 70.0%    10  116.1  80.2   8.5 116.1 62.0
  >  7. NTT-level3-80G.Miami.Level3.  0.0%    10  110.0 81.5 9.0 120.3  41.9
  >  8. ae-3.r20.miamfl02.us.bb.gin.  0.0%    10  119.8  84.0 10.0 119.8  38.5
  >  9. ae-4.r23.asbnva02.us.bb.gin. 10.0%    10  137.4 107.6 30.1 142.7  45.7
  > 10. ae-2.r05.asbnva02.us.bb.gin.  0.0%    10  135.0 109.9 36.6 140.0  39.1
  > 11. xe-0-9-0-8.r05.asbnva02.us.c  0.0%    10  147.5 125.6 49.4 165.5  41.1
  > 12. 24.52.112.21                  0.0%    10  158.6 124.0 49.6 161.3  41.5
  > 13. 24.52.112.42                  0.0%    10  151.0 127.7 52.2 159.0  41.2
  > 14. ???                          100.0    10    0.0 0.0 0.0   0.0   0.0
  >
  >-- 
  >Phillip Lynn
  >Software Engineer III
  >NetWolves
  >Phone:813-579-3214
  >Fax:813-882-0209
  >Email: phillip.lynn at netwolves.com
  >www.netwolves.com
  >

-- 
Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada
Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W.

From james.cutler at consultant.com  Thu Jul  7 20:14:57 2016
From: james.cutler at consultant.com (James R Cutler)
Date: Thu, 7 Jul 2016 16:14:57 -0400
Subject: packet loss question
In-Reply-To: <577EAAD4.5010405@netwolves.com>
References: <577EAAD4.5010405@netwolves.com>
Message-ID: <5BA6443E-35E2-4657-B6A8-93D652D555A3@consultant.com>

> On Jul 7, 2016, at 3:17 PM, Phillip Lynn <phillip.lynn at netwolves.com> wrote:
> 
> Hi all,
> 
>  I am writing because I do not understand what is happening.  I ran mtr against our email server and www.teco.comand below are the results.  I am not a network engineer so I am at a loss.  I think what I am seeing is maybe a hand off issue, between Frontier and Level3Miami2. If I am correct then what can I do?
> 
>  My system is running Centos 6.5 Linux.
> 
> Thanks,
> 
> Phillip
> 
> 
> 
> (! 1011)-> sudo mtr -r netwolves.securence.com
> HOST: xxxxx at netwolves.comLoss%   Snt   Last   Avg Best  Wrst StDev
>  1. 172.24.109.1                  0.0%    10    0.6 0.6 0.6   0.7   0.0
>  2. lo0-100.TAMPFL-VFTTP-322.gni  0.0%    10    3.2 2.0 1.0   4.3   1.2
>  3. 172.99.44.214                 0.0%    10    4.0 4.9 2.3   6.9   1.5
>  4. ae8---0.scr02.mias.fl.fronti  0.0%    10    9.3 9.1 7.5   9.8   1.0
>  5. ae1---0.cbr01.mias.fl.fronti  0.0%    10    8.9   9.1   7.6 9.7 0.7
>  6. lag-101.ear3.Miami2.Level3.n 80.0%    10    9.0   8.9   8.8 9.0 0.1
>  7. 10ge9-14.core1.mia1.he.net    0.0%    10   14.3 13.0 7.6  18.1   4.3
>  8. 10ge1-1.core1.atl1.he.net     0.0%    10   25.6  33.2 22.4  99.7  23.6
>  9. 10ge10-4.core1.chi1.he.net    0.0%    10   45.6  51.8 45.5  82.7  12.5
> 10. 100ge14-2.core1.msp1.he.net   0.0%    10   53.6  63.9 53.6 125.2  21.8
> 11. t4-2-usi-cr02-mpls-usinterne  0.0%    10   53.2  73.1 53.2 225.6  54.0
> 12. v102.usi-cr04-mtka.usinterne  0.0%    10   53.2  53.9 53.2  55.3   0.6
> 13. netwolves.securence.com       0.0%    10   53.4  53.9 53.4  55.4   0.7
> 
> (! 1014)-> sudo mtr -r www.teco.com
> HOST: xxxxx at netwolves.comLoss%   Snt   Last   Avg Best  Wrst StDev
>  1. 172.24.109.1                  0.0%    10    0.6 0.6 0.6   0.7   0.0
>  2. lo0-100.TAMPFL-VFTTP-322.gni  0.0%    10  104.8 81.4 1.1 113.2  43.2
>  3. 172.99.47.198                 0.0%    10  115.0 77.8 2.9 115.0  40.2
>  4. ae7---0.scr01.mias.fl.fronti  0.0%    10  111.1 80.2 8.5 113.5  41.3
>  5. ae0---0.cbr01.mias.fl.fronti  0.0%    10  105.9  82.2   7.6 115.4 33.8
>  6. lag-101.ear3.Miami2.Level3.n 70.0%    10  116.1  80.2   8.5 116.1 62.0
>  7. NTT-level3-80G.Miami.Level3.  0.0%    10  110.0 81.5 9.0 120.3  41.9
>  8. ae-3.r20.miamfl02.us.bb.gin.  0.0%    10  119.8  84.0 10.0 119.8  38.5
>  9. ae-4.r23.asbnva02.us.bb.gin. 10.0%    10  137.4 107.6 30.1 142.7  45.7
> 10. ae-2.r05.asbnva02.us.bb.gin.  0.0%    10  135.0 109.9 36.6 140.0  39.1
> 11. xe-0-9-0-8.r05.asbnva02.us.c  0.0%    10  147.5 125.6 49.4 165.5  41.1
> 12. 24.52.112.21                  0.0%    10  158.6 124.0 49.6 161.3  41.5
> 13. 24.52.112.42                  0.0%    10  151.0 127.7 52.2 159.0  41.2
> 14. ???                          100.0    10    0.0 0.0 0.0   0.0   0.0
> 
> --
> Phillip Lynn
> Software Engineer III
> NetWolves
> Phone:813-579-3214
> Fax:813-882-0209
> Email: phillip.lynn at netwolves.com
> www.netwolves.com
> 
Phillip,

The data for netwolves.securence.com shows 0% loss between HOST and netwolves.securence.com. This is most certainly good. The 80% Loss in line 4 simply indicates that that particular router was too busy to respond in a timely manner to an ECHO request because it was busy forwarding data traffic. There is no problem to solve for this connection.

The data for www.teco.com <http://www.teco.com/> has a couple of busy hops. However, for as far as the trace succeeds (24.52.112.42) there is no effective loss end to end.  The ??? response, similar to *** from traceroute, indicates that there is probably no route to the destination from that point. (Or there is a firewall blocking SNMP ECHO requests at that point.) Diagnosis may require contacting the operator of www.teco.com <http://www.teco.com/> to confirm the system is actually on line and operational. Contact information for tech.com is in whois.

Auxiliary information - traceroute data from a system in plymouth.mi.michigan.comcast.net <http://plymouth.mi.michigan.comcast.net/> shows similar results for both targets.

Are there other hosts difficult to reach?

James R. Cutler
James.cutler at consultant.com
PGP keys at http://pgp.mit.edu

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 872 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160707/42235e8f/attachment.pgp>

From james.cutler at consultant.com  Thu Jul  7 20:18:50 2016
From: james.cutler at consultant.com (James R Cutler)
Date: Thu, 7 Jul 2016 16:18:50 -0400
Subject: packet loss question
In-Reply-To: <5BA6443E-35E2-4657-B6A8-93D652D555A3@consultant.com>
References: <577EAAD4.5010405@netwolves.com>
 <5BA6443E-35E2-4657-B6A8-93D652D555A3@consultant.com>
Message-ID: <04FBECC5-AC60-4218-BE72-8AEE7D5279F3@consultant.com>

sedit /blocking SNMP ECHO requests/blocking ICMP ECHO requests/

oops! dyslexic fingers.

James R. Cutler
James.cutler at consultant.com
PGP keys at http://pgp.mit.edu



> On Jul 7, 2016, at 4:14 PM, James R Cutler <james.cutler at consultant.com> wrote:
> 
> blocking SNMP ECHO requests

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 872 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160707/14ba3aab/attachment.pgp>

From bruns at 2mbit.com  Thu Jul  7 20:27:36 2016
From: bruns at 2mbit.com (Brielle Bruns)
Date: Thu, 7 Jul 2016 14:27:36 -0600
Subject: packet loss question
In-Reply-To: <577EAAD4.5010405@netwolves.com>
References: <577EAAD4.5010405@netwolves.com>
Message-ID: <e39c0d7b-5aaf-d65d-d6b9-77c1f6c1879d@2mbit.com>

On 7/7/16 1:17 PM, Phillip Lynn wrote:
> Hi all,
>
>   I am writing because I do not understand what is happening.  I ran mtr
> against our email server and www.teco.comand below are the results.  I
> am not a network engineer so I am at a loss.  I think what I am seeing
> is maybe a hand off issue, between Frontier and Level3Miami2. If I am
> correct then what can I do?
>
>   My system is running Centos 6.5 Linux.


Is it bad that the first thing that came to mind is "Oh FFS, another troll"?


-- 
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org    /     http://www.ahbl.org

From mel at beckman.org  Thu Jul  7 20:32:19 2016
From: mel at beckman.org (Mel Beckman)
Date: Thu, 7 Jul 2016 20:32:19 +0000
Subject: packet loss question
In-Reply-To: <e39c0d7b-5aaf-d65d-d6b9-77c1f6c1879d@2mbit.com>
References: <577EAAD4.5010405@netwolves.com>,
 <e39c0d7b-5aaf-d65d-d6b9-77c1f6c1879d@2mbit.com>
Message-ID: <9A2000BD-1DAB-4FFE-ADBF-8830A2EEFD44@beckman.org>

Yes. It indicates that there was never a time when you did not know everything :)

 -mel beckman

> On Jul 7, 2016, at 1:28 PM, Brielle Bruns <bruns at 2mbit.com> wrote:
> 
>> On 7/7/16 1:17 PM, Phillip Lynn wrote:
>> Hi all,
>> 
>>  I am writing because I do not understand what is happening.  I ran mtr
>> against our email server and www.teco.comand below are the results.  I
>> am not a network engineer so I am at a loss.  I think what I am seeing
>> is maybe a hand off issue, between Frontier and Level3Miami2. If I am
>> correct then what can I do?
>> 
>>  My system is running Centos 6.5 Linux.
> 
> 
> Is it bad that the first thing that came to mind is "Oh FFS, another troll"?
> 
> 
> -- 
> Brielle Bruns
> The Summit Open Source Development Group
> http://www.sosdg.org    /     http://www.ahbl.org

From math at sizone.org  Thu Jul  7 21:34:52 2016
From: math at sizone.org (Ken Chase)
Date: Thu, 7 Jul 2016 17:34:52 -0400
Subject: packet loss question
Message-ID: <20160707213452.GF3241@sizone.org>

On Thu, Jul 07, 2016 at 08:32:19PM +0000, Mel Beckman said:
  >Yes. It indicates that there was never a time when you did not know everything :)
  >
  > -mel beckman

The issue isnt knowing everything, it's making accusations of issues while you still
dont know how much you dont know. (~D. Rumsfeld) -- My customers in a nutshell
(they pay to be able to yell about random stuff I guess, and I provide that service!).

The OP didnt make any accusations however, and just asked what was going on (sorry
if I sounded harsh in reply). Once, Google having a 8.8.8.8 failure locally on
its (anycast?) dns servers resulted in dozens of calls to us "your server
hosting our site must be down!! Our website isnt working! People are calling us!".

Most of my work is with these situations is spent proving it's not our fault.
Mtr makes it very hard because it's a very subtle tool, and only gives partial
information. (I still think mtr is a killer app though!)

consider this (fake, example) trace:

  6. 100ge13-1.core1.chi1.he.net            0.0%    10 
  7. 100ge14-1.core2.chi1.he.net            0.0%    10 
  8. 100ge3-1.core1.sjc2.he.net            30.0%    10 
  9. ???
 10. UNKNOWN-216-115-101-X.yahoo.com       10.0%    10 
 11. routerer-ext.ysv.freebsd.org          20.0%    10 
 12. wfe0.ysv.freebsd.org                  30.0%    10 

First off, the OP may have asked "who's fault is hop 9, yahoo or HE?" and seen it
as an issue. Ignoring that for now, the rest of the packetloss is an issue --
where is the problem though?

This is very tricky - it looks like hop 8 is at fault of course - or is it
just dropping ICMP as it's allowed to? How did hop 10 get only 10% loss then if
8 has 30? Is 8 then dropping ~20% (not statistically correct..) of ICMP just cuz
it can, and then having a 'real' 10% loss on top of that?

Or it's hop 11? But hop 12 has more PL, perhaps hop 12 is the issue
all along and 8 10 and 11 are just dropping ICMP? Or it's 8, 11 and 12 doing
~10% each? (not statistically correct.)

Can't say for sure - it's a probabilities game - and being completely correct
about it, hop 6 isn't blameless either (just very unlikely to be at fault
statistically, though not impossible with only 10 pings per hop - a statistician
can calculate it for us).

This is why more pings are required to be sure of the situation - I like to do
-i 0.1 -c 100 so it's completed quickly before conditions change.  Then you
can make a statistically valid pronouncement of where the problem MIGHT BE
within a useful confidence interval - however, without the return route we're
still largely in the dark as to the actual location of the issue. You cant be
'100% sure' with this stuff - technically speaking, it's all 'luck of the draw'.

(Beware: this one time, at band camp, some etherchannel or equiv at HE was
showing PL only for specific ips in any target subnet -- because they were xor'ing
the source & target IP to load balance and one channel was wonky. Fun times
debugging that one: "WFM from here, what's your issue?")

/kc
-- 
Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada
Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W.

From mel at beckman.org  Thu Jul  7 21:50:02 2016
From: mel at beckman.org (Mel Beckman)
Date: Thu, 7 Jul 2016 21:50:02 +0000
Subject: packet loss question
In-Reply-To: <20160707213452.GF3241@sizone.org>
References: <20160707213452.GF3241@sizone.org>
Message-ID: <A1F5111A-3B36-47E3-AE92-BD60C341B49E@beckman.org>

Ken,

I should have made clear I wasn't replying to you. I was replying to Brielle's comment:

>  Is it bad that the first thing that came to mind is "Oh FFS, another troll"?

 -mel beckman

> On Jul 7, 2016, at 2:35 PM, Ken Chase <math at sizone.org> wrote:
> 
> On Thu, Jul 07, 2016 at 08:32:19PM +0000, Mel Beckman said:
>> Yes. It indicates that there was never a time when you did not know everything :)
>> 
>> -mel beckman
> 
> The issue isnt knowing everything, it's making accusations of issues while you still
> dont know how much you dont know. (~D. Rumsfeld) -- My customers in a nutshell
> (they pay to be able to yell about random stuff I guess, and I provide that service!).
> 
> The OP didnt make any accusations however, and just asked what was going on (sorry
> if I sounded harsh in reply). Once, Google having a 8.8.8.8 failure locally on
> its (anycast?) dns servers resulted in dozens of calls to us "your server
> hosting our site must be down!! Our website isnt working! People are calling us!".
> 
> Most of my work is with these situations is spent proving it's not our fault.
> Mtr makes it very hard because it's a very subtle tool, and only gives partial
> information. (I still think mtr is a killer app though!)
> 
> consider this (fake, example) trace:
> 
>  6. 100ge13-1.core1.chi1.he.net            0.0%    10 
>  7. 100ge14-1.core2.chi1.he.net            0.0%    10 
>  8. 100ge3-1.core1.sjc2.he.net            30.0%    10 
>  9. ???
> 10. UNKNOWN-216-115-101-X.yahoo.com       10.0%    10 
> 11. routerer-ext.ysv.freebsd.org          20.0%    10 
> 12. wfe0.ysv.freebsd.org                  30.0%    10 
> 
> First off, the OP may have asked "who's fault is hop 9, yahoo or HE?" and seen it
> as an issue. Ignoring that for now, the rest of the packetloss is an issue --
> where is the problem though?
> 
> This is very tricky - it looks like hop 8 is at fault of course - or is it
> just dropping ICMP as it's allowed to? How did hop 10 get only 10% loss then if
> 8 has 30? Is 8 then dropping ~20% (not statistically correct..) of ICMP just cuz
> it can, and then having a 'real' 10% loss on top of that?
> 
> Or it's hop 11? But hop 12 has more PL, perhaps hop 12 is the issue
> all along and 8 10 and 11 are just dropping ICMP? Or it's 8, 11 and 12 doing
> ~10% each? (not statistically correct.)
> 
> Can't say for sure - it's a probabilities game - and being completely correct
> about it, hop 6 isn't blameless either (just very unlikely to be at fault
> statistically, though not impossible with only 10 pings per hop - a statistician
> can calculate it for us).
> 
> This is why more pings are required to be sure of the situation - I like to do
> -i 0.1 -c 100 so it's completed quickly before conditions change.  Then you
> can make a statistically valid pronouncement of where the problem MIGHT BE
> within a useful confidence interval - however, without the return route we're
> still largely in the dark as to the actual location of the issue. You cant be
> '100% sure' with this stuff - technically speaking, it's all 'luck of the draw'.
> 
> (Beware: this one time, at band camp, some etherchannel or equiv at HE was
> showing PL only for specific ips in any target subnet -- because they were xor'ing
> the source & target IP to load balance and one channel was wonky. Fun times
> debugging that one: "WFM from here, what's your issue?")
> 
> /kc
> -- 
> Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada
> Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W.

From bruns at 2mbit.com  Thu Jul  7 23:16:51 2016
From: bruns at 2mbit.com (Brielle Bruns)
Date: Thu, 7 Jul 2016 17:16:51 -0600
Subject: packet loss question
In-Reply-To: <A1F5111A-3B36-47E3-AE92-BD60C341B49E@beckman.org>
References: <20160707213452.GF3241@sizone.org>
 <A1F5111A-3B36-47E3-AE92-BD60C341B49E@beckman.org>
Message-ID: <bf9a2e9a-1d61-b6d2-8691-34fe18378fa9@2mbit.com>

On 7/7/16 3:50 PM, Mel Beckman wrote:
> Ken,
>
> I should have made clear I wasn't replying to you. I was replying to Brielle's comment:
>
>> >  Is it bad that the first thing that came to mind is "Oh FFS, another troll"?
I'd never say I was always knowledgeable, but after the thread the other 
day, and just general stress lately, some reactions are hard not to give 
into :)

-- 
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org    /     http://www.ahbl.org

From cb.list6 at gmail.com  Thu Jul  7 23:25:39 2016
From: cb.list6 at gmail.com (Ca By)
Date: Thu, 7 Jul 2016 16:25:39 -0700
Subject: www.RT.com bad dns record
Message-ID: <CAD6AjGTR2__=4PJ5z-jLypMJFD3pt1fJnwdWmbHdDOhL2NC6Tg@mail.gmail.com>

Anyone have a contact at www.rt.com that can encourage them to to delete
their bad aaaa ?

Some users on some devices fail to reach www.rt.com due to this dns
failure. I know about various work arounds, looking for RT.com to fix this
by deleting the bad aaaa record.

Shared from ISC Dig for iOS

; <<>> DiG 9.10.4 <<>> @fe80::4c60:deff:fee6:b019 @192.168.1.1 www.rt.com aaaa
+sit +dnssec +noqr +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4367
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;www.rt.com.            IN AAAA

;; ANSWER SECTION:
www.rt.com.             10 IN AAAA ::ffff:37.48.108.112


;; Query time: 298 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Jul 06 20:19:34 PDT 2016
;; MSG SIZE  rcvd: 67

From sryan at arbor.net  Fri Jul  8 01:05:25 2016
From: sryan at arbor.net (Spencer Ryan)
Date: Thu, 7 Jul 2016 21:05:25 -0400
Subject: www.RT.com bad dns record
In-Reply-To: <CAD6AjGTR2__=4PJ5z-jLypMJFD3pt1fJnwdWmbHdDOhL2NC6Tg@mail.gmail.com>
References: <CAD6AjGTR2__=4PJ5z-jLypMJFD3pt1fJnwdWmbHdDOhL2NC6Tg@mail.gmail.com>
Message-ID: <CA+HzidRYurrDb4Rasa5JJjjCbVGX4EAhShH4Apf2SZGrhF2zeA@mail.gmail.com>

Dotted-quad notation is completely valid, and works fine.

https://en.wikipedia.org/wiki/IPv6_address#Presentation

http://[::ffff:37.48.108.112] loads fine in my browsers.


*Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net
*Arbor Networks*
+1.734.794.5033 (d) | +1.734.846.2053 (m)
www.arbornetworks.com

On Thu, Jul 7, 2016 at 7:25 PM, Ca By <cb.list6 at gmail.com> wrote:

> Anyone have a contact at www.rt.com that can encourage them to to delete
> their bad aaaa ?
>
> Some users on some devices fail to reach www.rt.com due to this dns
> failure. I know about various work arounds, looking for RT.com to fix this
> by deleting the bad aaaa record.
>
> Shared from ISC Dig for iOS
>
> ; <<>> DiG 9.10.4 <<>> @fe80::4c60:deff:fee6:b019 @192.168.1.1 www.rt.com
> aaaa
> +sit +dnssec +noqr +multiline
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4367
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 512
> ;; QUESTION SECTION:
> ;www.rt.com.            IN AAAA
>
> ;; ANSWER SECTION:
> www.rt.com.             10 IN AAAA ::ffff:37.48.108.112
>
>
> ;; Query time: 298 msec
> ;; SERVER: 192.168.1.1#53(192.168.1.1)
> ;; WHEN: Wed Jul 06 20:19:34 PDT 2016
> ;; MSG SIZE  rcvd: 67
>

From cb.list6 at gmail.com  Fri Jul  8 01:36:23 2016
From: cb.list6 at gmail.com (Ca By)
Date: Thu, 7 Jul 2016 18:36:23 -0700
Subject: www.RT.com bad dns record
In-Reply-To: <CA+HzidRYurrDb4Rasa5JJjjCbVGX4EAhShH4Apf2SZGrhF2zeA@mail.gmail.com>
References: <CAD6AjGTR2__=4PJ5z-jLypMJFD3pt1fJnwdWmbHdDOhL2NC6Tg@mail.gmail.com>
 <CA+HzidRYurrDb4Rasa5JJjjCbVGX4EAhShH4Apf2SZGrhF2zeA@mail.gmail.com>
Message-ID: <CAD6AjGRehioWt_D_gReG4AYHpRb=c_Gb9VTvZAAeNEamG8EK1w@mail.gmail.com>

On Thursday, July 7, 2016, Spencer Ryan <sryan at arbor.net> wrote:

> Dotted-quad notation is completely valid, and works fine.
>
> https://en.wikipedia.org/wiki/IPv6_address#Presentation
>
> http://[::ffff:37.48.108.112] loads fine in my browsers.
>
>
> Spencer,

It may be legit on your network, but people generally don't do that.... If
they publish a aaaa record, it usually has a legit v6 address in it.

That said, what they have done breaks in dns64 networks. This could be a
real downer for them in the near future if they dont remove this aaaa. I am
sending this mail in attempt to head of impending disruptions for www.rt.com
for some subset of users.

And www.rt.com is one of only two sites in the alexa top 25,000 websites to
do this thing.

http://www.employees.org/~dwing/aaaa-stats/ipv6-map.2016-07-07_0800.txt

So, again, it would be great if www.rt.com could remove the aaaa.

CB


>
>
> *Spencer Ryan* | Senior Systems Administrator | sryan at arbor.net
> <javascript:_e(%7B%7D,'cvml','sryan at arbor.net');>
> *Arbor Networks*
> +1.734.794.5033 (d) | +1.734.846.2053 (m)
> www.arbornetworks.com
>
> On Thu, Jul 7, 2016 at 7:25 PM, Ca By <cb.list6 at gmail.com
> <javascript:_e(%7B%7D,'cvml','cb.list6 at gmail.com');>> wrote:
>
>> Anyone have a contact at www.rt.com that can encourage them to to delete
>> their bad aaaa ?
>>
>> Some users on some devices fail to reach www.rt.com due to this dns
>> failure. I know about various work arounds, looking for RT.com to fix this
>> by deleting the bad aaaa record.
>>
>> Shared from ISC Dig for iOS
>>
>> ; <<>> DiG 9.10.4 <<>> @fe80::4c60:deff:fee6:b019 @192.168.1.1 www.rt.com
>> aaaa
>> +sit +dnssec +noqr +multiline
>> ; (1 server found)
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4367
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags: do; udp: 512
>> ;; QUESTION SECTION:
>> ;www.rt.com.            IN AAAA
>>
>> ;; ANSWER SECTION:
>> www.rt.com.             10 IN AAAA ::ffff:37.48.108.112
>>
>>
>> ;; Query time: 298 msec
>> ;; SERVER: 192.168.1.1#53(192.168.1.1)
>> ;; WHEN: Wed Jul 06 20:19:34 PDT 2016
>> ;; MSG SIZE  rcvd: 67
>>
>
>
Does not work for on iOS

From mpalmer at hezmatt.org  Fri Jul  8 02:33:42 2016
From: mpalmer at hezmatt.org (Matt Palmer)
Date: Fri, 8 Jul 2016 12:33:42 +1000
Subject: www.RT.com bad dns record
In-Reply-To: <CAD6AjGRehioWt_D_gReG4AYHpRb=c_Gb9VTvZAAeNEamG8EK1w@mail.gmail.com>
References: <CAD6AjGTR2__=4PJ5z-jLypMJFD3pt1fJnwdWmbHdDOhL2NC6Tg@mail.gmail.com>
 <CA+HzidRYurrDb4Rasa5JJjjCbVGX4EAhShH4Apf2SZGrhF2zeA@mail.gmail.com>
 <CAD6AjGRehioWt_D_gReG4AYHpRb=c_Gb9VTvZAAeNEamG8EK1w@mail.gmail.com>
Message-ID: <20160708023342.GA15545@hezmatt.org>

On Thu, Jul 07, 2016 at 06:36:23PM -0700, Ca By wrote:
> On Thursday, July 7, 2016, Spencer Ryan <sryan at arbor.net> wrote:
> 
> > Dotted-quad notation is completely valid, and works fine.
> >
> > https://en.wikipedia.org/wiki/IPv6_address#Presentation
> >
> > http://[::ffff:37.48.108.112] loads fine in my browsers.
> 
> It may be legit on your network, but people generally don't do that.... If
> they publish a aaaa record, it usually has a legit v6 address in it.

That is a legit IPv6 address.  That it won't work on a host that is IPv6-only
is a different issue, and one I agree is probably an unexpected and unwanted
side effect.

- Matt


From mmg at transtelco.net  Fri Jul  8 02:43:00 2016
From: mmg at transtelco.net (=?UTF-8?Q?Manuel_Mar=C3=ADn?=)
Date: Thu, 7 Jul 2016 20:43:00 -0600
Subject: L3 over OTN vs pure IP/MPLS
Message-ID: <CAD0TWZ_kUTO2utNddusizoOngHUP9MVesyqSXpkPu8A1GqXSSg@mail.gmail.com>

Dear Nanog community

We are currently experimenting TCP degradation issues in some metro markets
where there are multiple POPs and the IP packets have to pass multiple L3
access devices (routers) before reaching the core router. The more L3 hops
that it goes through the more degradation we see in the Internet service.
L3 routers have the capacity in terms of pps and BW and we are using just a
small percentage of that capacity but anyway the service is degraded (No
CRC/Input errors in the links). A couple of vendors are recommending using
OTN or MPLS-TP to backhaul the connections from the access to the core but
obviously deploying OTN means a considerable amount of capex. The
flexibility and simplicity of the L3 based access network is great but
given the performance issues we are experimenting I would appreciate if you
can share your experience/recommendation with either OTN or MPLS-TP. Does
it really make sense to use a OTN/Photonic layer to backhaul the L3
connections in a metro network?

Your input is greatly appreciated

Thanks and have a great day

From bill at herrin.us  Fri Jul  8 03:53:38 2016
From: bill at herrin.us (William Herrin)
Date: Thu, 7 Jul 2016 23:53:38 -0400
Subject: packet loss question
In-Reply-To: <20160707195247.GO18345@sizone.org>
References: <577EAAD4.5010405@netwolves.com>
 <20160707195247.GO18345@sizone.org>
Message-ID: <CAP-guGWytSZUJ++E6UmHUv21TMJAQLq-A-RdtCuVmLG=RKUfDA@mail.gmail.com>

On Thu, Jul 7, 2016 at 3:52 PM, Ken Chase <math at sizone.org> wrote:
> ICMP is allowed to be dropped by intervening routers. Someone will quote an RFC
> at us shortly.

Hi Ken,

That's not correct. Routers might not generate an ICMP time-exceeded
packet for every packet whose TTL reaches zero, but that's not the
same thing. Routers dropping ICMP packets in transit would be bad.
Protocols like TCP depend on path MTU discovery and path MTU discovery
critically depends on ICMP.

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From baldur.norddahl at gmail.com  Fri Jul  8 09:11:59 2016
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Fri, 8 Jul 2016 11:11:59 +0200
Subject: www.RT.com bad dns record
In-Reply-To: <20160708023342.GA15545@hezmatt.org>
References: <CAD6AjGTR2__=4PJ5z-jLypMJFD3pt1fJnwdWmbHdDOhL2NC6Tg@mail.gmail.com>
 <CA+HzidRYurrDb4Rasa5JJjjCbVGX4EAhShH4Apf2SZGrhF2zeA@mail.gmail.com>
 <CAD6AjGRehioWt_D_gReG4AYHpRb=c_Gb9VTvZAAeNEamG8EK1w@mail.gmail.com>
 <20160708023342.GA15545@hezmatt.org>
Message-ID: <577F6E5F.4040106@gmail.com>



On 2016-07-08 04:33, Matt Palmer wrote:
> On Thu, Jul 07, 2016 at 06:36:23PM -0700, Ca By wrote:
>> On Thursday, July 7, 2016, Spencer Ryan <sryan at arbor.net> wrote:
>>
>>> Dotted-quad notation is completely valid, and works fine.
>>>
>>> https://en.wikipedia.org/wiki/IPv6_address#Presentation
>>>
>>> http://[::ffff:37.48.108.112] loads fine in my browsers.
>> It may be legit on your network, but people generally don't do that.... If
>> they publish a aaaa record, it usually has a legit v6 address in it.
> That is a legit IPv6 address.

No it is not. It is a format intended to be used only within a process 
to store IPv4 addresses in a single common data structure for IPv4/IPv6 
or for use in a socket API so a combined IPv4/IPv6 interface can be 
provided. There is no requirement that other processes understand it. 
There is no requirement that IPv4-mapped addressing is not disabled on a 
system supporting IPv6 (RFC4291 section 8 security considerations).

 From RFC5156:


      2.2 <https://tools.ietf.org/html/rfc5156#section-2.2>. IPv4-Mapped
      Addresses



    ::FFFF:0:0/96 are the IPv4-mapped addresses [RFC4291 <https://tools.ietf.org/html/rfc4291>].  Addresses
    within this block should not appear on the public Internet.



You can put it in a AAAA record just as you can configure a 10.0.0.0/8 
address there, but there can be no expectation that it will do anything 
useful outside your own environment.

Regards,

Baldur


From phillip.lynn at netwolves.com  Fri Jul  8 13:01:14 2016
From: phillip.lynn at netwolves.com (Phillip Lynn)
Date: Fri, 8 Jul 2016 09:01:14 -0400
Subject: packet loss question
In-Reply-To: <20160707195247.GO18345@sizone.org>
References: <577EAAD4.5010405@netwolves.com>
 <20160707195247.GO18345@sizone.org>
Message-ID: <577FA41A.8050303@netwolves.com>

On 07/07/2016 03:52 PM, Ken Chase wrote:
> No offence, but i swear that mtr should come with a license to use it. I get more
> questions from people accusing us of network issues with mtr in hand...
>
> You shoudlnt care that there's 80% packet loss in the middle of your route, unless
> you have actual traffic to lag-101.ear3.miami2.level3.net. I suspect you dont.
> (If you did, you'd have mtr'd to it directly of course.)
>
> As for your second trace, the sudden jump from 0% on 2nd last hop to 100% last
> hop packetloss seems like firewalling to me. (long discussion about the
> probabilities of getting 5 0%pl hops in a row and 100% on an unfirewalled
> endpoint elided. TL;DR: use more packets in your test -i 0.1 -c 100 thanks).
>
> If you have 0% packetloss to your target endpoint, is there an issue here?
> What caused you to mtr?  0% pl is pretty good. You could play quake 1.0
> through that pl and ping time. The +20ms ATL<>CHI jump in the route you'd have
> to take up with einstein/bill nye/$deity.
>
> For the 2nd trace, the 1st hop is your latency issue (plus the big jump from
> miami<>ashburn, again the limit is c.)
>
> ICMP is allowed to be dropped by intervening routers. Someone will quote an RFC
> at us shortly.
>
> Mtr without a return route is not that useful in figuring out packetloss
> because pl requires the packet make it there and back. Pl could be anywhere on
> the return route, which is probably not symmetrical. The internet stopped
> being symetrical about 20+ years ago (if it ever even loosely was), so get a friend
> to send you an mtr to your ip from the farside.
>
> (I remember a project long ago, some cgi-bin (yeah that long ago) that was
> basically a full-path forward+reverse traceroute you could hit on a selected
> server at the provider.  Rather handy. not sure if its still a thing, or what it was
> called.)
>
> /kc
>
>
> On Thu, Jul 07, 2016 at 03:17:40PM -0400, Phillip Lynn said:
>    >Hi all,
>    >
>    >  I am writing because I do not understand what is happening.  I ran mtr
>    >against our email server and www.teco.comand below are the results.  I am
>    >not a network engineer so I am at a loss.  I think what I am seeing is
>    >maybe a hand off issue, between Frontier and Level3Miami2. If I am correct
>    >then what can I do?
>    >
>    >  My system is running Centos 6.5 Linux.
>    >
>    >Thanks,
>    >
>    >Phillip
>    >
>    >
>    >
>    >(! 1011)-> sudo mtr -r netwolves.securence.com
>    >HOST: xxxxx at netwolves.comLoss%   Snt   Last   Avg Best  Wrst StDev
>    >  1. 172.24.109.1                  0.0%    10    0.6 0.6 0.6   0.7   0.0
>    >  2. lo0-100.TAMPFL-VFTTP-322.gni  0.0%    10    3.2 2.0 1.0   4.3   1.2
>    >  3. 172.99.44.214                 0.0%    10    4.0 4.9 2.3   6.9   1.5
>    >  4. ae8---0.scr02.mias.fl.fronti  0.0%    10    9.3 9.1 7.5   9.8   1.0
>    >  5. ae1---0.cbr01.mias.fl.fronti  0.0%    10    8.9   9.1   7.6 9.7 0.7
>    >  6. lag-101.ear3.Miami2.Level3.n 80.0%    10    9.0   8.9   8.8 9.0 0.1
>    >  7. 10ge9-14.core1.mia1.he.net    0.0%    10   14.3 13.0 7.6  18.1   4.3
>    >  8. 10ge1-1.core1.atl1.he.net     0.0%    10   25.6  33.2 22.4  99.7  23.6
>    >  9. 10ge10-4.core1.chi1.he.net    0.0%    10   45.6  51.8 45.5  82.7  12.5
>    > 10. 100ge14-2.core1.msp1.he.net   0.0%    10   53.6  63.9 53.6 125.2  21.8
>    > 11. t4-2-usi-cr02-mpls-usinterne  0.0%    10   53.2  73.1 53.2 225.6  54.0
>    > 12. v102.usi-cr04-mtka.usinterne  0.0%    10   53.2  53.9 53.2  55.3   0.6
>    > 13. netwolves.securence.com       0.0%    10   53.4  53.9 53.4  55.4   0.7
>    >
>    >(! 1014)-> sudo mtr -r www.teco.com
>    >HOST: xxxxx at netwolves.comLoss%   Snt   Last   Avg Best  Wrst StDev
>    >  1. 172.24.109.1                  0.0%    10    0.6 0.6 0.6   0.7   0.0
>    >  2. lo0-100.TAMPFL-VFTTP-322.gni  0.0%    10  104.8 81.4 1.1 113.2  43.2
>    >  3. 172.99.47.198                 0.0%    10  115.0 77.8 2.9 115.0  40.2
>    >  4. ae7---0.scr01.mias.fl.fronti  0.0%    10  111.1 80.2 8.5 113.5  41.3
>    >  5. ae0---0.cbr01.mias.fl.fronti  0.0%    10  105.9  82.2   7.6 115.4 33.8
>    >  6. lag-101.ear3.Miami2.Level3.n 70.0%    10  116.1  80.2   8.5 116.1 62.0
>    >  7. NTT-level3-80G.Miami.Level3.  0.0%    10  110.0 81.5 9.0 120.3  41.9
>    >  8. ae-3.r20.miamfl02.us.bb.gin.  0.0%    10  119.8  84.0 10.0 119.8  38.5
>    >  9. ae-4.r23.asbnva02.us.bb.gin. 10.0%    10  137.4 107.6 30.1 142.7  45.7
>    > 10. ae-2.r05.asbnva02.us.bb.gin.  0.0%    10  135.0 109.9 36.6 140.0  39.1
>    > 11. xe-0-9-0-8.r05.asbnva02.us.c  0.0%    10  147.5 125.6 49.4 165.5  41.1
>    > 12. 24.52.112.21                  0.0%    10  158.6 124.0 49.6 161.3  41.5
>    > 13. 24.52.112.42                  0.0%    10  151.0 127.7 52.2 159.0  41.2
>    > 14. ???                          100.0    10    0.0 0.0 0.0   0.0   0.0
>    >
>    >--
>    >Phillip Lynn
>    >Software Engineer III
>    >NetWolves
>    >Phone:813-579-3214
>    >Fax:813-882-0209
>    >Email: phillip.lynn at netwolves.com
>    >www.netwolves.com
>    >
>

None taken,

   We are having issues with our email and loading some web pages. I 
used mtr to try and find if there is a possible connection issue.  I 
just need to understand what is happening , and be able to explain the 
output showing the 80% packet loss .  We are not pointing fingers, just 
looking to understand the issue better.

Thanks

-- 
Phillip Lynn
Software Engineer III
NetWolves
Phone:813-579-3214
Fax:813-882-0209
Email: phillip.lynn at netwolves.com
www.netwolves.com


From math at sizone.org  Fri Jul  8 13:09:19 2016
From: math at sizone.org (Ken Chase)
Date: Fri, 8 Jul 2016 09:09:19 -0400
Subject: packet loss question
In-Reply-To: <CAP-guGWytSZUJ++E6UmHUv21TMJAQLq-A-RdtCuVmLG=RKUfDA@mail.gmail.com>
References: <577EAAD4.5010405@netwolves.com>
 <20160707195247.GO18345@sizone.org>
 <CAP-guGWytSZUJ++E6UmHUv21TMJAQLq-A-RdtCuVmLG=RKUfDA@mail.gmail.com>
Message-ID: <20160708130919.GI18345@sizone.org>

And we know the whole internet observes handling mtu discovery properly
and doesnt just firewall all ICMP because 'hackers'. 

(OP's issue may well be MTU discovery, esp if he's on broadband. Don't have
enough details. I just solved this exact problem a couple weeks ago for a
client with an UBNT ERX by turning on it's MTU hacking feature. Sites that
engaged in ICMP mtu blocking included cnn.com.)

I meant routers are allowed to drop ICMP request packets to themselves, not
the packets to be transitted. I wasnt clear.

/kc


On Thu, Jul 07, 2016 at 11:53:38PM -0400, William Herrin said:
  >On Thu, Jul 7, 2016 at 3:52 PM, Ken Chase <math at sizone.org> wrote:
  >> ICMP is allowed to be dropped by intervening routers. Someone will quote an RFC
  >> at us shortly.
  >
  >Hi Ken,
  >
  >That's not correct. Routers might not generate an ICMP time-exceeded
  >packet for every packet whose TTL reaches zero, but that's not the
  >same thing. Routers dropping ICMP packets in transit would be bad.
  >Protocols like TCP depend on path MTU discovery and path MTU discovery
  >critically depends on ICMP.
  >
  >Regards,
  >Bill Herrin
  >
  >
  >-- 
  >William Herrin ................ herrin at dirtside.com  bill at herrin.us
  >Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

-- 
Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada
Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W.

From mel at beckman.org  Fri Jul  8 14:02:19 2016
From: mel at beckman.org (Mel Beckman)
Date: Fri, 8 Jul 2016 14:02:19 +0000
Subject: packet loss question
In-Reply-To: <577FA41A.8050303@netwolves.com>
References: <577EAAD4.5010405@netwolves.com>
 <20160707195247.GO18345@sizone.org>,<577FA41A.8050303@netwolves.com>
Message-ID: <25577FE1-6366-4D6D-B82E-A779193CB458@beckman.org>

Philip,

Quite often slow Web page loading and email transport -- termed an application-layer problem because basic transport seems unaffected -- is due to DNS problems, particularly reverse DNS for the IP addresses originating your Web queries. If you have non-existent or intermittent IN-ADDR entries for those IPs, the remote Web servers can be timing out if they have older configurations that, for example, do DNS lookups in order to log HTTP requests and block on completion, resulting in timeouts. Use "nslookup x.x.x.x" command line queries (nslookup is on Windows, Mac and UNIX/Linux) to see if you can resolve the public IP addresses your users original queries from. You can find those addresses by visiting http://whatismyip.com from a problem desktop.

A second common cause of app-specific throughput problems, particularly where email is involved, is failed MTU discovery. The standard Internet MTU is 1500 bytes, but sometimes a router misconfiguration or change in encapsulation type along the path through your ISP lowers that to, say, 1492 or 1486 bytes (MTU is in increments of 8). The result is that whenever your web or email client sends a maximum MTU packet, the packet is dropped, resulting in connection impairment. Most HTTP and Email packets are not max-MTU in size, so you get very uneven performance simulating network congestion.

You can force the MTU to a lower number at your border to test this. You typically do this at your firewall; it's a setting on the WAN interface config. Temporarily lower that value dramatically to something like 1440 and see if your problem goes away. If it does, you may need to permanently reduce MTU, so you should try other divisible-by-8 values -- 1492, 1486, 1478, etc -- until you find the largest one that works. I commonly see this when a customer switches ISPs from DSL to Cable. Cable providers are fond of stealing 8 or 16 bytes for their CMT headers in a way that breaks MTU discovery. 

A third frequent application-layer throughout debillitator is IPv6 misconfiguration. If you support IPv6 for your end users, they may be getting directed to IPv6 web or mail servers (which are generally preferred via DNS) but thwarted by IPv6 transport issues, which could be as simple as routing or MTU, or as complex as an invisible 6-over-4 NAT somewhere (such as a your upstream ISP). These problems generally require an IPv6-competent network engineer to resolve, but you can test by disabling IPv6 on your network (which also requires an IPv6-competent network engineer :)

I'm always amazed at how often these three causes are at the root of performance problems. So it's worth investigating each.

 -mel beckman

> On Jul 8, 2016, at 6:02 AM, Phillip Lynn <phillip.lynn at netwolves.com> wrote:
> 
>> On 07/07/2016 03:52 PM, Ken Chase wrote:
>> No offence, but i swear that mtr should come with a license to use it. I get more
>> questions from people accusing us of network issues with mtr in hand...
>> 
>> You shoudlnt care that there's 80% packet loss in the middle of your route, unless
>> you have actual traffic to lag-101.ear3.miami2.level3.net. I suspect you dont.
>> (If you did, you'd have mtr'd to it directly of course.)
>> 
>> As for your second trace, the sudden jump from 0% on 2nd last hop to 100% last
>> hop packetloss seems like firewalling to me. (long discussion about the
>> probabilities of getting 5 0%pl hops in a row and 100% on an unfirewalled
>> endpoint elided. TL;DR: use more packets in your test -i 0.1 -c 100 thanks).
>> 
>> If you have 0% packetloss to your target endpoint, is there an issue here?
>> What caused you to mtr?  0% pl is pretty good. You could play quake 1.0
>> through that pl and ping time. The +20ms ATL<>CHI jump in the route you'd have
>> to take up with einstein/bill nye/$deity.
>> 
>> For the 2nd trace, the 1st hop is your latency issue (plus the big jump from
>> miami<>ashburn, again the limit is c.)
>> 
>> ICMP is allowed to be dropped by intervening routers. Someone will quote an RFC
>> at us shortly.
>> 
>> Mtr without a return route is not that useful in figuring out packetloss
>> because pl requires the packet make it there and back. Pl could be anywhere on
>> the return route, which is probably not symmetrical. The internet stopped
>> being symetrical about 20+ years ago (if it ever even loosely was), so get a friend
>> to send you an mtr to your ip from the farside.
>> 
>> (I remember a project long ago, some cgi-bin (yeah that long ago) that was
>> basically a full-path forward+reverse traceroute you could hit on a selected
>> server at the provider.  Rather handy. not sure if its still a thing, or what it was
>> called.)
>> 
>> /kc
>> 
>> 
>> On Thu, Jul 07, 2016 at 03:17:40PM -0400, Phillip Lynn said:
>>   >Hi all,
>>   >
>>   >  I am writing because I do not understand what is happening.  I ran mtr
>>   >against our email server and www.teco.comand below are the results.  I am
>>   >not a network engineer so I am at a loss.  I think what I am seeing is
>>   >maybe a hand off issue, between Frontier and Level3Miami2. If I am correct
>>   >then what can I do?
>>   >
>>   >  My system is running Centos 6.5 Linux.
>>   >
>>   >Thanks,
>>   >
>>   >Phillip
>>   >
>>   >
>>   >
>>   >(! 1011)-> sudo mtr -r netwolves.securence.com
>>   >HOST: xxxxx at netwolves.comLoss%   Snt   Last   Avg Best  Wrst StDev
>>   >  1. 172.24.109.1                  0.0%    10    0.6 0.6 0.6   0.7   0.0
>>   >  2. lo0-100.TAMPFL-VFTTP-322.gni  0.0%    10    3.2 2.0 1.0   4.3   1.2
>>   >  3. 172.99.44.214                 0.0%    10    4.0 4.9 2.3   6.9   1.5
>>   >  4. ae8---0.scr02.mias.fl.fronti  0.0%    10    9.3 9.1 7.5   9.8   1.0
>>   >  5. ae1---0.cbr01.mias.fl.fronti  0.0%    10    8.9   9.1   7.6 9.7 0.7
>>   >  6. lag-101.ear3.Miami2.Level3.n 80.0%    10    9.0   8.9   8.8 9.0 0.1
>>   >  7. 10ge9-14.core1.mia1.he.net    0.0%    10   14.3 13.0 7.6  18.1   4.3
>>   >  8. 10ge1-1.core1.atl1.he.net     0.0%    10   25.6  33.2 22.4  99.7  23.6
>>   >  9. 10ge10-4.core1.chi1.he.net    0.0%    10   45.6  51.8 45.5  82.7  12.5
>>   > 10. 100ge14-2.core1.msp1.he.net   0.0%    10   53.6  63.9 53.6 125.2  21.8
>>   > 11. t4-2-usi-cr02-mpls-usinterne  0.0%    10   53.2  73.1 53.2 225.6  54.0
>>   > 12. v102.usi-cr04-mtka.usinterne  0.0%    10   53.2  53.9 53.2  55.3   0.6
>>   > 13. netwolves.securence.com       0.0%    10   53.4  53.9 53.4  55.4   0.7
>>   >
>>   >(! 1014)-> sudo mtr -r www.teco.com
>>   >HOST: xxxxx at netwolves.comLoss%   Snt   Last   Avg Best  Wrst StDev
>>   >  1. 172.24.109.1                  0.0%    10    0.6 0.6 0.6   0.7   0.0
>>   >  2. lo0-100.TAMPFL-VFTTP-322.gni  0.0%    10  104.8 81.4 1.1 113.2  43.2
>>   >  3. 172.99.47.198                 0.0%    10  115.0 77.8 2.9 115.0  40.2
>>   >  4. ae7---0.scr01.mias.fl.fronti  0.0%    10  111.1 80.2 8.5 113.5  41.3
>>   >  5. ae0---0.cbr01.mias.fl.fronti  0.0%    10  105.9  82.2   7.6 115.4 33.8
>>   >  6. lag-101.ear3.Miami2.Level3.n 70.0%    10  116.1  80.2   8.5 116.1 62.0
>>   >  7. NTT-level3-80G.Miami.Level3.  0.0%    10  110.0 81.5 9.0 120.3  41.9
>>   >  8. ae-3.r20.miamfl02.us.bb.gin.  0.0%    10  119.8  84.0 10.0 119.8  38.5
>>   >  9. ae-4.r23.asbnva02.us.bb.gin. 10.0%    10  137.4 107.6 30.1 142.7  45.7
>>   > 10. ae-2.r05.asbnva02.us.bb.gin.  0.0%    10  135.0 109.9 36.6 140.0  39.1
>>   > 11. xe-0-9-0-8.r05.asbnva02.us.c  0.0%    10  147.5 125.6 49.4 165.5  41.1
>>   > 12. 24.52.112.21                  0.0%    10  158.6 124.0 49.6 161.3  41.5
>>   > 13. 24.52.112.42                  0.0%    10  151.0 127.7 52.2 159.0  41.2
>>   > 14. ???                          100.0    10    0.0 0.0 0.0   0.0   0.0
>>   >
>>   >--
>>   >Phillip Lynn
>>   >Software Engineer III
>>   >NetWolves
>>   >Phone:813-579-3214
>>   >Fax:813-882-0209
>>   >Email: phillip.lynn at netwolves.com
>>   >www.netwolves.com
>>   >
>> 
> 
> None taken,
> 
>  We are having issues with our email and loading some web pages. I used mtr to try and find if there is a possible connection issue.  I just need to understand what is happening , and be able to explain the output showing the 80% packet loss .  We are not pointing fingers, just looking to understand the issue better.
> 
> Thanks
> 
> -- 
> Phillip Lynn
> Software Engineer III
> NetWolves
> Phone:813-579-3214
> Fax:813-882-0209
> Email: phillip.lynn at netwolves.com
> www.netwolves.com
> 

From bill at herrin.us  Fri Jul  8 16:50:47 2016
From: bill at herrin.us (William Herrin)
Date: Fri, 8 Jul 2016 12:50:47 -0400
Subject: packet loss question
In-Reply-To: <20160708130919.GI18345@sizone.org>
References: <577EAAD4.5010405@netwolves.com>
 <20160707195247.GO18345@sizone.org>
 <CAP-guGWytSZUJ++E6UmHUv21TMJAQLq-A-RdtCuVmLG=RKUfDA@mail.gmail.com>
 <20160708130919.GI18345@sizone.org>
Message-ID: <CAP-guGULN7qB-gQvX5gGBj4w+X4EGkv7jLU1bakTfrqW1x9RQQ@mail.gmail.com>

On Fri, Jul 8, 2016 at 9:09 AM, Ken Chase <math at sizone.org> wrote:
> And we know the whole internet observes handling
> mtu discovery properly
> and doesnt just firewall all ICMP because 'hackers'.
>
> (OP's issue may well be MTU discovery, esp if he's on
> broadband. Don't have
> enough details. I just solved this exact problem a couple
> weeks ago for a
> client with an UBNT ERX by turning on it's MTU hacking
> feature. Sites that
> engaged in ICMP mtu blocking included cnn.com.)

Heh. And because life isn't interesting enough, Amazon AWS has started
defaulting their larger VMs to a 9001 byte interface MTU.


> I meant routers are allowed to drop ICMP request
> packets to themselves, not
> the packets to be transitted. I wasnt clear.

I think you really meant echo-request packets to themselves, right? ;)

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From rod.beck at unitedcablecompany.com  Fri Jul  8 08:50:42 2016
From: rod.beck at unitedcablecompany.com (Rod Beck)
Date: Fri, 8 Jul 2016 08:50:42 +0000
Subject: Interesting Article on Modulation Schemes
In-Reply-To: <20160708023342.GA15545@hezmatt.org>
References: <CAD6AjGTR2__=4PJ5z-jLypMJFD3pt1fJnwdWmbHdDOhL2NC6Tg@mail.gmail.com>
 <CA+HzidRYurrDb4Rasa5JJjjCbVGX4EAhShH4Apf2SZGrhF2zeA@mail.gmail.com>
 <CAD6AjGRehioWt_D_gReG4AYHpRb=c_Gb9VTvZAAeNEamG8EK1w@mail.gmail.com>,
 <20160708023342.GA15545@hezmatt.org>
Message-ID: <DM3PR13MB068780B608D89836C68AE383E43C0@DM3PR13MB0687.namprd13.prod.outlook.com>

The new undersea cable systems are now capable of 18 terabits per fiber pair. It is interesting how combinations of bits are being represented by combinations of optical features.


http://www.lightwaveonline.com/articles/print/volume-30/issue-5/features/which-optical-modulation-scheme-best-fits-my-application.html


Roderick Beck

Director of Global Sales

United Cable Company

www.unitedcablecompany.com<http://www.unitedcablecompany.com>


From jmkeller at houseofzen.org  Fri Jul  8 15:42:00 2016
From: jmkeller at houseofzen.org (jmkeller)
Date: Fri, 08 Jul 2016 11:42:00 -0400
Subject: packet loss question
In-Reply-To: <CAP-guGWytSZUJ++E6UmHUv21TMJAQLq-A-RdtCuVmLG=RKUfDA@mail.gmail.com>
References: <577EAAD4.5010405@netwolves.com>
 <20160707195247.GO18345@sizone.org>
 <CAP-guGWytSZUJ++E6UmHUv21TMJAQLq-A-RdtCuVmLG=RKUfDA@mail.gmail.com>
Message-ID: <f48827827ce43a397ac4a8eccd4caaf7@houseofzen.org>

On 2016-07-07 11:53 PM, William Herrin wrote:
> On Thu, Jul 7, 2016 at 3:52 PM, Ken Chase <math at sizone.org> wrote:
>> ICMP is allowed to be dropped by intervening routers. Someone will 
>> quote an RFC
>> at us shortly.
> 
> Hi Ken,
> 
> That's not correct. Routers might not generate an ICMP time-exceeded
> packet for every packet whose TTL reaches zero, but that's not the
> same thing. Routers dropping ICMP packets in transit would be bad.
> Protocols like TCP depend on path MTU discovery and path MTU discovery
> critically depends on ICMP.
> 
> Regards,
> Bill Herrin


All we are seeing here is control plane filtering by intermediate 
routers.   Unless packet loss numbers start at a router and hops past it 
show the same or higher losses it's not an actual issue with the 
transport path at that hop.   Outside of your own domain of 
administrative control, you can't rely on intermediate routers 
responding to ICMP (either filtered completely or rate limited 
responses).

--
James

From alh-ietf at tndh.net  Fri Jul  8 17:30:14 2016
From: alh-ietf at tndh.net (Tony Hain)
Date: Fri, 8 Jul 2016 10:30:14 -0700
Subject: www.RT.com bad dns record
In-Reply-To: <20160708023342.GA15545@hezmatt.org>
References: <CAD6AjGTR2__=4PJ5z-jLypMJFD3pt1fJnwdWmbHdDOhL2NC6Tg@mail.gmail.com>
 <CA+HzidRYurrDb4Rasa5JJjjCbVGX4EAhShH4Apf2SZGrhF2zeA@mail.gmail.com>
 <CAD6AjGRehioWt_D_gReG4AYHpRb=c_Gb9VTvZAAeNEamG8EK1w@mail.gmail.com>
 <20160708023342.GA15545@hezmatt.org>
Message-ID: <062201d1d93e$634a52b0$29def810$@tndh.net>

Matt Palmer wrote:
> On Thu, Jul 07, 2016 at 06:36:23PM -0700, Ca By wrote:
> > On Thursday, July 7, 2016, Spencer Ryan <sryan at arbor.net> wrote:
> >
> > > Dotted-quad notation is completely valid, and works fine.
> > >
> > > https://en.wikipedia.org/wiki/IPv6_address#Presentation
> > >
> > > http://[::ffff:37.48.108.112] loads fine in my browsers.
> >
> > It may be legit on your network, but people generally don't do
> > that.... If they publish a aaaa record, it usually has a legit v6
address in it.
> 
> That is a legit IPv6 address.  That it won't work on a host that is
IPv6-only is a
> different issue, and one I agree is probably an unexpected and unwanted
> side effect.

This doesn't sound like a host issue, but a broken dns64 implementation. If
it checked the content of the aaaa response for an ::ffff... answer and
treated that as an A-only response, the host would never be involved.

Tony




From cscora at apnic.net  Fri Jul  8 18:01:42 2016
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 9 Jul 2016 04:01:42 +1000 (AEST)
Subject: Weekly Routing Table Report
Message-ID: <20160708180142.ADB8513D98@thyme.apnic.net>

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG,
SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG.

Daily listings are sent to bgp-stats at lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith <pfsinoz at gmail.com>.

Routing Table Report   04:00 +10GMT Sat 09 Jul, 2016

Report Website:     http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              603480
    Prefixes after maximum aggregation (per Origin AS):          218627
    Deaggregation factor:                                          2.76
    Unique aggregates announced (without unneeded subnets):      294607
Total ASes present in the Internet Routing Table:                 54248
    Prefixes per ASN:                                             11.12
Origin-only ASes present in the Internet Routing Table:           36531
Origin ASes announcing only one prefix:                           15524
Transit ASes present in the Internet Routing Table:                6436
Transit-only ASes present in the Internet Routing Table:            167
Average AS path length visible in the Internet Routing Table:       4.3
    Max AS path length visible:                                      54
    Max AS path prepend of ASN ( 55644)                              51
Prefixes from unregistered ASNs in the Routing Table:                55
    Unregistered ASNs in the Routing Table:                          13
Number of 32-bit ASNs allocated by the RIRs:                      14555
Number of 32-bit ASNs visible in the Routing Table:               11281
Prefixes from 32-bit ASNs in the Routing Table:                   44495
Number of bogon 32-bit ASNs visible in the Routing Table:            12
Special use prefixes present in the Routing Table:                    0
Prefixes being announced from unallocated address space:            395
Number of addresses announced to Internet:                   2816498660
    Equivalent to 167 /8s, 224 /16s and 91 /24s
    Percentage of available address space announced:               76.1
    Percentage of allocated address space announced:               76.1
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               98.2
Total number of prefixes smaller than registry allocations:      196469

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                   155921
    Total APNIC prefixes after maximum aggregation:               42694
    APNIC Deaggregation factor:                                    3.65
Prefixes being announced from the APNIC address blocks:          167897
    Unique aggregates announced from the APNIC address blocks:    67994
APNIC Region origin ASes present in the Internet Routing Table:    5186
    APNIC Prefixes per ASN:                                       32.38
APNIC Region origin ASes announcing only one prefix:               1172
APNIC Region transit ASes present in the Internet Routing Table:    931
Average APNIC Region AS path length visible:                        4.3
    Max APNIC Region AS path length visible:                         54
Number of APNIC region 32-bit ASNs visible in the Routing Table:   2202
Number of APNIC addresses announced to Internet:              759303492
    Equivalent to 45 /8s, 66 /16s and 13 /24s
    Percentage of available APNIC address space announced:         88.7

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 63488-64098, 64297-64395, 131072-137529
APNIC Address Blocks     1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
                        49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
                       106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
                       116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
                       123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
                       163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
                       203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
                       222/8, 223/8,

ARIN Region Analysis Summary
----------------------------

Prefixes being announced by ARIN Region ASes:                    182610
    Total ARIN prefixes after maximum aggregation:                89230
    ARIN Deaggregation factor:                                     2.05
Prefixes being announced from the ARIN address blocks:           188256
    Unique aggregates announced from the ARIN address blocks:     88127
ARIN Region origin ASes present in the Internet Routing Table:    16309
    ARIN Prefixes per ASN:                                        11.54
ARIN Region origin ASes announcing only one prefix:                5786
ARIN Region transit ASes present in the Internet Routing Table:    1693
Average ARIN Region AS path length visible:                         3.8
    Max ARIN Region AS path length visible:                          23
Number of ARIN region 32-bit ASNs visible in the Routing Table:    1304
Number of ARIN addresses announced to Internet:              1101096160
    Equivalent to 65 /8s, 161 /16s and 100 /24s
    Percentage of available ARIN address space announced:          58.2

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 62464-63487, 64198-64296, 393216-397212
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  45/8,  47/8,  48/8,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/8,  63/8,  64/8,
                        65/8,  66/8,  67/8,  68/8,  69/8,  70/8,  71/8,
                        72/8,  73/8,  74/8,  75/8,  76/8,  96/8,  97/8,
                        98/8,  99/8, 100/8, 104/8, 107/8, 108/8, 128/8,
                       129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8,
                       137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8,
                       146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8,
                       157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8,
                       165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8,
                       173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8,
                       205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8,
                       216/8,

RIPE Region Analysis Summary
----------------------------

Prefixes being announced by RIPE Region ASes:                    144707
    Total RIPE prefixes after maximum aggregation:                71243
    RIPE Deaggregation factor:                                     2.03
Prefixes being announced from the RIPE address blocks:           154203
    Unique aggregates announced from the RIPE address blocks:     95406
RIPE Region origin ASes present in the Internet Routing Table:    18084
    RIPE Prefixes per ASN:                                         8.53
RIPE Region origin ASes announcing only one prefix:                7824
RIPE Region transit ASes present in the Internet Routing Table:    3003
Average RIPE Region AS path length visible:                         4.4
    Max RIPE Region AS path length visible:                          27
Number of RIPE region 32-bit ASNs visible in the Routing Table:    4912
Number of RIPE addresses announced to Internet:               705483904
    Equivalent to 42 /8s, 12 /16s and 212 /24s
    Percentage of available RIPE address space announced:         102.6

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       59392-61439, 61952-62463, 196608-204287
RIPE Address Blocks      2/8,   5/8,  25/8,  31/8,  37/8,  46/8,  51/8,
                        62/8,  77/8,  78/8,  79/8,  80/8,  81/8,  82/8,
                        83/8,  84/8,  85/8,  86/8,  87/8,  88/8,  89/8,
                        90/8,  91/8,  92/8,  93/8,  94/8,  95/8, 109/8,
                       141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8,
                       193/8, 194/8, 195/8, 212/8, 213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   61574
    Total LACNIC prefixes after maximum aggregation:              12251
    LACNIC Deaggregation factor:                                   5.03
Prefixes being announced from the LACNIC address blocks:          76632
    Unique aggregates announced from the LACNIC address blocks:   36567
LACNIC Region origin ASes present in the Internet Routing Table:   2480
    LACNIC Prefixes per ASN:                                      30.90
LACNIC Region origin ASes announcing only one prefix:               566
LACNIC Region transit ASes present in the Internet Routing Table:   572
Average LACNIC Region AS path length visible:                       4.8
    Max LACNIC Region AS path length visible:                        21
Number of LACNIC region 32-bit ASNs visible in the Routing Table:  2628
Number of LACNIC addresses announced to Internet:             169973568
    Equivalent to 10 /8s, 33 /16s and 151 /24s
    Percentage of available LACNIC address space announced:       101.3

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       61440-61951, 64099-64197, 262144-265628 + ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       191/8, 200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                  14117
    Total AfriNIC prefixes after maximum aggregation:              3199
    AfriNIC Deaggregation factor:                                  4.41
Prefixes being announced from the AfriNIC address blocks:         16097
    Unique aggregates announced from the AfriNIC address blocks:   6156
AfriNIC Region origin ASes present in the Internet Routing Table:   734
    AfriNIC Prefixes per ASN:                                     21.93
AfriNIC Region origin ASes announcing only one prefix:              176
AfriNIC Region transit ASes present in the Internet Routing Table:  172
Average AfriNIC Region AS path length visible:                      4.5
    Max AfriNIC Region AS path length visible:                       19
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:  235
Number of AfriNIC addresses announced to Internet:             80272640
    Equivalent to 4 /8s, 200 /16s and 221 /24s
    Percentage of available AfriNIC address space announced:       79.7

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 154/8, 196/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4538     5558       4191          75   ERX-CERNET-BKB China Education and Rese
 7545     3391        383         246   TPG-INTERNET-AP TPG Telecom Limited, AU
 4766     3151      11143        1116   KIXS-AS-KR Korea Telecom, KR
17974     2944        907          82   TELKOMNET-AS2-AP PT Telekomunikasi Indo
 9829     2557       1484         514   BSNL-NIB National Internet Backbone, IN
 1659     2483       1466          38   ERX-TANET-ASN1 Taiwan Academic Network 
 9808     2143       8761          40   CMNET-GD Guangdong Mobile Communication
 4755     2078        431         239   TATACOMM-AS TATA Communications formerl
 4808     1714       2317         556   CHINA169-BJ China Unicom Beijing Provin
38197     1494         93         274   SUNHK-DATA-AS-AP Sun Network (Hong Kong

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC

ARIN Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
22773     3474       2965         144   ASN-CXA-ALL-CCI-22773-RDC - Cox Communi
 6389     2248       3671          41   BELLSOUTH-NET-BLK - BellSouth.net Inc.,
18566     2197        405         110   MEGAPATH5-US - MegaPath Corporation, US
20115     1928       1950         413   CHARTER-NET-HKY-NC - Charter Communicat
  209     1712       5103         655   CENTURYLINK-US-LEGACY-QWEST - Qwest Com
 6983     1688        849         228   ITCDELTA - Earthlink, Inc., US
30036     1675        336         459   MEDIACOM-ENTERPRISE-BUSINESS - Mediacom
16509     1332       2474         423   AMAZON-02 - Amazon.com, Inc., US
 7018     1325      20045         993   ATT-INTERNET4 - AT&T Services, Inc., US
11492     1314        235         569   CABLEONE - CABLE ONE, INC., US

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN

RIPE Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
39891     3329        169          15   ALJAWWALSTC-AS , SA
20940     2710       1052        1924   AKAMAI-ASN1 , US
34984     1973        327         357   TELLCOM-AS , TR
 8551     1279        377          46   BEZEQ-INTERNATIONAL-AS Bezeqint Interne
12479     1270       1002          46   UNI2-AS , ES
 6849     1148        355          21   UKRTELNET , UA
13188     1091         98          65   BANKINFORM-AS , UA
 8402     1053        544          15   CORBINA-AS Russia, RU
 9198      949        352          26   KAZTELECOM-AS , KZ
 6830      889       2752         463   LGI-UPC formerly known as UPC Broadband

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
10620     3471        542         129   Telmex Colombia S.A., CO
 8151     2264       3346         550   Uninet S.A. de C.V., MX
 7303     1525        949         240   Telecom Argentina S.A., AR
11830     1465        368          50   Instituto Costarricense de Electricidad
 6503     1455        437          55   Axtel, S.A.B. de C.V., MX
 6147     1109        377          27   Telefonica del Peru S.A.A., PE
 3816      999        479         178   COLOMBIA TELECOMUNICACIONES S.A. ESP, C
 7738      994       1882          40   Telemar Norte Leste S.A., BR
11172      907        125          76   Alestra, S. de R.L. de C.V., MX
28573      875       2175         168   CLARO S.A., BR

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC

AfriNIC Region per AS prefix count summary
------------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
24863     1164        402          48   LINKdotNET-AS, EG
37611      645         48           2   Afrihost, ZA
36903      628        316         103   MT-MPLS, MA
36992      525       1235          47   ETISALAT-MISR, EG
 8452      505       1472          15   TE-AS TE-AS, EG
37492      395        234          68   ORANGE-TN, TN
24835      329        594          15   RAYA-AS, EG
29571      299         37          12   CITelecom-AS, CI
 2018      256        327          74   TENET-1, ZA
36947      232        855          15   ALGTEL-AS, DZ

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC

Global Per AS prefix count summary
----------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4538     5558       4191          75   ERX-CERNET-BKB China Education and Rese
22773     3474       2965         144   ASN-CXA-ALL-CCI-22773-RDC - Cox Communi
10620     3471        542         129   Telmex Colombia S.A., CO
 7545     3391        383         246   TPG-INTERNET-AP TPG Telecom Limited, AU
39891     3329        169          15   ALJAWWALSTC-AS , SA
 4766     3151      11143        1116   KIXS-AS-KR Korea Telecom, KR
17974     2944        907          82   TELKOMNET-AS2-AP PT Telekomunikasi Indo
20940     2710       1052        1924   AKAMAI-ASN1 , US
 9829     2557       1484         514   BSNL-NIB National Internet Backbone, IN
 1659     2483       1466          38   ERX-TANET-ASN1 Taiwan Academic Network 

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
10620      3471        3342      Telmex Colombia S.A., CO
22773      3474        3330      ASN-CXA-ALL-CCI-22773-RDC - Cox Communi
39891      3329        3314      ALJAWWALSTC-AS , SA
 7545      3391        3145      TPG-INTERNET-AP TPG Telecom Limited, AU
17974      2944        2862      TELKOMNET-AS2-AP PT Telekomunikasi Indo
 1659      2483        2445      ERX-TANET-ASN1 Taiwan Academic Network 
 6389      2248        2207      BELLSOUTH-NET-BLK - BellSouth.net Inc.,
 9808      2143        2103      CMNET-GD Guangdong Mobile Communication
18566      2197        2087      MEGAPATH5-US - MegaPath Corporation, US
 9829      2557        2043      BSNL-NIB National Internet Backbone, IN

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS  Designation  Network              Transit AS  Description
65001   PRIVATE      5.143.176.0/20       15468       KLGELECS-AS 38, Teatralnaya st
65001   PRIVATE      31.172.192.0/20      15468       KLGELECS-AS 38, Teatralnaya st
65001   PRIVATE      31.172.192.0/21      15468       KLGELECS-AS 38, Teatralnaya st
65001   PRIVATE      31.172.200.0/21      15468       KLGELECS-AS 38, Teatralnaya st
65001   PRIVATE      31.172.208.0/21      15468       KLGELECS-AS 38, Teatralnaya st
65001   PRIVATE      31.172.216.0/21      15468       KLGELECS-AS 38, Teatralnaya st
65000   PRIVATE      31.219.177.0/25       8966       ETISALAT-AS P.O. Box 1150, Dub
65000   PRIVATE      31.219.177.128/25     8966       ETISALAT-AS P.O. Box 1150, Dub
65001   PRIVATE      46.237.32.0/20       13118       ASN-YARTELECOM Verhnevolzhsky 
64502   RESERVED     92.38.215.0/24       12695       DINET-AS , RU

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
23.226.112.0/20      62788     -Reserved AS-, ZZ
23.249.144.0/20      40430     COLO4JAX-AS - colo4jax, LLC, US
27.100.7.0/24        56096     UNKNOWN
41.73.1.0/24         37004     -Reserved AS-, ZZ
41.73.2.0/24         37004     -Reserved AS-, ZZ
41.73.3.0/24         37004     -Reserved AS-, ZZ
41.73.4.0/24         37004     -Reserved AS-, ZZ
41.73.5.0/24         37004     -Reserved AS-, ZZ
41.73.6.0/24         37004     -Reserved AS-, ZZ
41.73.7.0/24         37004     -Reserved AS-, ZZ

Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA

Number of prefixes announced per prefix length (Global)
-------------------------------------------------------

 /1:0        /2:0        /3:0        /4:0        /5:0        /6:0       
 /7:0        /8:16       /9:13      /10:36      /11:100     /12:266     
/13:515     /14:1036    /15:1767    /16:13161   /17:7789    /18:12745   
/19:25299   /20:38225   /21:40061   /22:66775   /23:58267   /24:335755  
/25:565     /26:585     /27:375     /28:49      /29:32      /30:16      
/31:1       /32:31      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
39891     2896          3329      ALJAWWALSTC-AS , SA
22773     2712          3474      ASN-CXA-ALL-CCI-22773-RDC - Cox Communi
18566     2089          2197      MEGAPATH5-US - MegaPath Corporation, US
30036     1489          1675      MEDIACOM-ENTERPRISE-BUSINESS - Mediacom
 6389     1453          2248      BELLSOUTH-NET-BLK - BellSouth.net Inc.,
10620     1382          3471      Telmex Colombia S.A., CO
 6983     1339          1688      ITCDELTA - Earthlink, Inc., US
34984     1256          1973      TELLCOM-AS , TR
11492     1212          1314      CABLEONE - CABLE ONE, INC., US
 6849      968          1148      UKRTELNET , UA

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:1568      2:733       4:21        5:2134      6:31        8:975    
  12:1786     13:39       14:1723     15:45       16:2        17:85     
  18:108      20:49       22:1        23:1657     24:1774     27:2282   
  31:1735     32:67       33:3        34:2        35:5        36:308    
  37:2282     38:1230     39:34       40:94       41:2732     42:446    
  43:1802     44:43       45:2087     46:2516     47:89       49:1163   
  50:884      51:20       52:513      54:338      55:10       56:7      
  57:42       58:1604     59:942      60:350      61:1832     62:1490   
  63:1933     64:4505     65:2176     66:4273     67:2228     68:1115   
  69:3284     70:1252     71:482      72:2023     74:2533     75:344    
  76:375      77:1432     78:1279     79:875      80:1303     81:1375   
  82:965      83:711      84:857      85:1601     86:482      87:1093   
  88:552      89:2041     90:180      91:6066     92:953      93:2401   
  94:2390     95:2491     96:518      97:375      98:948      99:41     
 100:75      101:1073    103:11467   104:2488    105:127     106:427    
 107:1298    108:674     109:2223    110:1273    111:1632    112:1027   
 113:1109    114:1083    115:1643    116:1612    117:1527    118:1979   
 119:1624    120:1267    121:1178    122:2188    123:2027    124:1587   
 125:1744    128:700     129:427     130:414     131:1331    132:620    
 133:176     134:459     135:134     136:379     137:400     138:1738   
 139:296     140:711     141:452     142:646     143:900     144:715    
 145:168     146:887     147:645     148:1363    149:527     150:656    
 151:1020    152:635     153:302     154:632     155:946     156:514    
 157:473     158:406     159:1132    160:501     161:790     162:2331   
 163:912     164:889     165:1051    166:314     167:1162    168:1946   
 169:673     170:1746    171:262     172:594     173:1639    174:757    
 175:734     176:1729    177:4069    178:2257    179:1142    180:2084   
 181:1823    182:1952    183:979     184:832     185:6877    186:2999   
 187:2099    188:2194    189:1732    190:7818    191:1243    192:9058   
 193:5730    194:4443    195:3837    196:1707    197:1049    198:5556   
 199:5751    200:7061    201:3772    202:10077   203:10013   204:4506   
 205:2708    206:2990    207:3105    208:4094    209:3906    210:4260   
 211:2053    212:2745    213:2269    214:870     215:72      216:5843   
 217:1986    218:799     219:629     220:1630    221:862     222:679    
 223:1274   

End of report

From mark at viviotech.net  Fri Jul  8 19:36:32 2016
From: mark at viviotech.net (Mark Keymer)
Date: Fri, 8 Jul 2016 12:36:32 -0700
Subject: DNS resolving issues with AT&T Customer Resolvers
Message-ID: <768031b8-2606-b004-2f3a-8dbc36e4d478@viviotech.net>

Hi all,

I have a client bridgecatalog.com and it seems like customers with AT&T 
are unable to resolve his Domain. Maybe I am just overlooking something 
here but it seems like all should be working. Looking at outside tool 
things look ok too. http://dnscheck.pingdom.com/?domain=bridgecatalog.com

(except the SOA hostmaster at solarek.com e-mailing issues I see now)

Other domains seem to work fine. So it isn't just everything is down. 
One of the end-users I was working with currently has an ip of 
99.7.225.25. Power cycling the modem did not change thing. I also 
flushed DNS. If I change to google's open resolvers things work fine. 
But not with default resolvers to client.

Anyone at AT&T that could check that the resolver's your clients are 
using are able to resolve. (Home / SMB connections, etc)

I am not sure the best way to go about trying to look into this issue if 
other have suggestion I would also appreciate it.

Sincerely,

-- 

Mark Keymer


From eric.kuhnke at gmail.com  Fri Jul  8 20:40:55 2016
From: eric.kuhnke at gmail.com (Eric Kuhnke)
Date: Fri, 8 Jul 2016 13:40:55 -0700
Subject: Interesting Article on Modulation Schemes
In-Reply-To: <DM3PR13MB068780B608D89836C68AE383E43C0@DM3PR13MB0687.namprd13.prod.outlook.com>
References: <CAD6AjGTR2__=4PJ5z-jLypMJFD3pt1fJnwdWmbHdDOhL2NC6Tg@mail.gmail.com>
 <CA+HzidRYurrDb4Rasa5JJjjCbVGX4EAhShH4Apf2SZGrhF2zeA@mail.gmail.com>
 <CAD6AjGRehioWt_D_gReG4AYHpRb=c_Gb9VTvZAAeNEamG8EK1w@mail.gmail.com>
 <20160708023342.GA15545@hezmatt.org>
 <DM3PR13MB068780B608D89836C68AE383E43C0@DM3PR13MB0687.namprd13.prod.outlook.com>
Message-ID: <CAB69EHhwnV5Q38SdV4gevcPSZzetif-YBsTNYFqH2BKort_hrA@mail.gmail.com>

Essentially the transceiver optics are applying the same modulation and
coding that have been used in point-to-point microwave for a long time...
Starting from OOK, up to BPSK and then on to QPSK, 16QAM and possibly 64QAM
with varying levels of FEC.

A singlemode fiber is just an extremely narrow diameter waveguide. Big
difference in frequency between a 71-86 GHz FDD radio pair and optical at
191 to 196 THz.

On Fri, Jul 8, 2016 at 1:50 AM, Rod Beck <rod.beck at unitedcablecompany.com>
wrote:

> The new undersea cable systems are now capable of 18 terabits per fiber
> pair. It is interesting how combinations of bits are being represented by
> combinations of optical features.
>
>
>
> http://www.lightwaveonline.com/articles/print/volume-30/issue-5/features/which-optical-modulation-scheme-best-fits-my-application.html
>
>
> Roderick Beck
>
> Director of Global Sales
>
> United Cable Company
>
> www.unitedcablecompany.com<http://www.unitedcablecompany.com>
>
>

From mark at viviotech.net  Fri Jul  8 20:52:04 2016
From: mark at viviotech.net (Mark Keymer)
Date: Fri, 8 Jul 2016 13:52:04 -0700
Subject: DNS resolving issues with AT&T Customer Resolvers
In-Reply-To: <768031b8-2606-b004-2f3a-8dbc36e4d478@viviotech.net>
References: <768031b8-2606-b004-2f3a-8dbc36e4d478@viviotech.net>
Message-ID: <62cf063b-2166-43a4-b280-3c295c28d702@viviotech.net>

The specific DNS server that are not resolve for my client are.

Primary DNS     68.94.156.9
Secondary DNS     68.94.157.9

If any AT&T people out there that can look into this. Thank you.

Sincerely,

Mark Keymer

On 7/8/2016 12:36 PM, Mark Keymer wrote:
> Hi all,
>
> I have a client bridgecatalog.com and it seems like customers with 
> AT&T are unable to resolve his Domain. Maybe I am just overlooking 
> something here but it seems like all should be working. Looking at 
> outside tool things look ok too. 
> http://dnscheck.pingdom.com/?domain=bridgecatalog.com
>
> (except the SOA hostmaster at solarek.com e-mailing issues I see now)
>
> Other domains seem to work fine. So it isn't just everything is down. 
> One of the end-users I was working with currently has an ip of 
> 99.7.225.25. Power cycling the modem did not change thing. I also 
> flushed DNS. If I change to google's open resolvers things work fine. 
> But not with default resolvers to client.
>
> Anyone at AT&T that could check that the resolver's your clients are 
> using are able to resolve. (Home / SMB connections, etc)
>
> I am not sure the best way to go about trying to look into this issue 
> if other have suggestion I would also appreciate it.
>
> Sincerely,
>


From eric.kuhnke at gmail.com  Fri Jul  8 21:45:31 2016
From: eric.kuhnke at gmail.com (Eric Kuhnke)
Date: Fri, 8 Jul 2016 14:45:31 -0700
Subject: Interesting Article on Modulation Schemes
In-Reply-To: <DM3PR13MB06876DF8CB85565272F7C5FCE43C0@DM3PR13MB0687.namprd13.prod.outlook.com>
References: <CAD6AjGTR2__=4PJ5z-jLypMJFD3pt1fJnwdWmbHdDOhL2NC6Tg@mail.gmail.com>
 <CA+HzidRYurrDb4Rasa5JJjjCbVGX4EAhShH4Apf2SZGrhF2zeA@mail.gmail.com>
 <CAD6AjGRehioWt_D_gReG4AYHpRb=c_Gb9VTvZAAeNEamG8EK1w@mail.gmail.com>
 <20160708023342.GA15545@hezmatt.org>
 <DM3PR13MB068780B608D89836C68AE383E43C0@DM3PR13MB0687.namprd13.prod.outlook.com>
 <CAB69EHhwnV5Q38SdV4gevcPSZzetif-YBsTNYFqH2BKort_hrA@mail.gmail.com>
 <DM3PR13MB06876DF8CB85565272F7C5FCE43C0@DM3PR13MB0687.namprd13.prod.outlook.com>
Message-ID: <CAB69EHh-zL4OmMTE5GBVTeunCkbA+McXwa_sZ6FwT0vh+PFEHw@mail.gmail.com>

Not just "talking about" 16QAM is in active use for subsea high capacity
channels...  Both Xtera and Infinera are shipping DWDM terminals for
installation at cable landing stations that use 16QAM for 100/200/400 Gbps
superchannels.

http://www.xtera.com/home/technology/100g-and-400g/

http://www.xtera.com/home/products/nu-wave-optima/

Unless I'm grossly mistaken, Alcatel-Lucent and Huawei as well.



On Fri, Jul 8, 2016 at 2:24 PM, Rod Beck <rod.beck at unitedcablecompany.com>
wrote:

> Apparently 40 gigs is the limit of simple laser flash equals 1, no flash
> equals 0. Above that threshold the signal becomes larger than an ITU 50
> gigahertz channel. Most new undersea cables are using QPSK or 8 QAM and
> talking about 16 QAM.
>
>
> This companion piece explains it:
> http://digital.lightwaveonline.com/lightwave/20130708/?pm=1&u1=friend&pg=19#pg19
> .
>
>
> - Roderick.
>
>
> ------------------------------
> *From:* Eric Kuhnke <eric.kuhnke at gmail.com>
> *Sent:* Friday, July 8, 2016 10:40 PM
> *To:* Rod Beck
> *Cc:* nanog at nanog.org
> *Subject:* Re: Interesting Article on Modulation Schemes
>
> Essentially the transceiver optics are applying the same modulation and
> coding that have been used in point-to-point microwave for a long time...
> Starting from OOK, up to BPSK and then on to QPSK, 16QAM and possibly 64QAM
> with varying levels of FEC.
>
> A singlemode fiber is just an extremely narrow diameter waveguide. Big
> difference in frequency between a 71-86 GHz FDD radio pair and optical at
> 191 to 196 THz.
>
> On Fri, Jul 8, 2016 at 1:50 AM, Rod Beck <rod.beck at unitedcablecompany.com>
> wrote:
>
>> The new undersea cable systems are now capable of 18 terabits per fiber
>> pair. It is interesting how combinations of bits are being represented by
>> combinations of optical features.
>>
>>
>>
>> http://www.lightwaveonline.com/articles/print/volume-30/issue-5/features/which-optical-modulation-scheme-best-fits-my-application.html
>>
>>
>> Roderick Beck
>>
>> Director of Global Sales
>>
>> United Cable Company
>>
>> www.unitedcablecompany.com<http://www.unitedcablecompany.com>
>>
>>
>

From hdemby at email.unc.edu  Fri Jul  8 19:55:29 2016
From: hdemby at email.unc.edu (Hiawatha Demby)
Date: Fri, 8 Jul 2016 15:55:29 -0400
Subject: DNS resolving issues with AT&T Customer Resolvers
In-Reply-To: <768031b8-2606-b004-2f3a-8dbc36e4d478@viviotech.net>
References: <768031b8-2606-b004-2f3a-8dbc36e4d478@viviotech.net>
Message-ID: <c8cf4de5-bd9b-abbb-d9b5-bd0a0a2817fd@email.unc.edu>

C:\Users>nslookup bridgecatalog.com
Server:  UnKnown
Address:  192.168.0.1

DNS request timed out.
     timeout was 2 seconds.
DNS request timed out.
     timeout was 2 seconds.
DNS request timed out.
     timeout was 2 seconds.
DNS request timed out.
     timeout was 2 seconds.
*** Request to UnKnown timed-out

C:\Users>nslookup bridgecatalog.com 8.8.8.8
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

DNS request timed out.
     timeout was 2 seconds.
DNS request timed out.
     timeout was 2 seconds.
DNS request timed out.
     timeout was 2 seconds.
DNS request timed out.
     timeout was 2 seconds.
*** Request to google-public-dns-a.google.com timed-out

C:\Users>nslookup bridgecatalog.com 68.94.156.15
Server:  dns156r15.sbcglobal.net
Address:  68.94.156.15

DNS request timed out.
     timeout was 2 seconds.
DNS request timed out.
     timeout was 2 seconds.
DNS request timed out.
     timeout was 2 seconds.
DNS request timed out.
     timeout was 2 seconds.
*** Request to dns156r15.sbcglobal.net timed-out

Looks like the AT&T server are unavailable and the host is unresolvable 
on my end.

On 7/8/2016 3:36 PM, Mark Keymer wrote:
> Hi all,
>
> I have a client bridgecatalog.com and it seems like customers with 
> AT&T are unable to resolve his Domain. Maybe I am just overlooking 
> something here but it seems like all should be working. Looking at 
> outside tool things look ok too. 
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdnscheck.pingdom.com%2f%3fdomain%3dbridgecatalog.com&data=01%7c01%7chdemby%40email.unc.edu%7ca1a111c28862421e835f08d3a7672759%7c58b3d54f16c942d3af081fcabd095666%7c1&sdata=OhVtZs8EqOGddhZh26uvcnMLBBZ5CiUTdeX9FXy5twk%3d
>
> (except the SOA hostmaster at solarek.com e-mailing issues I see now)
>
> Other domains seem to work fine. So it isn't just everything is down. 
> One of the end-users I was working with currently has an ip of 
> 99.7.225.25. Power cycling the modem did not change thing. I also 
> flushed DNS. If I change to google's open resolvers things work fine. 
> But not with default resolvers to client.
>
> Anyone at AT&T that could check that the resolver's your clients are 
> using are able to resolve. (Home / SMB connections, etc)
>
> I am not sure the best way to go about trying to look into this issue 
> if other have suggestion I would also appreciate it.
>
> Sincerely,
>


From rod.beck at unitedcablecompany.com  Fri Jul  8 21:24:14 2016
From: rod.beck at unitedcablecompany.com (Rod Beck)
Date: Fri, 8 Jul 2016 21:24:14 +0000
Subject: Interesting Article on Modulation Schemes
In-Reply-To: <CAB69EHhwnV5Q38SdV4gevcPSZzetif-YBsTNYFqH2BKort_hrA@mail.gmail.com>
References: <CAD6AjGTR2__=4PJ5z-jLypMJFD3pt1fJnwdWmbHdDOhL2NC6Tg@mail.gmail.com>
 <CA+HzidRYurrDb4Rasa5JJjjCbVGX4EAhShH4Apf2SZGrhF2zeA@mail.gmail.com>
 <CAD6AjGRehioWt_D_gReG4AYHpRb=c_Gb9VTvZAAeNEamG8EK1w@mail.gmail.com>
 <20160708023342.GA15545@hezmatt.org>
 <DM3PR13MB068780B608D89836C68AE383E43C0@DM3PR13MB0687.namprd13.prod.outlook.com>,
 <CAB69EHhwnV5Q38SdV4gevcPSZzetif-YBsTNYFqH2BKort_hrA@mail.gmail.com>
Message-ID: <DM3PR13MB06876DF8CB85565272F7C5FCE43C0@DM3PR13MB0687.namprd13.prod.outlook.com>

Apparently 40 gigs is the limit of simple laser flash equals 1, no flash equals 0. Above that threshold the signal becomes larger than an ITU 50 gigahertz channel. Most new undersea cables are using QPSK or 8 QAM and talking about 16 QAM.


This companion piece explains it: http://digital.lightwaveonline.com/lightwave/20130708/?pm=1&u1=friend&pg=19#pg19.


- Roderick.


________________________________
From: Eric Kuhnke <eric.kuhnke at gmail.com>
Sent: Friday, July 8, 2016 10:40 PM
To: Rod Beck
Cc: nanog at nanog.org
Subject: Re: Interesting Article on Modulation Schemes

Essentially the transceiver optics are applying the same modulation and coding that have been used in point-to-point microwave for a long time...   Starting from OOK, up to BPSK and then on to QPSK, 16QAM and possibly 64QAM with varying levels of FEC.

A singlemode fiber is just an extremely narrow diameter waveguide. Big difference in frequency between a 71-86 GHz FDD radio pair and optical at 191 to 196 THz.

On Fri, Jul 8, 2016 at 1:50 AM, Rod Beck <rod.beck at unitedcablecompany.com<mailto:rod.beck at unitedcablecompany.com>> wrote:
The new undersea cable systems are now capable of 18 terabits per fiber pair. It is interesting how combinations of bits are being represented by combinations of optical features.


http://www.lightwaveonline.com/articles/print/volume-30/issue-5/features/which-optical-modulation-scheme-best-fits-my-application.html


Roderick Beck

Director of Global Sales

United Cable Company

www.unitedcablecompany.com<http://www.unitedcablecompany.com><http://www.unitedcablecompany.com>



From stephen.strowes at gmail.com  Fri Jul  8 21:59:39 2016
From: stephen.strowes at gmail.com (Stephen Strowes)
Date: Fri, 8 Jul 2016 14:59:39 -0700
Subject: NAT firewall for IPv6?
In-Reply-To: <1889bab6-bf5c-5c76-1626-51b1fb91edd2@rollernet.us>
References: <CAMJ2qG0_Z4yArNt6jc10c+OhRSV-2Gv0k0thNdJD9WSuFaA-Ww@mail.gmail.com>
 <1889bab6-bf5c-5c76-1626-51b1fb91edd2@rollernet.us>
Message-ID: <CAJbMJ32HO0rY-4G7aZDvmP5cbeFM-0jBBDLfCLGn9Weuw9M37g@mail.gmail.com>

Wonderfully crafted, too. Great work.

S.


On 5 July 2016 at 15:39, Seth Mattinen <sethm at rollernet.us> wrote:

> On 7/1/16 19:28, Edgar Carver wrote:
>
>> Hello NANOG community. I was directed here by our network administrator
>> since she is on vacation. Luckily, I minored in Computer Science so I have
>> some familiarity.
>>
>>
> This is not legit, ya'll are being trolled.
>
> ~Seth
>

From rod.beck at unitedcablecompany.com  Fri Jul  8 22:15:15 2016
From: rod.beck at unitedcablecompany.com (Rod Beck)
Date: Fri, 8 Jul 2016 22:15:15 +0000
Subject: Interesting Article on Modulation Schemes
In-Reply-To: <CAB69EHh-zL4OmMTE5GBVTeunCkbA+McXwa_sZ6FwT0vh+PFEHw@mail.gmail.com>
References: <CAD6AjGTR2__=4PJ5z-jLypMJFD3pt1fJnwdWmbHdDOhL2NC6Tg@mail.gmail.com>
 <CA+HzidRYurrDb4Rasa5JJjjCbVGX4EAhShH4Apf2SZGrhF2zeA@mail.gmail.com>
 <CAD6AjGRehioWt_D_gReG4AYHpRb=c_Gb9VTvZAAeNEamG8EK1w@mail.gmail.com>
 <20160708023342.GA15545@hezmatt.org>
 <DM3PR13MB068780B608D89836C68AE383E43C0@DM3PR13MB0687.namprd13.prod.outlook.com>
 <CAB69EHhwnV5Q38SdV4gevcPSZzetif-YBsTNYFqH2BKort_hrA@mail.gmail.com>
 <DM3PR13MB06876DF8CB85565272F7C5FCE43C0@DM3PR13MB0687.namprd13.prod.outlook.com>,
 <CAB69EHh-zL4OmMTE5GBVTeunCkbA+McXwa_sZ6FwT0vh+PFEHw@mail.gmail.com>
Message-ID: <DM3PR13MB0687E70010BEA0C30176648FE43C0@DM3PR13MB0687.namprd13.prod.outlook.com>

I don't see wide spread deployment. The most recently built TransAtlantic cable is Aquacomms It is QPSK and 130 100 gig waves per pair. Does one really need more? C-Lion, the new Finland/Germany cable is 18 terabits per fiber pair. I think that is 8 QAM. Is that a representative sample?  I don't know. It is certainly a small sample and hence could be highly contained by random error. Since so many ISPs dropped their Layer 2 networks in favor of buying cheap transit, the market for 100 gig waves is limited to Tier 1 ISPs, a few huge hosting companies, and the public Web giants in shopping, social media. I have been told that the video streaming guys like Netflix are more similar to Akamai than Telia. Dense local footprints.


Bottom line. I don't think the demand is sufficient or the interface costs on the customer side sufficiently low. Could be wrong about both.


Regards,


Roderick.


________________________________
From: Eric Kuhnke <eric.kuhnke at gmail.com>
Sent: Friday, July 8, 2016 11:45 PM
To: Rod Beck
Cc: nanog at nanog.org
Subject: Re: Interesting Article on Modulation Schemes

Not just "talking about" 16QAM is in active use for subsea high capacity channels...  Both Xtera and Infinera are shipping DWDM terminals for installation at cable landing stations that use 16QAM for 100/200/400 Gbps superchannels.

http://www.xtera.com/home/technology/100g-and-400g/
100G and 400G Coherent | Xtera<http://www.xtera.com/home/technology/100g-and-400g/>
www.xtera.com
Xtera's coherent technology support 100G, 400G and beyond optical channel rates for high-capacity backbone networks.



http://www.xtera.com/home/products/nu-wave-optima/

Unless I'm grossly mistaken, Alcatel-Lucent and Huawei as well.



On Fri, Jul 8, 2016 at 2:24 PM, Rod Beck <rod.beck at unitedcablecompany.com<mailto:rod.beck at unitedcablecompany.com>> wrote:

Apparently 40 gigs is the limit of simple laser flash equals 1, no flash equals 0. Above that threshold the signal becomes larger than an ITU 50 gigahertz channel. Most new undersea cables are using QPSK or 8 QAM and talking about 16 QAM.


This companion piece explains it: http://digital.lightwaveonline.com/lightwave/20130708/?pm=1&u1=friend&pg=19#pg19.


- Roderick.


________________________________
From: Eric Kuhnke <eric.kuhnke at gmail.com<mailto:eric.kuhnke at gmail.com>>
Sent: Friday, July 8, 2016 10:40 PM
To: Rod Beck
Cc: nanog at nanog.org<mailto:nanog at nanog.org>
Subject: Re: Interesting Article on Modulation Schemes

Essentially the transceiver optics are applying the same modulation and coding that have been used in point-to-point microwave for a long time...   Starting from OOK, up to BPSK and then on to QPSK, 16QAM and possibly 64QAM with varying levels of FEC.

A singlemode fiber is just an extremely narrow diameter waveguide. Big difference in frequency between a 71-86 GHz FDD radio pair and optical at 191 to 196 THz.

On Fri, Jul 8, 2016 at 1:50 AM, Rod Beck <rod.beck at unitedcablecompany.com<mailto:rod.beck at unitedcablecompany.com>> wrote:
The new undersea cable systems are now capable of 18 terabits per fiber pair. It is interesting how combinations of bits are being represented by combinations of optical features.


http://www.lightwaveonline.com/articles/print/volume-30/issue-5/features/which-optical-modulation-scheme-best-fits-my-application.html


Roderick Beck

Director of Global Sales

United Cable Company

www.unitedcablecompany.com<http://www.unitedcablecompany.com><http://www.unitedcablecompany.com>




From javier at advancedmachines.us  Fri Jul  8 22:53:24 2016
From: javier at advancedmachines.us (Javier J)
Date: Fri, 8 Jul 2016 18:53:24 -0400
Subject: Leap Second planned for 2016
In-Reply-To: <c8258e7b-d53c-6a31-b2a4-57b44cbc79e6@gmail.com>
References: <c8258e7b-d53c-6a31-b2a4-57b44cbc79e6@gmail.com>
Message-ID: <CA+M5dWbZM1kQx1dG6Ba_cEYOyH=f9X5vhuc6bmM6s8pCdbGx=g@mail.gmail.com>

> Time to start preparing


Unless you are running something that can't handle leap seconds what do you
really need to prepare for?



On Thu, Jul 7, 2016 at 12:59 PM, Andrew Gallo <akg1330 at gmail.com> wrote:

> Looks like we'll have another second in 2016:
> http://www.space.com/33361-leap-second-2016-atomic-clocks.html
>
>
> Time to start preparing
>
>

From mcdonald.richards at gmail.com  Fri Jul  8 23:00:10 2016
From: mcdonald.richards at gmail.com (McDonald Richards)
Date: Fri, 8 Jul 2016 16:00:10 -0700
Subject: L3 over OTN vs pure IP/MPLS
Message-ID: <CACrsH-5+R2D0CMRzQezrDD9bWe10SYNQ7HhfCXTxpb25=vWynA@mail.gmail.com>

This sounds like somebody is trying to sell you equipment.

Can you elaborate on the degradation you're experiencing? Are you sure
you're utilizing all your link bandwidth effectively and packets are not
being stuck in large buffers or crammed into a starving forwarding class?



On Thu, Jul 7, 2016 at 7:43 PM, Manuel Mar?n <mmg at transtelco.net> wrote:

> Dear Nanog community
>
> We are currently experimenting TCP degradation issues in some metro markets
> where there are multiple POPs and the IP packets have to pass multiple L3
> access devices (routers) before reaching the core router. The more L3 hops
> that it goes through the more degradation we see in the Internet service.
> L3 routers have the capacity in terms of pps and BW and we are using just a
> small percentage of that capacity but anyway the service is degraded (No
> CRC/Input errors in the links). A couple of vendors are recommending using
> OTN or MPLS-TP to backhaul the connections from the access to the core but
> obviously deploying OTN means a considerable amount of capex. The
> flexibility and simplicity of the L3 based access network is great but
> given the performance issues we are experimenting I would appreciate if you
> can share your experience/recommendation with either OTN or MPLS-TP. Does
> it really make sense to use a OTN/Photonic layer to backhaul the L3
> connections in a metro network?
>
> Your input is greatly appreciated
>
> Thanks and have a great day
>

From trelane at trelane.net  Fri Jul  8 23:09:57 2016
From: trelane at trelane.net (Andrew Kirch)
Date: Fri, 8 Jul 2016 19:09:57 -0400
Subject: Leap Second planned for 2016
In-Reply-To: <CA+M5dWbZM1kQx1dG6Ba_cEYOyH=f9X5vhuc6bmM6s8pCdbGx=g@mail.gmail.com>
References: <c8258e7b-d53c-6a31-b2a4-57b44cbc79e6@gmail.com>
 <CA+M5dWbZM1kQx1dG6Ba_cEYOyH=f9X5vhuc6bmM6s8pCdbGx=g@mail.gmail.com>
Message-ID: <CALA5tJLrq3O3NQoN1dLyRcBcJkiAWy0gLLBT8Wm528XX3oH7gg@mail.gmail.com>

Its a whole extra second you can spend doing something awesome. You have to
plan now!

On Friday, July 8, 2016, Javier J <javier at advancedmachines.us> wrote:

> > Time to start preparing
>
>
> Unless you are running something that can't handle leap seconds what do you
> really need to prepare for?
>
>
>
> On Thu, Jul 7, 2016 at 12:59 PM, Andrew Gallo <akg1330 at gmail.com
> <javascript:;>> wrote:
>
> > Looks like we'll have another second in 2016:
> > http://www.space.com/33361-leap-second-2016-atomic-clocks.html
> >
> >
> > Time to start preparing
> >
> >
>

From hal at buzcom.net  Fri Jul  8 23:14:31 2016
From: hal at buzcom.net (Hal Ponton)
Date: Sat, 09 Jul 2016 00:14:31 +0100
Subject: Leap Second planned for 2016
In-Reply-To: <CALA5tJLrq3O3NQoN1dLyRcBcJkiAWy0gLLBT8Wm528XX3oH7gg@mail.gmail.com>
References: <c8258e7b-d53c-6a31-b2a4-57b44cbc79e6@gmail.com>
 <CA+M5dWbZM1kQx1dG6Ba_cEYOyH=f9X5vhuc6bmM6s8pCdbGx=g@mail.gmail.com>
 <CALA5tJLrq3O3NQoN1dLyRcBcJkiAWy0gLLBT8Wm528XX3oH7gg@mail.gmail.com>
Message-ID: <578033D7.8080409@buzcom.net>

I'll just leave this here :)

http://spendyourleapsecondhere.com/
-- 
--
Regards,

Hal Ponton
Senior Network Engineer

Buzcom / FibreWiFi




> Andrew Kirch <mailto:trelane at trelane.net>
> 9 July 2016 at 00:09
> Its a whole extra second you can spend doing something awesome. You 
> have to
> plan now!
>
> Javier J <mailto:javier at advancedmachines.us>
> 8 July 2016 at 23:53
>> Time to start preparing
>
>
> Unless you are running something that can't handle leap seconds what do you
> really need to prepare for?
>
>
>
> On Thu, Jul 7, 2016 at 12:59 PM, Andrew Gallo<akg1330 at gmail.com>  wrote:
>
>> Looks like we'll have another second in 2016:
>> http://www.space.com/33361-leap-second-2016-atomic-clocks.html
>>
>>
>> Time to start preparing
>>
>>
> Andrew Gallo <mailto:akg1330 at gmail.com>
> 7 July 2016 at 17:59
> Looks like we'll have another second in 2016:
> http://www.space.com/33361-leap-second-2016-atomic-clocks.html
>
>
> Time to start preparing
>


From jared at puck.nether.net  Fri Jul  8 23:27:04 2016
From: jared at puck.nether.net (Jared Mauch)
Date: Fri, 8 Jul 2016 19:27:04 -0400
Subject: Leap Second planned for 2016
In-Reply-To: <CA+M5dWbZM1kQx1dG6Ba_cEYOyH=f9X5vhuc6bmM6s8pCdbGx=g@mail.gmail.com>
References: <c8258e7b-d53c-6a31-b2a4-57b44cbc79e6@gmail.com>
 <CA+M5dWbZM1kQx1dG6Ba_cEYOyH=f9X5vhuc6bmM6s8pCdbGx=g@mail.gmail.com>
Message-ID: <310A3651-64F5-4B79-9951-C0208A1C1A82@puck.nether.net>

Time is actually harder than it seems. Many bits of software break in unexpected ways. Expect the unexpected. 

Jared Mauch

On Jul 8, 2016, at 6:53 PM, Javier J <javier at advancedmachines.us> wrote:

>> Time to start preparing
> 
> 
> Unless you are running something that can't handle leap seconds what do you
> really need to prepare for?
> 
> 
> 
>> On Thu, Jul 7, 2016 at 12:59 PM, Andrew Gallo <akg1330 at gmail.com> wrote:
>> 
>> Looks like we'll have another second in 2016:
>> http://www.space.com/33361-leap-second-2016-atomic-clocks.html
>> 
>> 
>> Time to start preparing
>> 
>> 


From jeremy at eff.org  Fri Jul  8 23:35:21 2016
From: jeremy at eff.org (Jeremy Gillula)
Date: Fri, 8 Jul 2016 16:35:21 -0700
Subject: An open letter to security researchers and practitioners
Message-ID: <578038B9.40504@eff.org>

An open letter to security researchers and practitioners:

We need you to take a stand to protect security researchers who report
defects in browsers, before it's too late.

Earlier this month, the World Wide Web Consortium's Encrypted Media
Extensions (EME) spec progressed to Draft Recommendation phase. This is
a controversial standard for transmitting DRM-encumbered videos, and it
marks the very first time that the W3C has attempted to standardize a
DRM system.

This means that for the first time, W3C standards for browsers will fall
under laws like the DMCA (and its international equivalents, which the
US Trade Representative has spread all over the world). These laws allow
companies to threaten security researchers who disclose vulnerabilities
in DRM systems, on the grounds that these disclosures make it easier to
figure out how to bypass the DRM.

Last summer, the Copyright Office heard from security researchers about
the effect that DRM has on their work; those filings detail showstopper
bugs in consumer devices, cars, agricultural equipment, medical
implants, and voting machines that researchers felt they couldn't
readily publish about, lest they face punitive lawsuits from the
companies they embarrassed.

EFF has asked the W3C to take a minimal step to insulate their
stakeholders from the legal fallout from the inclusion of DRM in their
standards. Our proposal asks the W3C to bind its members to legal
promises not to use the DMCA or laws like it against security
researchers or implementers.

https://www.eff.org/deeplinks/2016/06/w3c-eme-and-eff-frequently-asked-questions

So far, the W3C executive has failed to act on this proposal, despite
diverse support from a number of W3C members.

We are hosting an open letter from security, privacy and technology
experts to the W3C's director, Tim Berners-Lee; and its CEO, Jeff Jaffe,
asking them to make any further work on EME contingent on adopting rules
to protect the open web from these bad laws.

https://www.eff.org/deeplinks/2016/03/security-researchers-tell-w3c-protect-researchers-who-investigate-browsers

Will you sign this letter? Some of security's leading lights have
already put their names to it. We can't afford to make widely used tools
like browsers off-limits to security research and disclosure, especially
not as HTML5 is being positioned as a UI environment to replace apps as
the primary way of interacting with sensors, actuators, embedded systems
and the whole Internet of Things.

If you're willing to sign on, please send an email to cory at eff.org with
your country of residence and your institutional affiliation (if any).

Thank you,

Cory Doctorow
Apollo 1201 Project
Electronic Frontier Foundation


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160708/d95ca619/attachment.pgp>

From marine64 at gmail.com  Fri Jul  8 23:46:14 2016
From: marine64 at gmail.com (Brian Henson)
Date: Fri, 8 Jul 2016 19:46:14 -0400
Subject: DNS resolving issues with AT&T Customer Resolvers
In-Reply-To: <c8cf4de5-bd9b-abbb-d9b5-bd0a0a2817fd@email.unc.edu>
References: <768031b8-2606-b004-2f3a-8dbc36e4d478@viviotech.net>
 <c8cf4de5-bd9b-abbb-d9b5-bd0a0a2817fd@email.unc.edu>
Message-ID: <CAE_vMvex2E4Bw=BfOdVgw5osW0n93-eLf5iq7eurirxLSK9i5g@mail.gmail.com>

Resolves here in Ohio and using 8.8.8.8 anycast address. on Timewarner

On Fri, Jul 8, 2016 at 3:55 PM, Hiawatha Demby <hdemby at email.unc.edu> wrote:

> C:\Users>nslookup bridgecatalog.com
> Server:  UnKnown
> Address:  192.168.0.1
>
> DNS request timed out.
>     timeout was 2 seconds.
> DNS request timed out.
>     timeout was 2 seconds.
> DNS request timed out.
>     timeout was 2 seconds.
> DNS request timed out.
>     timeout was 2 seconds.
> *** Request to UnKnown timed-out
>
> C:\Users>nslookup bridgecatalog.com 8.8.8.8
> Server:  google-public-dns-a.google.com
> Address:  8.8.8.8
>
> DNS request timed out.
>     timeout was 2 seconds.
> DNS request timed out.
>     timeout was 2 seconds.
> DNS request timed out.
>     timeout was 2 seconds.
> DNS request timed out.
>     timeout was 2 seconds.
> *** Request to google-public-dns-a.google.com timed-out
>
> C:\Users>nslookup bridgecatalog.com 68.94.156.15
> Server:  dns156r15.sbcglobal.net
> Address:  68.94.156.15
>
> DNS request timed out.
>     timeout was 2 seconds.
> DNS request timed out.
>     timeout was 2 seconds.
> DNS request timed out.
>     timeout was 2 seconds.
> DNS request timed out.
>     timeout was 2 seconds.
> *** Request to dns156r15.sbcglobal.net timed-out
>
> Looks like the AT&T server are unavailable and the host is unresolvable on
> my end.
>
> On 7/8/2016 3:36 PM, Mark Keymer wrote:
>
>> Hi all,
>>
>> I have a client bridgecatalog.com and it seems like customers with AT&T
>> are unable to resolve his Domain. Maybe I am just overlooking something
>> here but it seems like all should be working. Looking at outside tool
>> things look ok too.
>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdnscheck.pingdom.com%2f%3fdomain%3dbridgecatalog.com&data=01%7c01%7chdemby%40email.unc.edu%7ca1a111c28862421e835f08d3a7672759%7c58b3d54f16c942d3af081fcabd095666%7c1&sdata=OhVtZs8EqOGddhZh26uvcnMLBBZ5CiUTdeX9FXy5twk%3d
>>
>> (except the SOA hostmaster at solarek.com e-mailing issues I see now)
>>
>> Other domains seem to work fine. So it isn't just everything is down. One
>> of the end-users I was working with currently has an ip of 99.7.225.25.
>> Power cycling the modem did not change thing. I also flushed DNS. If I
>> change to google's open resolvers things work fine. But not with default
>> resolvers to client.
>>
>> Anyone at AT&T that could check that the resolver's your clients are
>> using are able to resolve. (Home / SMB connections, etc)
>>
>> I am not sure the best way to go about trying to look into this issue if
>> other have suggestion I would also appreciate it.
>>
>> Sincerely,
>>
>>
>

From saku at ytti.fi  Fri Jul  8 23:47:51 2016
From: saku at ytti.fi (Saku Ytti)
Date: Sat, 9 Jul 2016 02:47:51 +0300
Subject: Leap Second planned for 2016
In-Reply-To: <310A3651-64F5-4B79-9951-C0208A1C1A82@puck.nether.net>
References: <c8258e7b-d53c-6a31-b2a4-57b44cbc79e6@gmail.com>
 <CA+M5dWbZM1kQx1dG6Ba_cEYOyH=f9X5vhuc6bmM6s8pCdbGx=g@mail.gmail.com>
 <310A3651-64F5-4B79-9951-C0208A1C1A82@puck.nether.net>
Message-ID: <CAAeewD_kxj2g4=XaNk8jj5DCp8hEhtNY5JhAQesCyYGVy8Opew@mail.gmail.com>

On 9 July 2016 at 02:27, Jared Mauch <jared at puck.nether.net> wrote:
> Time is actually harder than it seems. Many bits of software break in unexpected ways. Expect the unexpected.

Aye. How many have written code like this:

start = time();
do_something();
elapsed = time() - start;

Virtually all code dealing with passage of time assumes time moves
only forward, I'm amazed we don't see more issues during leap seconds.
Portable monotonic time isn't even available in many languages
standard libraries.

Hopefully they'll decide in 2023 finally to get rid of leap seconds
from UTC. Then GPS_TIME, TAI and UTC are all same with different
static offset.
-- 
  ++ytti

From mark at viviotech.net  Sat Jul  9 00:09:34 2016
From: mark at viviotech.net (Mark Keymer)
Date: Fri, 8 Jul 2016 17:09:34 -0700
Subject: DNS resolving issues with AT&T Customer Resolvers
In-Reply-To: <CAE_vMvex2E4Bw=BfOdVgw5osW0n93-eLf5iq7eurirxLSK9i5g@mail.gmail.com>
References: <768031b8-2606-b004-2f3a-8dbc36e4d478@viviotech.net>
 <c8cf4de5-bd9b-abbb-d9b5-bd0a0a2817fd@email.unc.edu>
 <CAE_vMvex2E4Bw=BfOdVgw5osW0n93-eLf5iq7eurirxLSK9i5g@mail.gmail.com>
Message-ID: <8147fc27-1bb3-602f-121a-e1a8d59585e7@viviotech.net>

Hi,

For my tested it did work with google but not several internal AT&T 
resolvers. A ticket has been created in one of the AT&T NOC departments. 
(after a 4 hour phone call) and I hope they can get to this soon.

Sincerely,

Mark Keymer

On 7/8/2016 4:46 PM, Brian Henson wrote:
> Resolves here in Ohio and using 8.8.8.8 anycast address. on Timewarner
>
> On Fri, Jul 8, 2016 at 3:55 PM, Hiawatha Demby <hdemby at email.unc.edu> wrote:
>
>> C:\Users>nslookup bridgecatalog.com
>> Server:  UnKnown
>> Address:  192.168.0.1
>>
>> DNS request timed out.
>>      timeout was 2 seconds.
>> DNS request timed out.
>>      timeout was 2 seconds.
>> DNS request timed out.
>>      timeout was 2 seconds.
>> DNS request timed out.
>>      timeout was 2 seconds.
>> *** Request to UnKnown timed-out
>>
>> C:\Users>nslookup bridgecatalog.com 8.8.8.8
>> Server:  google-public-dns-a.google.com
>> Address:  8.8.8.8
>>
>> DNS request timed out.
>>      timeout was 2 seconds.
>> DNS request timed out.
>>      timeout was 2 seconds.
>> DNS request timed out.
>>      timeout was 2 seconds.
>> DNS request timed out.
>>      timeout was 2 seconds.
>> *** Request to google-public-dns-a.google.com timed-out
>>
>> C:\Users>nslookup bridgecatalog.com 68.94.156.15
>> Server:  dns156r15.sbcglobal.net
>> Address:  68.94.156.15
>>
>> DNS request timed out.
>>      timeout was 2 seconds.
>> DNS request timed out.
>>      timeout was 2 seconds.
>> DNS request timed out.
>>      timeout was 2 seconds.
>> DNS request timed out.
>>      timeout was 2 seconds.
>> *** Request to dns156r15.sbcglobal.net timed-out
>>
>> Looks like the AT&T server are unavailable and the host is unresolvable on
>> my end.
>>
>> On 7/8/2016 3:36 PM, Mark Keymer wrote:
>>
>>> Hi all,
>>>
>>> I have a client bridgecatalog.com and it seems like customers with AT&T
>>> are unable to resolve his Domain. Maybe I am just overlooking something
>>> here but it seems like all should be working. Looking at outside tool
>>> things look ok too.
>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdnscheck.pingdom.com%2f%3fdomain%3dbridgecatalog.com&data=01%7c01%7chdemby%40email.unc.edu%7ca1a111c28862421e835f08d3a7672759%7c58b3d54f16c942d3af081fcabd095666%7c1&sdata=OhVtZs8EqOGddhZh26uvcnMLBBZ5CiUTdeX9FXy5twk%3d
>>>
>>> (except the SOA hostmaster at solarek.com e-mailing issues I see now)
>>>
>>> Other domains seem to work fine. So it isn't just everything is down. One
>>> of the end-users I was working with currently has an ip of 99.7.225.25.
>>> Power cycling the modem did not change thing. I also flushed DNS. If I
>>> change to google's open resolvers things work fine. But not with default
>>> resolvers to client.
>>>
>>> Anyone at AT&T that could check that the resolver's your clients are
>>> using are able to resolve. (Home / SMB connections, etc)
>>>
>>> I am not sure the best way to go about trying to look into this issue if
>>> other have suggestion I would also appreciate it.
>>>
>>> Sincerely,
>>>
>>>


From eric-list at truenet.com  Sat Jul  9 00:33:01 2016
From: eric-list at truenet.com (Eric Tykwinski)
Date: Fri, 8 Jul 2016 20:33:01 -0400
Subject: Leap Second planned for 2016
In-Reply-To: <578033D7.8080409@buzcom.net>
References: <c8258e7b-d53c-6a31-b2a4-57b44cbc79e6@gmail.com>
 <CA+M5dWbZM1kQx1dG6Ba_cEYOyH=f9X5vhuc6bmM6s8pCdbGx=g@mail.gmail.com>
 <CALA5tJLrq3O3NQoN1dLyRcBcJkiAWy0gLLBT8Wm528XX3oH7gg@mail.gmail.com>
 <578033D7.8080409@buzcom.net>
Message-ID: <4D4F8B99-C893-43F4-8AC7-2BAED3D169AA@truenet.com>

That was great, I would actually like NIST to link to it?

> On Jul 8, 2016, at 7:14 PM, Hal Ponton <hal at buzcom.net> wrote:
> 
> I'll just leave this here :)
> 
> http://spendyourleapsecondhere.com/ <http://spendyourleapsecondhere.com/>
> -- 
> --
> Regards,
> 
> Hal Ponton
> Senior Network Engineer
> 
> Buzcom / FibreWiFi
> 
> 
> 
> 
>> Andrew Kirch <mailto:trelane at trelane.net <mailto:trelane at trelane.net>>
>> 9 July 2016 at 00:09
>> Its a whole extra second you can spend doing something awesome. You have to
>> plan now!
>> 
>> Javier J <mailto:javier at advancedmachines.us <mailto:javier at advancedmachines.us>>
>> 8 July 2016 at 23:53
>>> Time to start preparing
>> 
>> 
>> Unless you are running something that can't handle leap seconds what do you
>> really need to prepare for?
>> 
>> 
>> 
>> On Thu, Jul 7, 2016 at 12:59 PM, Andrew Gallo<akg1330 at gmail.com>  wrote:
>> 
>>> Looks like we'll have another second in 2016:
>>> http://www.space.com/33361-leap-second-2016-atomic-clocks.html
>>> 
>>> 
>>> Time to start preparing
>>> 
>>> 
>> Andrew Gallo <mailto:akg1330 at gmail.com <mailto:akg1330 at gmail.com>>
>> 7 July 2016 at 17:59
>> Looks like we'll have another second in 2016:
>> http://www.space.com/33361-leap-second-2016-atomic-clocks.html <http://www.space.com/33361-leap-second-2016-atomic-clocks.html>
>> 
>> 
>> Time to start preparing


From stenn at nwtime.org  Sat Jul  9 00:50:25 2016
From: stenn at nwtime.org (Harlan Stenn)
Date: Fri, 8 Jul 2016 17:50:25 -0700
Subject: Leap Second planned for 2016
In-Reply-To: <CAAeewD_kxj2g4=XaNk8jj5DCp8hEhtNY5JhAQesCyYGVy8Opew@mail.gmail.com>
References: <c8258e7b-d53c-6a31-b2a4-57b44cbc79e6@gmail.com>
 <CA+M5dWbZM1kQx1dG6Ba_cEYOyH=f9X5vhuc6bmM6s8pCdbGx=g@mail.gmail.com>
 <310A3651-64F5-4B79-9951-C0208A1C1A82@puck.nether.net>
 <CAAeewD_kxj2g4=XaNk8jj5DCp8hEhtNY5JhAQesCyYGVy8Opew@mail.gmail.com>
Message-ID: <097086ec-b408-c21b-4aa5-aad947aae048@nwtime.org>



On 7/8/16 4:47 PM, Saku Ytti wrote:
> On 9 July 2016 at 02:27, Jared Mauch <jared at puck.nether.net> wrote:
>> Time is actually harder than it seems. Many bits of software break in unexpected ways. Expect the unexpected.
> 
> Aye. How many have written code like this:
> 
> start = time();
> do_something();
> elapsed = time() - start;
> 
> Virtually all code dealing with passage of time assumes time moves
> only forward, I'm amazed we don't see more issues during leap seconds.
> Portable monotonic time isn't even available in many languages
> standard libraries.
> 
> Hopefully they'll decide in 2023 finally to get rid of leap seconds
> from UTC. Then GPS_TIME, TAI and UTC are all same with different
> static offset.

How about you run your systems on TAI or satellite time?

-- 
Harlan Stenn <stenn at nwtime.org>
http://networktimefoundation.org - be a member!


From patrick at ianai.net  Sat Jul  9 01:39:32 2016
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Fri, 8 Jul 2016 21:39:32 -0400
Subject: Leap Second planned for 2016
In-Reply-To: <CAAeewD_kxj2g4=XaNk8jj5DCp8hEhtNY5JhAQesCyYGVy8Opew@mail.gmail.com>
References: <c8258e7b-d53c-6a31-b2a4-57b44cbc79e6@gmail.com>
 <CA+M5dWbZM1kQx1dG6Ba_cEYOyH=f9X5vhuc6bmM6s8pCdbGx=g@mail.gmail.com>
 <310A3651-64F5-4B79-9951-C0208A1C1A82@puck.nether.net>
 <CAAeewD_kxj2g4=XaNk8jj5DCp8hEhtNY5JhAQesCyYGVy8Opew@mail.gmail.com>
Message-ID: <EEE229F6-9539-49A1-9D14-6652A9C49285@ianai.net>

On Jul 8, 2016, at 7:47 PM, Saku Ytti <saku at ytti.fi> wrote:
> On 9 July 2016 at 02:27, Jared Mauch <jared at puck.nether.net> wrote:

>> Time is actually harder than it seems. Many bits of software break in unexpected ways. Expect the unexpected.
> 
> Aye. How many have written code like this:
> 
> start = time();
> do_something();
> elapsed = time() - start;
> 
> Virtually all code dealing with passage of time assumes time moves
> only forward, I'm amazed we don't see more issues during leap seconds.
> Portable monotonic time isn't even available in many languages
> standard libraries.
> 
> Hopefully they'll decide in 2023 finally to get rid of leap seconds
> from UTC. Then GPS_TIME, TAI and UTC are all same with different
> static offset.

But time _DOES_ flow. The seconds count
	58, 59, 60, 00, 01, ?
If you can?t keep up, that?s not UTC?s fault.

As for stopping the leap seconds, talk to the planet Earth. It?s the one who will not conveniently rotate properly. Either that, or run REEEEEEALLY Fast in that -> direction every once in a while. :-)

-- 
TTFN,
patrick


From cma at cmadams.net  Sat Jul  9 04:29:47 2016
From: cma at cmadams.net (Chris Adams)
Date: Fri, 8 Jul 2016 23:29:47 -0500
Subject: Leap Second planned for 2016
In-Reply-To: <EEE229F6-9539-49A1-9D14-6652A9C49285@ianai.net>
References: <c8258e7b-d53c-6a31-b2a4-57b44cbc79e6@gmail.com>
 <CA+M5dWbZM1kQx1dG6Ba_cEYOyH=f9X5vhuc6bmM6s8pCdbGx=g@mail.gmail.com>
 <310A3651-64F5-4B79-9951-C0208A1C1A82@puck.nether.net>
 <CAAeewD_kxj2g4=XaNk8jj5DCp8hEhtNY5JhAQesCyYGVy8Opew@mail.gmail.com>
 <EEE229F6-9539-49A1-9D14-6652A9C49285@ianai.net>
Message-ID: <20160709042947.GA24818@cmadams.net>

Once upon a time, Patrick W. Gilmore <patrick at ianai.net> said:
> But time _DOES_ flow. The seconds count
> 	58, 59, 60, 00, 01, ?
> If you can?t keep up, that?s not UTC?s fault.

Here in the real world of modern computers, virtually everybody has
copied the UNIX/C behavior that doesn't actually allow for 61 seconds in
a minute.  POSIX time_t is defined to be 86,400 seconds per day, with
"(time % 86400) == 0" being midnight UTC.  The conversion from time_t to
(hours, minutes, seconds) documents that minutes can be more or less
than 60 seconds, but it is moot, since the input that the system uses to
actually keep time cannot represent anything but 60-second minutes (and
still be in sync with the outside world).

So, all the systems we use either double count 59 (which means time
jumps backwards, because it goes 59.9999... to 59.0), or count half time
during second 59 (so going from 59.0 to 0.0 takes two actual seconds).
Both have their pluses and minuses, and IIRC both have exposed software
bugs in the past.  The bugs usually get fixed after the leap second, but
the next one always seems to expose new bugs.

Leap second handling code is not well-tested and is an ultimate corner
case.  There's been debate about abolishing leap seconds; with all the
every-day bugs people have to deal with, few people set up a special
test environment to handle something that may never happen again (until
you get less than six months warning that it'll happen at least once
more), and even then, tests tend to focus on what broke before, because
it is really hard to test EVERYTHING.

You can debate the correctness of these things, but you can't really
debate that they are the way things work.

There are experiments to handle leap seconds differently, such as
smearing them over a longer period (up to 24 hours IIRC), but they
require custom time-keeping code and running without any external time
reference during the smear (because there's no standard way to do that).

> As for stopping the leap seconds, talk to the planet Earth. It?s the one who will not conveniently rotate properly. Either that, or run REEEEEEALLY Fast in that -> direction every once in a while. :-)

Leap seconds are inserted to keep the atomic clocks synced with an
arbitrary time base (that is guaranteed to vary forever).  There's
nothing magic about having noon UTC meaning the Sun is directly over 0?
longitude; if we didn't insert leap seconds, it would have drifted
slightly, but so what?

-- 
Chris Adams <cma at cmadams.net>

From cma at cmadams.net  Sat Jul  9 04:31:18 2016
From: cma at cmadams.net (Chris Adams)
Date: Fri, 8 Jul 2016 23:31:18 -0500
Subject: Leap Second planned for 2016
In-Reply-To: <CA+M5dWbZM1kQx1dG6Ba_cEYOyH=f9X5vhuc6bmM6s8pCdbGx=g@mail.gmail.com>
References: <c8258e7b-d53c-6a31-b2a4-57b44cbc79e6@gmail.com>
 <CA+M5dWbZM1kQx1dG6Ba_cEYOyH=f9X5vhuc6bmM6s8pCdbGx=g@mail.gmail.com>
Message-ID: <20160709043118.GB24818@cmadams.net>

Once upon a time, Javier J <javier at advancedmachines.us> said:
> Unless you are running something that can't handle leap seconds what do you
> really need to prepare for?

The last several leap seconds have exposed weird and hard to predict
bugs in various bits of software.  Those previous bugs have (probably)
all been fixed, but there will likely be new bugs that nobody tested
for.
-- 
Chris Adams <cma at cmadams.net>

From esr at thyrsus.com  Sat Jul  9 08:36:02 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 9 Jul 2016 04:36:02 -0400
Subject: Leap Second planned for 2016
In-Reply-To: <20160709042947.GA24818@cmadams.net>
References: <c8258e7b-d53c-6a31-b2a4-57b44cbc79e6@gmail.com>
 <CA+M5dWbZM1kQx1dG6Ba_cEYOyH=f9X5vhuc6bmM6s8pCdbGx=g@mail.gmail.com>
 <310A3651-64F5-4B79-9951-C0208A1C1A82@puck.nether.net>
 <CAAeewD_kxj2g4=XaNk8jj5DCp8hEhtNY5JhAQesCyYGVy8Opew@mail.gmail.com>
 <EEE229F6-9539-49A1-9D14-6652A9C49285@ianai.net>
 <20160709042947.GA24818@cmadams.net>
Message-ID: <20160709083602.GA19591@thyrsus.com>

Chris Adams <cma at cmadams.net>:
> Leap seconds are inserted to keep the atomic clocks synced with an
> arbitrary time base (that is guaranteed to vary forever).  There's
> nothing magic about having noon UTC meaning the Sun is directly over 0?
> longitude; if we didn't insert leap seconds, it would have drifted
> slightly, but so what?

Here is "so what".  From my blog, earlier this year: "In defense of
calendrical irregularity"

I?ve been getting deeper into timekeeping and calendar-related
software the last few years. Besides my work on GPSD, I?m now the tech
lead of NTPsec. Accordingly, I have learned a great deal about time
mensuration and the many odd problems that beset calendricists. I
could tell you more about the flakiness of timezones, leap seconds,
and the error budget of UTC than you probably want to know.

Paradoxically, I find that studying the glitches in the system (some
of which are quite maddening from a software engineer?s point of view)
has left me more opposed to efforts to simplify them out of
existence. I am against, as a major example, the efforts to abolish
leap seconds.

My reason is that studying this mess has made me more aware than I
used to be of the actual function of civil timekeeping. It is to allow
humans to have consistent and useful intuitions about how clock time
relates to the solar day, and in particular to how human circadian
rhythms are entrained by the solar day. Secondarily to maintain
knowledge of how human biological rhythms connect to the seasonal
round (a weaker effect but not a trivial one).

Yes, in theory we could abolish calendars and timestamp everything by
atomic-clock kiloseconds since an epoch. And if there ever comes a day
when we all live in completely controlled environments like space habs
or dome colonies that might actually work for us.

Until then, the trouble with that sort of computer-optimized timestamp
is that while it tells us what time it is, it doesn?t tell us what
*kind* of time it is ? how the time relates to human living. Day? Night?
Season?

Those sideband meanings are an important component of how humans use
and interpret time references. Yes, I know January in Australia
doesn?t mean the same thing as January in the U.S. ? the point is that
people in both places have stable intuitions about what the weather
will be like then, what sorts of holidays will be celebrated, what
kind of mood is prevalent.

I judge that all the crap I go though reconciling scientific absolute
time to human-centered solar time is worth it. Because when all is
said and done, clocks and calendars are human instruments to serve
human needs. We should be glad when they add texture and meaning to
human life, and beware lest in our attempts to make software easier to
write we inadvertently bulldoze away entire structures of delicate
meaning.

UPDATE: There is one context, however, in which I would cheerfully
junk timezones. I think timestamps on things like file modifications
and version-control commits should always be kept, and represented, in
UTC, and I?m a big fan of RFC3339 format as the way to do that.

The reason I say this is that these times almost never have a
human-body-clock meaning, while on the other hand it is often useful
to be able to compare them unambiguously across timezones. Their usage
pattern is more like scientific than civil time.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From saku at ytti.fi  Sat Jul  9 09:14:03 2016
From: saku at ytti.fi (Saku Ytti)
Date: Sat, 9 Jul 2016 12:14:03 +0300
Subject: Leap Second planned for 2016
In-Reply-To: <EEE229F6-9539-49A1-9D14-6652A9C49285@ianai.net>
References: <c8258e7b-d53c-6a31-b2a4-57b44cbc79e6@gmail.com>
 <CA+M5dWbZM1kQx1dG6Ba_cEYOyH=f9X5vhuc6bmM6s8pCdbGx=g@mail.gmail.com>
 <310A3651-64F5-4B79-9951-C0208A1C1A82@puck.nether.net>
 <CAAeewD_kxj2g4=XaNk8jj5DCp8hEhtNY5JhAQesCyYGVy8Opew@mail.gmail.com>
 <EEE229F6-9539-49A1-9D14-6652A9C49285@ianai.net>
Message-ID: <CAAeewD9LXBngWYT-RZJhC-oP7O2=BEDDjiQMmqWYJeKyyTgiUw@mail.gmail.com>

On 9 July 2016 at 04:39, Patrick W. Gilmore <patrick at ianai.net> wrote:

Hey,

> But time _DOES_ flow. The seconds count
>         58, 59, 60, 00, 01, ?
> If you can?t keep up, that?s not UTC?s fault.

Check the implementation on your PC. This is why code is broken and
people don't even know it's broken. You have to use monotonic time to
measure passage of time, which is not particularly easy to do
portable, in some languages.

> As for stopping the leap seconds, talk to the planet Earth. It?s the one who will not conveniently rotate properly. Either that, or run REEEEEEALLY Fast in that -> direction every once in a while. :-)

In practice this does not appear to be significant problem. Several
thousand years must pass until clocks have shifted one hour, and we
have experience on shifting clocks one hour within a year, so I'm sure
we can tolerate slippage caused by not having leaps. I'm holding my
thumbs up for 2023 and sanity prevailing.

-- 
  ++ytti

From mark.tinka at seacom.mu  Sat Jul  9 09:23:29 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Sat, 9 Jul 2016 11:23:29 +0200
Subject: L3 over OTN vs pure IP/MPLS
In-Reply-To: <CAD0TWZ_kUTO2utNddusizoOngHUP9MVesyqSXpkPu8A1GqXSSg@mail.gmail.com>
References: <CAD0TWZ_kUTO2utNddusizoOngHUP9MVesyqSXpkPu8A1GqXSSg@mail.gmail.com>
Message-ID: <d8923375-a383-b1d3-ac4a-761e2b0cf98a@seacom.mu>



On 8/Jul/16 04:43, Manuel Mar?n wrote:

> Dear Nanog community
>
> We are currently experimenting TCP degradation issues in some metro markets
> where there are multiple POPs and the IP packets have to pass multiple L3
> access devices (routers) before reaching the core router. The more L3 hops
> that it goes through the more degradation we see in the Internet service.
> L3 routers have the capacity in terms of pps and BW and we are using just a
> small percentage of that capacity but anyway the service is degraded (No
> CRC/Input errors in the links). A couple of vendors are recommending using
> OTN or MPLS-TP to backhaul the connections from the access to the core but
> obviously deploying OTN means a considerable amount of capex. The
> flexibility and simplicity of the L3 based access network is great but
> given the performance issues we are experimenting I would appreciate if you
> can share your experience/recommendation with either OTN or MPLS-TP. Does
> it really make sense to use a OTN/Photonic layer to backhaul the L3
> connections in a metro network?

Are you running your Metro-E networks on dark fibre all the way into
your core, or are you leasing a lit service from another carrier for this?

If the former, you should not have any issues with performance
considering a well-designed network. If the latter, you are in the hands
of your carrier, and you would need to qualify that they know what they
are doing before you overlay your network on top of theirs.

I cannot find any benefit in running your Metro-E network on dark fibre
vs. OTN into the core apart from when you hit the port bandwidth limits
in your Metro-E network and need to go to DWDM to upgrade that so as to
keep the fibre-count down while increasing bandwidth.

We run a large dark-fibre-based Metro-E network without any DWDM
equipment between most rings and our core, and there is no tangible
difference in performance between services delivered on those rings or
services delivered upstream in the core data centres. There is also no
difference in performance between the dark fibre rings vs. the DWDM
rings (although, depending on your equipment vendor, some platforms
could introduce quite a bit of serialization delay, but not enough to
affect actual performance).

Sounds like your vendors are trying to sell you boxes...

Mark.

From johnl at iecc.com  Sat Jul  9 17:12:36 2016
From: johnl at iecc.com (John Levine)
Date: 9 Jul 2016 17:12:36 -0000
Subject: Bitcoin mining reward halved
Message-ID: <20160709171236.19630.qmail@ary.lan>

At about 16:46 UTC block 420001 showed up on the Bitcoin blockchain,
so the mining reward per block dropped from 25 to 12.5 btc.

Depending on whom you believe, nothing will change, or most of the
miners will go offline, or something else.  My blockchain client saw
420002 was over 25 minutes after 420001 ago, and over 10,000 waiting
transactions, so perhaps the second theory is correct.

Anyone here tracking bitcoin P2P traffic?

R's,
John


From josh at kyneticwifi.com  Sat Jul  9 18:30:12 2016
From: josh at kyneticwifi.com (Josh Reynolds)
Date: Sat, 9 Jul 2016 13:30:12 -0500
Subject: Bitcoin mining reward halved
In-Reply-To: <20160709171236.19630.qmail@ary.lan>
References: <20160709171236.19630.qmail@ary.lan>
Message-ID: <CAC6=tfbtPO_7CKgozw83GgWm8ATpJOSRqBmqk0JH9O5jB2TH=g@mail.gmail.com>

This is pretty O/T for this list, isn't it?
On Jul 9, 2016 12:15 PM, "John Levine" <johnl at iecc.com> wrote:

> At about 16:46 UTC block 420001 showed up on the Bitcoin blockchain,
> so the mining reward per block dropped from 25 to 12.5 btc.
>
> Depending on whom you believe, nothing will change, or most of the
> miners will go offline, or something else.  My blockchain client saw
> 420002 was over 25 minutes after 420001 ago, and over 10,000 waiting
> transactions, so perhaps the second theory is correct.
>
> Anyone here tracking bitcoin P2P traffic?
>
> R's,
> John
>
>

From A.L.M.Buxey at lboro.ac.uk  Sat Jul  9 19:04:21 2016
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Sat, 9 Jul 2016 19:04:21 +0000
Subject: Bitcoin mining reward halved
In-Reply-To: <CAC6=tfbtPO_7CKgozw83GgWm8ATpJOSRqBmqk0JH9O5jB2TH=g@mail.gmail.com>
References: <20160709171236.19630.qmail@ary.lan>
 <CAC6=tfbtPO_7CKgozw83GgWm8ATpJOSRqBmqk0JH9O5jB2TH=g@mail.gmail.com>
Message-ID: <20160709190421.GA31023@lboro.ac.uk>

Hi,
> This is pretty O/T for this list, isn't it?

not if he's using his routers ASICs to do it! ;-)
(or maybe its related to the bitcoin network traffic volumes...but
thats too logical...)

alan

From A.L.M.Buxey at lboro.ac.uk  Sat Jul  9 19:09:08 2016
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Sat, 9 Jul 2016 19:09:08 +0000
Subject: Leap Second planned for 2016
In-Reply-To: <20160709042947.GA24818@cmadams.net>
References: <c8258e7b-d53c-6a31-b2a4-57b44cbc79e6@gmail.com>
 <CA+M5dWbZM1kQx1dG6Ba_cEYOyH=f9X5vhuc6bmM6s8pCdbGx=g@mail.gmail.com>
 <310A3651-64F5-4B79-9951-C0208A1C1A82@puck.nether.net>
 <CAAeewD_kxj2g4=XaNk8jj5DCp8hEhtNY5JhAQesCyYGVy8Opew@mail.gmail.com>
 <EEE229F6-9539-49A1-9D14-6652A9C49285@ianai.net>
 <20160709042947.GA24818@cmadams.net>
Message-ID: <20160709190908.GB31023@lboro.ac.uk>

Hi,

> Leap second handling code is not well-tested and is an ultimate corner
> case.  There's been debate about abolishing leap seconds; with all the

well, we've gone through a few of these now...so if it was all okay before
its likely to be again... exception: any NEW code that
you are running since last time - THAT hasnt been tested ;-)

alan

From mysidia at gmail.com  Sat Jul  9 19:10:42 2016
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 9 Jul 2016 14:10:42 -0500
Subject: Bitcoin mining reward halved
In-Reply-To: <20160709190421.GA31023@lboro.ac.uk>
References: <20160709171236.19630.qmail@ary.lan>
 <CAC6=tfbtPO_7CKgozw83GgWm8ATpJOSRqBmqk0JH9O5jB2TH=g@mail.gmail.com>
 <20160709190421.GA31023@lboro.ac.uk>
Message-ID: <CAAAwwbU--PL1zxUeJs0nwDZNdERVmTZOBnj7h5_OJ3FPO2StMQ@mail.gmail.com>

On Sat, Jul 9, 2016 at 2:04 PM,  <A.L.M.Buxey at lboro.ac.uk> wrote:
> Hi,

Blockchain-based replacement for RPKI involving encoding of
IP address  registry registrations   assigned to a Network operator's
specified  Org ID wallet,  And LOAs for propagating the announcement
of a prefix by using  Colored coins   automatically distributed to a
specified ASN by
BGP daemon  on your routers?

Err...

>> This is pretty O/T for this list, isn't it?
>
> not if he's using his routers ASICs to do it! ;-)
> (or maybe its related to the bitcoin network traffic volumes...but
> thats too logical...)
>
> alan

-- 
-JH

From saku at ytti.fi  Sat Jul  9 20:09:38 2016
From: saku at ytti.fi (Saku Ytti)
Date: Sat, 9 Jul 2016 23:09:38 +0300
Subject: Leap Second planned for 2016
In-Reply-To: <20160709190908.GB31023@lboro.ac.uk>
References: <c8258e7b-d53c-6a31-b2a4-57b44cbc79e6@gmail.com>
 <CA+M5dWbZM1kQx1dG6Ba_cEYOyH=f9X5vhuc6bmM6s8pCdbGx=g@mail.gmail.com>
 <310A3651-64F5-4B79-9951-C0208A1C1A82@puck.nether.net>
 <CAAeewD_kxj2g4=XaNk8jj5DCp8hEhtNY5JhAQesCyYGVy8Opew@mail.gmail.com>
 <EEE229F6-9539-49A1-9D14-6652A9C49285@ianai.net>
 <20160709042947.GA24818@cmadams.net>
 <20160709190908.GB31023@lboro.ac.uk>
Message-ID: <CAAeewD__Dd-ZBb1H6qf2doJNFdJPni2hsaem3r3Te21EtBob_A@mail.gmail.com>

On 9 July 2016 at 22:09,  <A.L.M.Buxey at lboro.ac.uk> wrote:

> well, we've gone through a few of these now...so if it was all okay before
> its likely to be again... exception: any NEW code that
> you are running since last time - THAT hasnt been tested ;-)

In most cases the bugs are not pathological if the elapsed time is
long, it may not break anything if they are 1s off. And if they
measure short elapsed time, but are done infrequently, you might just
not have hit the code path at the right moment.

I'm sure you've had your share of difficult to track down bugs
requiring very specific set complicated conditions. I give little
value in black-box testing, lot of effort and very high chance of just
not hitting all bug prerequisites, unit testing is much more fruitful,
but alas in walled garden not possible.

  ++ytti

From Valdis.Kletnieks at vt.edu  Sat Jul  9 21:12:29 2016
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sat, 09 Jul 2016 17:12:29 -0400
Subject: Leap Second planned for 2016
In-Reply-To: <CAAeewD9LXBngWYT-RZJhC-oP7O2=BEDDjiQMmqWYJeKyyTgiUw@mail.gmail.com>
References: <c8258e7b-d53c-6a31-b2a4-57b44cbc79e6@gmail.com>
 <CA+M5dWbZM1kQx1dG6Ba_cEYOyH=f9X5vhuc6bmM6s8pCdbGx=g@mail.gmail.com>
 <310A3651-64F5-4B79-9951-C0208A1C1A82@puck.nether.net>
 <CAAeewD_kxj2g4=XaNk8jj5DCp8hEhtNY5JhAQesCyYGVy8Opew@mail.gmail.com>
 <EEE229F6-9539-49A1-9D14-6652A9C49285@ianai.net>
 <CAAeewD9LXBngWYT-RZJhC-oP7O2=BEDDjiQMmqWYJeKyyTgiUw@mail.gmail.com>
Message-ID: <90902.1468098749@turing-police.cc.vt.edu>

On Sat, 09 Jul 2016 12:14:03 +0300, Saku Ytti said:

> Check the implementation on your PC. This is why code is broken and
> people don't even know it's broken. You have to use monotonic time to
> measure passage of time, which is not particularly easy to do
> portable, in some languages.

It doesn't help that the POSIX standard doesn't represent leap seconds
anyplace, so any elapsed time calculation that crosses a leap second
is guaranteed to be wrong....

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160709/db8e6b9a/attachment.pgp>

From kmedcalf at dessus.com  Sat Jul  9 21:37:36 2016
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Sat, 09 Jul 2016 15:37:36 -0600
Subject: Leap Second planned for 2016
In-Reply-To: <90902.1468098749@turing-police.cc.vt.edu>
Message-ID: <ec2c0c6cbe70ce4e9a65453cafb90530@mail.dessus.com>


POSIX (Unix) (normal) time does not have leap seconds.  
Every POSIX (Unix) (normal) minute has exactly 60 seconds.  
Every POSIX (Unix) (normal) hour has exactly 60 minutes.  
Every POSIX (Unix) (normal) day has exactly 24 hours.
Every POSIX (Unix) (normal) year has 365 days, unless it is a leap year, in which case it has exactly 366 days.

The POSIX time is the number of seconds (or parts thereof) that has passed since midnight, 1 January 1970 GMT.  The time scale is UT1.  Outside of very specialized scientific applications, EVERY computer system everywhere uses POSIX time and does time/date calculations based on POSIX time (UT1).

UTC time has leap seconds.  This is because UTC is a "different" time-scale than the UT1 timescale on which POSIX/Unix time is based.  UTC proceeds at a different "rate" from UT1 and so, from time to time, UTC time must be adjusted to keep it in sync with POSIX/Unix (normal) time.

> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of
> Valdis.Kletnieks at vt.edu
> Sent: Saturday, 9 July, 2016 15:12
> To: Saku Ytti
> Cc: NANOG list
> Subject: Re: Leap Second planned for 2016
> 
> On Sat, 09 Jul 2016 12:14:03 +0300, Saku Ytti said:
> 
> > Check the implementation on your PC. This is why code is broken and
> > people don't even know it's broken. You have to use monotonic time to
> > measure passage of time, which is not particularly easy to do
> > portable, in some languages.
> 
> It doesn't help that the POSIX standard doesn't represent leap seconds
> anyplace, so any elapsed time calculation that crosses a leap second
> is guaranteed to be wrong....





From morrowc.lists at gmail.com  Sat Jul  9 21:39:17 2016
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sat, 9 Jul 2016 17:39:17 -0400
Subject: Bitcoin mining reward halved
In-Reply-To: <CAAAwwbU--PL1zxUeJs0nwDZNdERVmTZOBnj7h5_OJ3FPO2StMQ@mail.gmail.com>
References: <20160709171236.19630.qmail@ary.lan>
 <CAC6=tfbtPO_7CKgozw83GgWm8ATpJOSRqBmqk0JH9O5jB2TH=g@mail.gmail.com>
 <20160709190421.GA31023@lboro.ac.uk>
 <CAAAwwbU--PL1zxUeJs0nwDZNdERVmTZOBnj7h5_OJ3FPO2StMQ@mail.gmail.com>
Message-ID: <CAL9jLaZ4OG5VDNWAN1KsL07O_9GFkd_QWvoa975gQ=CRzRoqaw@mail.gmail.com>

On Sat, Jul 9, 2016 at 3:10 PM, Jimmy Hess <mysidia at gmail.com> wrote:

> On Sat, Jul 9, 2016 at 2:04 PM,  <A.L.M.Buxey at lboro.ac.uk> wrote:
> > Hi,
>
> Blockchain-based replacement for RPKI involving encoding of
> IP address  registry registrations   assigned to a Network operator's
> specified  Org ID wallet,  And LOAs for propagating the announcement
> of a prefix by using  Colored coins   automatically distributed to a
> specified ASN by
> BGP daemon  on your routers?
>
>
you are on to something... something fantastic.

From math at sizone.org  Sat Jul  9 21:54:15 2016
From: math at sizone.org (Ken Chase)
Date: Sat, 9 Jul 2016 17:54:15 -0400
Subject: Bitcoin mining reward halved
In-Reply-To: <CAL9jLaZ4OG5VDNWAN1KsL07O_9GFkd_QWvoa975gQ=CRzRoqaw@mail.gmail.com>
References: <20160709171236.19630.qmail@ary.lan>
 <CAC6=tfbtPO_7CKgozw83GgWm8ATpJOSRqBmqk0JH9O5jB2TH=g@mail.gmail.com>
 <20160709190421.GA31023@lboro.ac.uk>
 <CAAAwwbU--PL1zxUeJs0nwDZNdERVmTZOBnj7h5_OJ3FPO2StMQ@mail.gmail.com>
 <CAL9jLaZ4OG5VDNWAN1KsL07O_9GFkd_QWvoa975gQ=CRzRoqaw@mail.gmail.com>
Message-ID: <20160709215414.GY18345@sizone.org>

How'd namecoin work out? .bit taking over the internet?

/kc

On Sat, Jul 09, 2016 at 05:39:17PM -0400, Christopher Morrow said:
  >On Sat, Jul 9, 2016 at 3:10 PM, Jimmy Hess <mysidia at gmail.com> wrote:
  >
  >> On Sat, Jul 9, 2016 at 2:04 PM,  <A.L.M.Buxey at lboro.ac.uk> wrote:
  >> > Hi,
  >>
  >> Blockchain-based replacement for RPKI involving encoding of
  >> IP address  registry registrations   assigned to a Network operator's
  >> specified  Org ID wallet,  And LOAs for propagating the announcement
  >> of a prefix by using  Colored coins   automatically distributed to a
  >> specified ASN by
  >> BGP daemon  on your routers?
  >>
  >>
  >you are on to something... something fantastic.

-- 
Ken Chase - math at sizone.org


From cb.list6 at gmail.com  Sat Jul  9 23:04:33 2016
From: cb.list6 at gmail.com (Ca By)
Date: Sat, 9 Jul 2016 16:04:33 -0700
Subject: Bitcoin mining reward halved
In-Reply-To: <CAL9jLaZ4OG5VDNWAN1KsL07O_9GFkd_QWvoa975gQ=CRzRoqaw@mail.gmail.com>
References: <20160709171236.19630.qmail@ary.lan>
 <CAC6=tfbtPO_7CKgozw83GgWm8ATpJOSRqBmqk0JH9O5jB2TH=g@mail.gmail.com>
 <20160709190421.GA31023@lboro.ac.uk>
 <CAAAwwbU--PL1zxUeJs0nwDZNdERVmTZOBnj7h5_OJ3FPO2StMQ@mail.gmail.com>
 <CAL9jLaZ4OG5VDNWAN1KsL07O_9GFkd_QWvoa975gQ=CRzRoqaw@mail.gmail.com>
Message-ID: <CAD6AjGTB6PqL8Q-1brYNq0EDrAn=vpGWNg7kXXig18xDEhcFcQ@mail.gmail.com>

On Saturday, July 9, 2016, Christopher Morrow <morrowc.lists at gmail.com>
wrote:

> On Sat, Jul 9, 2016 at 3:10 PM, Jimmy Hess <mysidia at gmail.com
> <javascript:;>> wrote:
>
> > On Sat, Jul 9, 2016 at 2:04 PM,  <A.L.M.Buxey at lboro.ac.uk <javascript:;>>
> wrote:
> > > Hi,
> >
> > Blockchain-based replacement for RPKI involving encoding of
> > IP address  registry registrations   assigned to a Network operator's
> > specified  Org ID wallet,  And LOAs for propagating the announcement
> > of a prefix by using  Colored coins   automatically distributed to a
> > specified ASN by
> > BGP daemon  on your routers?
> >
> >
> you are on to something... something fantastic
>

Ok. +1.

From saku at ytti.fi  Sun Jul 10 08:27:33 2016
From: saku at ytti.fi (Saku Ytti)
Date: Sun, 10 Jul 2016 11:27:33 +0300
Subject: Leap Second planned for 2016
In-Reply-To: <90902.1468098749@turing-police.cc.vt.edu>
References: <c8258e7b-d53c-6a31-b2a4-57b44cbc79e6@gmail.com>
 <CA+M5dWbZM1kQx1dG6Ba_cEYOyH=f9X5vhuc6bmM6s8pCdbGx=g@mail.gmail.com>
 <310A3651-64F5-4B79-9951-C0208A1C1A82@puck.nether.net>
 <CAAeewD_kxj2g4=XaNk8jj5DCp8hEhtNY5JhAQesCyYGVy8Opew@mail.gmail.com>
 <EEE229F6-9539-49A1-9D14-6652A9C49285@ianai.net>
 <CAAeewD9LXBngWYT-RZJhC-oP7O2=BEDDjiQMmqWYJeKyyTgiUw@mail.gmail.com>
 <90902.1468098749@turing-police.cc.vt.edu>
Message-ID: <CAAeewD-p8w5M5neGMtT8qkE=2sBNyn2wUWUOqT22+31R_cmUig@mail.gmail.com>

On 10 July 2016 at 00:12,  <Valdis.Kletnieks at vt.edu> wrote:
> It doesn't help that the POSIX standard doesn't represent leap seconds
> anyplace, so any elapsed time calculation that crosses a leap second
> is guaranteed to be wrong....

So how can we solve the problem? Immediately and long term?

a) use UTC or unix time, and accept that code is broken
b) migrate to CLOCK_MONOTONIC, and accept that epoch is unknown (you
cannot serialise clock and consume it in another system)
c) use NTP smear to make clocks run incorrectly to hide the problem
d) use GPSTIME or TAI and implement leaps at last possible moment (at
the presentation layer)
e) wait for 2023 and hope the problem goes away

-- 
  ++ytti

From sla at ucolick.org  Sun Jul 10 16:06:14 2016
From: sla at ucolick.org (Steve Allen)
Date: Sun, 10 Jul 2016 09:06:14 -0700
Subject: Leap Second planned for 2016
In-Reply-To: <CAAeewD-p8w5M5neGMtT8qkE=2sBNyn2wUWUOqT22+31R_cmUig@mail.gmail.com>
References: <c8258e7b-d53c-6a31-b2a4-57b44cbc79e6@gmail.com>
 <CA+M5dWbZM1kQx1dG6Ba_cEYOyH=f9X5vhuc6bmM6s8pCdbGx=g@mail.gmail.com>
 <310A3651-64F5-4B79-9951-C0208A1C1A82@puck.nether.net>
 <CAAeewD_kxj2g4=XaNk8jj5DCp8hEhtNY5JhAQesCyYGVy8Opew@mail.gmail.com>
 <EEE229F6-9539-49A1-9D14-6652A9C49285@ianai.net>
 <CAAeewD9LXBngWYT-RZJhC-oP7O2=BEDDjiQMmqWYJeKyyTgiUw@mail.gmail.com>
 <90902.1468098749@turing-police.cc.vt.edu>
 <CAAeewD-p8w5M5neGMtT8qkE=2sBNyn2wUWUOqT22+31R_cmUig@mail.gmail.com>
Message-ID: <20160710160614.GC21909@ucolick.org>

On Sun 2016-07-10T11:27:33 +0300, Saku Ytti hath writ:
> So how can we solve the problem? Immediately and long term?

The ITU-R had the question of leap seconds on their agenda for 14
years and did not come up with an answer.  Their 2015 decision was to
drop the question and ask an alphabet soup of international acronym
agencies to come up with something better by 2023.

The problem remains that simply abandoning leap seconds has the effect
of redefining the calendar, and Pope Gregory's last attempt to do that
took 300 years to consolidate.  For time scales there are three
desirable goals, but it is only possible to pick two

http://www.ucolick.org/~sla/leapsecs/picktwo.html

--
Steve Allen                    <sla at ucolick.org>              WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street               Voice: +1 831 459 3046         Lng -122.06015
Santa Cruz, CA 95064           http://www.ucolick.org/~sla/   Hgt +250 m

From swmike at swm.pp.se  Sun Jul 10 16:37:02 2016
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Sun, 10 Jul 2016 18:37:02 +0200 (CEST)
Subject: Leap Second planned for 2016
In-Reply-To: <CAAeewD-p8w5M5neGMtT8qkE=2sBNyn2wUWUOqT22+31R_cmUig@mail.gmail.com>
References: <c8258e7b-d53c-6a31-b2a4-57b44cbc79e6@gmail.com>
 <CA+M5dWbZM1kQx1dG6Ba_cEYOyH=f9X5vhuc6bmM6s8pCdbGx=g@mail.gmail.com>
 <310A3651-64F5-4B79-9951-C0208A1C1A82@puck.nether.net>
 <CAAeewD_kxj2g4=XaNk8jj5DCp8hEhtNY5JhAQesCyYGVy8Opew@mail.gmail.com>
 <EEE229F6-9539-49A1-9D14-6652A9C49285@ianai.net>
 <CAAeewD9LXBngWYT-RZJhC-oP7O2=BEDDjiQMmqWYJeKyyTgiUw@mail.gmail.com>
 <90902.1468098749@turing-police.cc.vt.edu>
 <CAAeewD-p8w5M5neGMtT8qkE=2sBNyn2wUWUOqT22+31R_cmUig@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1607101835100.2309@uplift.swm.pp.se>

On Sun, 10 Jul 2016, Saku Ytti wrote:

> On 10 July 2016 at 00:12,  <Valdis.Kletnieks at vt.edu> wrote:
>> It doesn't help that the POSIX standard doesn't represent leap seconds
>> anyplace, so any elapsed time calculation that crosses a leap second
>> is guaranteed to be wrong....
>
> So how can we solve the problem? Immediately and long term?

Since one problem is that the leap second code isn't exercised regularily, 
I propose that each month there is a leap second either forward or 
backward. These forward/backward motions should be fudged to over time 
make sure that we stay pretty much correct.

If POSIX needs to be changed, then change it. By making leap second not a 
rare event, this would hopefully mean it'll get taken more serously and 
the code would receive wider testing than today.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se

From jra at baylink.com  Sun Jul 10 17:26:17 2016
From: jra at baylink.com (Jay R. Ashworth)
Date: Sun, 10 Jul 2016 17:26:17 +0000 (UTC)
Subject: Leap Second planned for 2016
In-Reply-To: <c8258e7b-d53c-6a31-b2a4-57b44cbc79e6@gmail.com>
References: <c8258e7b-d53c-6a31-b2a4-57b44cbc79e6@gmail.com>
Message-ID: <1463212683.34000.1468171577970.JavaMail.zimbra@baylink.com>

----- Original Message -----
> From: "Andrew Gallo" <akg1330 at gmail.com>

> Looks like we'll have another second in 2016:
> http://www.space.com/33361-leap-second-2016-atomic-clocks.html

"5... 4... 3... 2... 1... Zero!... Happy New Year!"

But only if you're in London.  7pm EDT.

Cheers,
-- jr 'not on my birthday, damn'
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274

From jra at baylink.com  Sun Jul 10 17:34:32 2016
From: jra at baylink.com (Jay R. Ashworth)
Date: Sun, 10 Jul 2016 17:34:32 +0000 (UTC)
Subject: Falsehoods programmers believe about time, etc (was Re: Leap Second
 planned for 2016)
In-Reply-To: <20160709042947.GA24818@cmadams.net>
References: <c8258e7b-d53c-6a31-b2a4-57b44cbc79e6@gmail.com>
 <CA+M5dWbZM1kQx1dG6Ba_cEYOyH=f9X5vhuc6bmM6s8pCdbGx=g@mail.gmail.com>
 <310A3651-64F5-4B79-9951-C0208A1C1A82@puck.nether.net>
 <CAAeewD_kxj2g4=XaNk8jj5DCp8hEhtNY5JhAQesCyYGVy8Opew@mail.gmail.com>
 <EEE229F6-9539-49A1-9D14-6652A9C49285@ianai.net>
 <20160709042947.GA24818@cmadams.net>
Message-ID: <1251440452.34010.1468172072700.JavaMail.zimbra@baylink.com>

----- Original Message -----
> From: "Chris Adams" <cma at cmadams.net>

> Once upon a time, Patrick W. Gilmore <patrick at ianai.net> said:
>> But time _DOES_ flow. The seconds count
>> 	58, 59, 60, 00, 01, ?
>> If you can?t keep up, that?s not UTC?s fault.

[ ... ]

> Leap second handling code is not well-tested and is an ultimate corner
> case.  There's been debate about abolishing leap seconds; with all the
> every-day bugs people have to deal with, few people set up a special
> test environment to handle something that may never happen again (until
> you get less than six months warning that it'll happen at least once
> more), and even then, tests tend to focus on what broke before, because
> it is really hard to test EVERYTHING.

If this particular issue is your beat -- or your avocation -- you really should
read both these blog postings, and all their comments; they are nearly
comprehensive:

  http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time

and

  http://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time

They are also both funny as hell.



To myself be comprehensive, I should point out a companion piece about names:

  https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

and there are similar lists for phone numbers, geography, civil addresses and gender,
linked from this thread:

  https://news.ycombinator.com/item?id=11321236

If you write any code that has to interface with the outside world, these are pieces
I think you should read at least annually.

Cheers,
-- jra


-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274

From mysidia at gmail.com  Sun Jul 10 18:28:29 2016
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 10 Jul 2016 13:28:29 -0500
Subject: Leap Second planned for 2016
In-Reply-To: <CAAeewD-p8w5M5neGMtT8qkE=2sBNyn2wUWUOqT22+31R_cmUig@mail.gmail.com>
References: <c8258e7b-d53c-6a31-b2a4-57b44cbc79e6@gmail.com>
 <CA+M5dWbZM1kQx1dG6Ba_cEYOyH=f9X5vhuc6bmM6s8pCdbGx=g@mail.gmail.com>
 <310A3651-64F5-4B79-9951-C0208A1C1A82@puck.nether.net>
 <CAAeewD_kxj2g4=XaNk8jj5DCp8hEhtNY5JhAQesCyYGVy8Opew@mail.gmail.com>
 <EEE229F6-9539-49A1-9D14-6652A9C49285@ianai.net>
 <CAAeewD9LXBngWYT-RZJhC-oP7O2=BEDDjiQMmqWYJeKyyTgiUw@mail.gmail.com>
 <90902.1468098749@turing-police.cc.vt.edu>
 <CAAeewD-p8w5M5neGMtT8qkE=2sBNyn2wUWUOqT22+31R_cmUig@mail.gmail.com>
Message-ID: <CAAAwwbVhG93YQeobMnOuVdkWX9xd1DH=wZiK8bot5ZeXL7YSdw@mail.gmail.com>

On Sun, Jul 10, 2016 at 3:27 AM, Saku Ytti <saku at ytti.fi> wrote:

[snip]
> a) use UTC or unix time, and accept that code is broken
[snip]

The Unix time format  might be an unsuitable time representation for
applications which require clock precision or time precision within a
few seconds  for the purposes of Timestamping or synchronizing events
 down to a  Per-Second or   Subsecond resolution.

Suggest revising Unix/POSIX   Time implementation to use a 3-Tuple
representation of calendar time,  instead of a single Integer.

typedef   int64_t  time_t [3];

 [  Delta from Epoch  in Seconds,  Delta in Microseconds,
Cumulative  Leap Adjustment from the Epoch in Microseconds]

Thus to compare two  timestamps  A and B

long long difference_in_seconds(time_t A, time_t B) {

return  (B[0] - A[0])  +   ( B[1] - A[1]  +  B[2] - A[2] ) /1000000;

}

-- 
-JH

From James at mor-pah.net  Sun Jul 10 23:48:56 2016
From: James at mor-pah.net (James Greig)
Date: Mon, 11 Jul 2016 00:48:56 +0100
Subject: packet loss question
In-Reply-To: <577EAAD4.5010405@netwolves.com>
References: <577EAAD4.5010405@netwolves.com>
Message-ID: <23A78013-F030-413C-8E34-5AD7D2BEB1E8@mor-pah.net>

There was a useful nanog presentation somewhere that explained this really well in particular reading traceroutes correctly

Kind regards

James Greig 

> On 7 Jul 2016, at 20:17, Phillip Lynn <phillip.lynn at netwolves.com> wrote:
> 
> Hi all,
> 
>  I am writing because I do not understand what is happening.  I ran mtr against our email server and www.teco.comand below are the results.  I am not a network engineer so I am at a loss.  I think what I am seeing is maybe a hand off issue, between Frontier and Level3Miami2. If I am correct then what can I do?
> 
>  My system is running Centos 6.5 Linux.
> 
> Thanks,
> 
> Phillip
> 
> 
> 
> (! 1011)-> sudo mtr -r netwolves.securence.com
> HOST: xxxxx at netwolves.comLoss%   Snt   Last   Avg Best  Wrst StDev
>  1. 172.24.109.1                  0.0%    10    0.6 0.6 0.6   0.7   0.0
>  2. lo0-100.TAMPFL-VFTTP-322.gni  0.0%    10    3.2 2.0 1.0   4.3   1.2
>  3. 172.99.44.214                 0.0%    10    4.0 4.9 2.3   6.9   1.5
>  4. ae8---0.scr02.mias.fl.fronti  0.0%    10    9.3 9.1 7.5   9.8   1.0
>  5. ae1---0.cbr01.mias.fl.fronti  0.0%    10    8.9   9.1   7.6 9.7 0.7
>  6. lag-101.ear3.Miami2.Level3.n 80.0%    10    9.0   8.9   8.8 9.0 0.1
>  7. 10ge9-14.core1.mia1.he.net    0.0%    10   14.3 13.0 7.6  18.1   4.3
>  8. 10ge1-1.core1.atl1.he.net     0.0%    10   25.6  33.2 22.4  99.7  23.6
>  9. 10ge10-4.core1.chi1.he.net    0.0%    10   45.6  51.8 45.5  82.7  12.5
> 10. 100ge14-2.core1.msp1.he.net   0.0%    10   53.6  63.9 53.6 125.2  21.8
> 11. t4-2-usi-cr02-mpls-usinterne  0.0%    10   53.2  73.1 53.2 225.6  54.0
> 12. v102.usi-cr04-mtka.usinterne  0.0%    10   53.2  53.9 53.2  55.3   0.6
> 13. netwolves.securence.com       0.0%    10   53.4  53.9 53.4  55.4   0.7
> 
> (! 1014)-> sudo mtr -r www.teco.com
> HOST: xxxxx at netwolves.comLoss%   Snt   Last   Avg Best  Wrst StDev
>  1. 172.24.109.1                  0.0%    10    0.6 0.6 0.6   0.7   0.0
>  2. lo0-100.TAMPFL-VFTTP-322.gni  0.0%    10  104.8 81.4 1.1 113.2  43.2
>  3. 172.99.47.198                 0.0%    10  115.0 77.8 2.9 115.0  40.2
>  4. ae7---0.scr01.mias.fl.fronti  0.0%    10  111.1 80.2 8.5 113.5  41.3
>  5. ae0---0.cbr01.mias.fl.fronti  0.0%    10  105.9  82.2   7.6 115.4 33.8
>  6. lag-101.ear3.Miami2.Level3.n 70.0%    10  116.1  80.2   8.5 116.1 62.0
>  7. NTT-level3-80G.Miami.Level3.  0.0%    10  110.0 81.5 9.0 120.3  41.9
>  8. ae-3.r20.miamfl02.us.bb.gin.  0.0%    10  119.8  84.0 10.0 119.8  38.5
>  9. ae-4.r23.asbnva02.us.bb.gin. 10.0%    10  137.4 107.6 30.1 142.7  45.7
> 10. ae-2.r05.asbnva02.us.bb.gin.  0.0%    10  135.0 109.9 36.6 140.0  39.1
> 11. xe-0-9-0-8.r05.asbnva02.us.c  0.0%    10  147.5 125.6 49.4 165.5  41.1
> 12. 24.52.112.21                  0.0%    10  158.6 124.0 49.6 161.3  41.5
> 13. 24.52.112.42                  0.0%    10  151.0 127.7 52.2 159.0  41.2
> 14. ???                          100.0    10    0.0 0.0 0.0   0.0   0.0
> 
> -- 
> Phillip Lynn
> Software Engineer III
> NetWolves
> Phone:813-579-3214
> Fax:813-882-0209
> Email: phillip.lynn at netwolves.com
> www.netwolves.com
> 


From mel at beckman.org  Mon Jul 11 00:26:15 2016
From: mel at beckman.org (Mel Beckman)
Date: Mon, 11 Jul 2016 00:26:15 +0000
Subject: packet loss question
In-Reply-To: <23A78013-F030-413C-8E34-5AD7D2BEB1E8@mor-pah.net>
References: <577EAAD4.5010405@netwolves.com>,
 <23A78013-F030-413C-8E34-5AD7D2BEB1E8@mor-pah.net>
Message-ID: <0050804F-9510-4605-9D89-66BF748DDC9A@beckman.org>

James,

You may be thinking of this presentation: 

https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf

 -mel beckman

> On Jul 10, 2016, at 4:49 PM, James Greig <James at mor-pah.net> wrote:
> 
> There was a useful nanog presentation somewhere that explained this really well in particular reading traceroutes correctly
> 
> Kind regards
> 
> James Greig 
> 
>> On 7 Jul 2016, at 20:17, Phillip Lynn <phillip.lynn at netwolves.com> wrote:
>> 
>> Hi all,
>> 
>> I am writing because I do not understand what is happening.  I ran mtr against our email server and www.teco.comand below are the results.  I am not a network engineer so I am at a loss.  I think what I am seeing is maybe a hand off issue, between Frontier and Level3Miami2. If I am correct then what can I do?
>> 
>> My system is running Centos 6.5 Linux.
>> 
>> Thanks,
>> 
>> Phillip
>> 
>> 
>> 
>> (! 1011)-> sudo mtr -r netwolves.securence.com
>> HOST: xxxxx at netwolves.comLoss%   Snt   Last   Avg Best  Wrst StDev
>> 1. 172.24.109.1                  0.0%    10    0.6 0.6 0.6   0.7   0.0
>> 2. lo0-100.TAMPFL-VFTTP-322.gni  0.0%    10    3.2 2.0 1.0   4.3   1.2
>> 3. 172.99.44.214                 0.0%    10    4.0 4.9 2.3   6.9   1.5
>> 4. ae8---0.scr02.mias.fl.fronti  0.0%    10    9.3 9.1 7.5   9.8   1.0
>> 5. ae1---0.cbr01.mias.fl.fronti  0.0%    10    8.9   9.1   7.6 9.7 0.7
>> 6. lag-101.ear3.Miami2.Level3.n 80.0%    10    9.0   8.9   8.8 9.0 0.1
>> 7. 10ge9-14.core1.mia1.he.net    0.0%    10   14.3 13.0 7.6  18.1   4.3
>> 8. 10ge1-1.core1.atl1.he.net     0.0%    10   25.6  33.2 22.4  99.7  23.6
>> 9. 10ge10-4.core1.chi1.he.net    0.0%    10   45.6  51.8 45.5  82.7  12.5
>> 10. 100ge14-2.core1.msp1.he.net   0.0%    10   53.6  63.9 53.6 125.2  21.8
>> 11. t4-2-usi-cr02-mpls-usinterne  0.0%    10   53.2  73.1 53.2 225.6  54.0
>> 12. v102.usi-cr04-mtka.usinterne  0.0%    10   53.2  53.9 53.2  55.3   0.6
>> 13. netwolves.securence.com       0.0%    10   53.4  53.9 53.4  55.4   0.7
>> 
>> (! 1014)-> sudo mtr -r www.teco.com
>> HOST: xxxxx at netwolves.comLoss%   Snt   Last   Avg Best  Wrst StDev
>> 1. 172.24.109.1                  0.0%    10    0.6 0.6 0.6   0.7   0.0
>> 2. lo0-100.TAMPFL-VFTTP-322.gni  0.0%    10  104.8 81.4 1.1 113.2  43.2
>> 3. 172.99.47.198                 0.0%    10  115.0 77.8 2.9 115.0  40.2
>> 4. ae7---0.scr01.mias.fl.fronti  0.0%    10  111.1 80.2 8.5 113.5  41.3
>> 5. ae0---0.cbr01.mias.fl.fronti  0.0%    10  105.9  82.2   7.6 115.4 33.8
>> 6. lag-101.ear3.Miami2.Level3.n 70.0%    10  116.1  80.2   8.5 116.1 62.0
>> 7. NTT-level3-80G.Miami.Level3.  0.0%    10  110.0 81.5 9.0 120.3  41.9
>> 8. ae-3.r20.miamfl02.us.bb.gin.  0.0%    10  119.8  84.0 10.0 119.8  38.5
>> 9. ae-4.r23.asbnva02.us.bb.gin. 10.0%    10  137.4 107.6 30.1 142.7  45.7
>> 10. ae-2.r05.asbnva02.us.bb.gin.  0.0%    10  135.0 109.9 36.6 140.0  39.1
>> 11. xe-0-9-0-8.r05.asbnva02.us.c  0.0%    10  147.5 125.6 49.4 165.5  41.1
>> 12. 24.52.112.21                  0.0%    10  158.6 124.0 49.6 161.3  41.5
>> 13. 24.52.112.42                  0.0%    10  151.0 127.7 52.2 159.0  41.2
>> 14. ???                          100.0    10    0.0 0.0 0.0   0.0   0.0
>> 
>> -- 
>> Phillip Lynn
>> Software Engineer III
>> NetWolves
>> Phone:813-579-3214
>> Fax:813-882-0209
>> Email: phillip.lynn at netwolves.com
>> www.netwolves.com
>> 
> 

From marka at isc.org  Mon Jul 11 01:26:26 2016
From: marka at isc.org (Mark Andrews)
Date: Mon, 11 Jul 2016 11:26:26 +1000
Subject: packet loss question
In-Reply-To: Your message of "Fri, 08 Jul 2016 14:02:19 +0000."
 <25577FE1-6366-4D6D-B82E-A779193CB458@beckman.org>
References: <577EAAD4.5010405@netwolves.com>
 <20160707195247.GO18345@sizone.org>,
 <577FA41A.8050303@netwolves.com>
 <25577FE1-6366-4D6D-B82E-A779193CB458@beckman.org>
Message-ID: <20160711012626.C7A4E4DDD425@rock.dv.isc.org>


In message <25577FE1-6366-4D6D-B82E-A779193CB458 at beckman.org>, Mel Beckman writ
es:
> Philip,
>
> Quite often slow Web page loading and email transport -- termed an
> application-layer problem because basic transport seems unaffected -- is
> due to DNS problems, particularly reverse DNS for the IP addresses
> originating your Web queries. If you have non-existent or intermittent
> IN-ADDR entries for those IPs, the remote Web servers can be timing out
> if they have older configurations that, for example, do DNS lookups in
> order to log HTTP requests and block on completion, resulting in
> timeouts. Use "nslookup x.x.x.x" command line queries (nslookup is on
> Windows, Mac and UNIX/Linux) to see if you can resolve the public IP
> addresses your users original queries from. You can find those addresses
> by visiting http://whatismyip.com from a problem desktop.
>
> A second common cause of app-specific throughput problems, particularly
> where email is involved, is failed MTU discovery. The standard Internet
> MTU is 1500 bytes, but sometimes a router misconfiguration or change in
> encapsulation type along the path through your ISP lowers that to, say,
> 1492 or 1486 bytes (MTU is in increments of 8). The result is that
> whenever your web or email client sends a maximum MTU packet, the packet
> is dropped, resulting in connection impairment. Most HTTP and Email
> packets are not max-MTU in size, so you get very uneven performance
> simulating network congestion.

The Internet Standard MTU's are 68 octets for IPv4 (RFC 791) and
1280 octets for IPv6 (RFC 2460).

Every size greater than those is subject to negotiation.  Now most
paths pass packets greater than those values.  Ethernet is very
common and passes 1500.

Encapsulated / translate traffic is also very common and has MTUs
< 1500 and affects BOTH IPv4 and IPv6 data streams and will become
more so as we move from dual stack to IPv6 only where IPv4 is a
service running on top of IPv6.

> You can force the MTU to a lower number at your border to test this. You
> typically do this at your firewall; it's a setting on the WAN interface
> config. Temporarily lower that value dramatically to something like 1440
> and see if your problem goes away. If it does, you may need to
> permanently reduce MTU, so you should try other divisible-by-8 values --
> 1492, 1486, 1478, etc -- until you find the largest one that works. I
> commonly see this when a customer switches ISPs from DSL to Cable. Cable
> providers are fond of stealing 8 or 16 bytes for their CMT headers in a
> way that breaks MTU discovery.
>
> A third frequent application-layer throughout debillitator is IPv6
> misconfiguration. If you support IPv6 for your end users, they may be
> getting directed to IPv6 web or mail servers (which are generally
> preferred via DNS) but thwarted by IPv6 transport issues, which could be
> as simple as routing or MTU, or as complex as an invisible 6-over-4 NAT
> somewhere (such as a your upstream ISP). These problems generally require
> an IPv6-competent network engineer to resolve, but you can test by
> disabling IPv6 on your network (which also requires an IPv6-competent
> network engineer :)
>
> I'm always amazed at how often these three causes are at the root of
> performance problems. So it's worth investigating each.
>
>  -mel beckman
>
> > On Jul 8, 2016, at 6:02 AM, Phillip Lynn <phillip.lynn at netwolves.com>
> wrote:
> >
> >> On 07/07/2016 03:52 PM, Ken Chase wrote:
> >> No offence, but i swear that mtr should come with a license to use it.
> I get more
> >> questions from people accusing us of network issues with mtr in hand...
> >>
> >> You shoudlnt care that there's 80% packet loss in the middle of your
> route, unless
> >> you have actual traffic to lag-101.ear3.miami2.level3.net. I suspect
> you dont.
> >> (If you did, you'd have mtr'd to it directly of course.)
> >>
> >> As for your second trace, the sudden jump from 0% on 2nd last hop to
> 100% last
> >> hop packetloss seems like firewalling to me. (long discussion about the
> >> probabilities of getting 5 0%pl hops in a row and 100% on an
> unfirewalled
> >> endpoint elided. TL;DR: use more packets in your test -i 0.1 -c 100
> thanks).
> >>
> >> If you have 0% packetloss to your target endpoint, is there an issue
> here?
> >> What caused you to mtr?  0% pl is pretty good. You could play quake 1.0
> >> through that pl and ping time. The +20ms ATL<>CHI jump in the route
> you'd have
> >> to take up with einstein/bill nye/$deity.
> >>
> >> For the 2nd trace, the 1st hop is your latency issue (plus the big
> jump from
> >> miami<>ashburn, again the limit is c.)
> >>
> >> ICMP is allowed to be dropped by intervening routers. Someone will
> quote an RFC
> >> at us shortly.
> >>
> >> Mtr without a return route is not that useful in figuring out
> packetloss
> >> because pl requires the packet make it there and back. Pl could be
> anywhere on
> >> the return route, which is probably not symmetrical. The internet
> stopped
> >> being symetrical about 20+ years ago (if it ever even loosely was), so
> get a friend
> >> to send you an mtr to your ip from the farside.
> >>
> >> (I remember a project long ago, some cgi-bin (yeah that long ago) that
> was
> >> basically a full-path forward+reverse traceroute you could hit on a
> selected
> >> server at the provider.  Rather handy. not sure if its still a thing,
> or what it was
> >> called.)
> >>
> >> /kc
> >>
> >>
> >> On Thu, Jul 07, 2016 at 03:17:40PM -0400, Phillip Lynn said:
> >>   >Hi all,
> >>   >
> >>   >  I am writing because I do not understand what is happening.  I
> ran mtr
> >>   >against our email server and www.teco.comand below are the results.
>  I am
> >>   >not a network engineer so I am at a loss.  I think what I am seeing
> is
> >>   >maybe a hand off issue, between Frontier and Level3Miami2. If I am
> correct
> >>   >then what can I do?
> >>   >
> >>   >  My system is running Centos 6.5 Linux.
> >>   >
> >>   >Thanks,
> >>   >
> >>   >Phillip
> >>   >
> >>   >
> >>   >
> >>   >(! 1011)-> sudo mtr -r netwolves.securence.com
> >>   >HOST: xxxxx at netwolves.comLoss%   Snt   Last   Avg Best  Wrst StDev
> >>   >  1. 172.24.109.1                  0.0%    10    0.6 0.6 0.6   0.7
>  0.0
> >>   >  2. lo0-100.TAMPFL-VFTTP-322.gni  0.0%    10    3.2 2.0 1.0   4.3
>  1.2
> >>   >  3. 172.99.44.214                 0.0%    10    4.0 4.9 2.3   6.9
>  1.5
> >>   >  4. ae8---0.scr02.mias.fl.fronti  0.0%    10    9.3 9.1 7.5   9.8
>  1.0
> >>   >  5. ae1---0.cbr01.mias.fl.fronti  0.0%    10    8.9   9.1   7.6
> 9.7 0.7
> >>   >  6. lag-101.ear3.Miami2.Level3.n 80.0%    10    9.0   8.9   8.8
> 9.0 0.1
> >>   >  7. 10ge9-14.core1.mia1.he.net    0.0%    10   14.3 13.0 7.6  18.1
>   4.3
> >>   >  8. 10ge1-1.core1.atl1.he.net     0.0%    10   25.6  33.2 22.4
> 99.7  23.6
> >>   >  9. 10ge10-4.core1.chi1.he.net    0.0%    10   45.6  51.8 45.5
> 82.7  12.5
> >>   > 10. 100ge14-2.core1.msp1.he.net   0.0%    10   53.6  63.9 53.6
> 125.2  21.8
> >>   > 11. t4-2-usi-cr02-mpls-usinterne  0.0%    10   53.2  73.1 53.2
> 225.6  54.0
> >>   > 12. v102.usi-cr04-mtka.usinterne  0.0%    10   53.2  53.9 53.2
> 55.3   0.6
> >>   > 13. netwolves.securence.com       0.0%    10   53.4  53.9 53.4
> 55.4   0.7
> >>   >
> >>   >(! 1014)-> sudo mtr -r www.teco.com
> >>   >HOST: xxxxx at netwolves.comLoss%   Snt   Last   Avg Best  Wrst StDev
> >>   >  1. 172.24.109.1                  0.0%    10    0.6 0.6 0.6   0.7
>  0.0
> >>   >  2. lo0-100.TAMPFL-VFTTP-322.gni  0.0%    10  104.8 81.4 1.1 113.2
>  43.2
> >>   >  3. 172.99.47.198                 0.0%    10  115.0 77.8 2.9 115.0
>  40.2
> >>   >  4. ae7---0.scr01.mias.fl.fronti  0.0%    10  111.1 80.2 8.5 113.5
>  41.3
> >>   >  5. ae0---0.cbr01.mias.fl.fronti  0.0%    10  105.9  82.2   7.6
> 115.4 33.8
> >>   >  6. lag-101.ear3.Miami2.Level3.n 70.0%    10  116.1  80.2   8.5
> 116.1 62.0
> >>   >  7. NTT-level3-80G.Miami.Level3.  0.0%    10  110.0 81.5 9.0 120.3
>  41.9
> >>   >  8. ae-3.r20.miamfl02.us.bb.gin.  0.0%    10  119.8  84.0 10.0
> 119.8  38.5
> >>   >  9. ae-4.r23.asbnva02.us.bb.gin. 10.0%    10  137.4 107.6 30.1
> 142.7  45.7
> >>   > 10. ae-2.r05.asbnva02.us.bb.gin.  0.0%    10  135.0 109.9 36.6
> 140.0  39.1
> >>   > 11. xe-0-9-0-8.r05.asbnva02.us.c  0.0%    10  147.5 125.6 49.4
> 165.5  41.1
> >>   > 12. 24.52.112.21                  0.0%    10  158.6 124.0 49.6
> 161.3  41.5
> >>   > 13. 24.52.112.42                  0.0%    10  151.0 127.7 52.2
> 159.0  41.2
> >>   > 14. ???                          100.0    10    0.0 0.0 0.0   0.0
>  0.0
> >>   >
> >>   >--
> >>   >Phillip Lynn
> >>   >Software Engineer III
> >>   >NetWolves
> >>   >Phone:813-579-3214
> >>   >Fax:813-882-0209
> >>   >Email: phillip.lynn at netwolves.com
> >>   >www.netwolves.com
> >>   >
> >>
> >
> > None taken,
> >
> >  We are having issues with our email and loading some web pages. I used
> mtr to try and find if there is a possible connection issue.  I just need
> to understand what is happening , and be able to explain the output
> showing the 80% packet loss .  We are not pointing fingers, just looking
> to understand the issue better.
> >
> > Thanks
> >
> > --
> > Phillip Lynn
> > Software Engineer III
> > NetWolves
> > Phone:813-579-3214
> > Fax:813-882-0209
> > Email: phillip.lynn at netwolves.com
> > www.netwolves.com
> >

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

From diotonante at gmail.com  Mon Jul 11 07:10:56 2016
From: diotonante at gmail.com (Davide Davini)
Date: Mon, 11 Jul 2016 09:10:56 +0200
Subject: IPv6 deployment excuses
In-Reply-To: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
Message-ID: <222bac2d-800b-93c7-7d17-bd469e858184@gmail.com>

On 01/07/2016 21:52, Mike Jones wrote:
> I am in contact with a couple of network operators trying to prod them
> to deploy IPv6, I figured that 10 minutes to send a couple of emails
> was worth the effort to make them "see a customer demand" (now none of
> them can use the excuse that nobody has asked for it!), but the
> replies I got were less than impressive to say the least.
> 
> I was wondering if you guys could summarise your experiences with
> people who make excuses for not deploying IPv6? I regularly see a
> specific person saying "we can't deploy it because X" followed by you
> guys "correcting them" and telling them how to deploy it without the
> problems they claim they will have, but that is only a small snapshot
> of the people who bother to post about their ignorance in public. I
> suspect there is also a lot of selection-bias in the NANOG membership
> base but you deal with a lot of enterprise networks off of this list
> so probably have broader experience than the NANOG archives.
> 
> Can we have a thread summarising the most common excuses you've heard,
> and if they are actual problems blocking IPv6 deployment or just down
> to ignorance? Perhaps this could be the basis for an FAQ type page
> that I can point people to when they say they don't know how to deploy
> IPv6 on their networks? :)

Our provider sale representative, who is the most tech savvy sale-rep I
ever encountered by far, which is not a very high bar, but still, said
something like:
"You shouldn't worry about that, we have plenty of IPv4 addresses
left... and besides we are "working on it(TM)"... it's going to be
deployed next year... probably "

Needless to say I'm still waiting. :)

Ciao,
Davide Davini



From marka at isc.org  Mon Jul 11 07:24:19 2016
From: marka at isc.org (Mark Andrews)
Date: Mon, 11 Jul 2016 17:24:19 +1000
Subject: IPv6 deployment excuses
In-Reply-To: Your message of "Mon, 11 Jul 2016 09:10:56 +0200."
 <222bac2d-800b-93c7-7d17-bd469e858184@gmail.com>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <222bac2d-800b-93c7-7d17-bd469e858184@gmail.com>
Message-ID: <20160711072419.77CF44DF3704@rock.dv.isc.org>


In message <222bac2d-800b-93c7-7d17-bd469e858184 at gmail.com>, Davide Davini writ
es:
> On 01/07/2016 21:52, Mike Jones wrote:
> > I am in contact with a couple of network operators trying to prod them
> > to deploy IPv6, I figured that 10 minutes to send a couple of emails
> > was worth the effort to make them "see a customer demand" (now none of
> > them can use the excuse that nobody has asked for it!), but the
> > replies I got were less than impressive to say the least.
> > 
> > I was wondering if you guys could summarise your experiences with
> > people who make excuses for not deploying IPv6? I regularly see a
> > specific person saying "we can't deploy it because X" followed by you
> > guys "correcting them" and telling them how to deploy it without the
> > problems they claim they will have, but that is only a small snapshot
> > of the people who bother to post about their ignorance in public. I
> > suspect there is also a lot of selection-bias in the NANOG membership
> > base but you deal with a lot of enterprise networks off of this list
> > so probably have broader experience than the NANOG archives.
> > 
> > Can we have a thread summarising the most common excuses you've heard,
> > and if they are actual problems blocking IPv6 deployment or just down
> > to ignorance? Perhaps this could be the basis for an FAQ type page
> > that I can point people to when they say they don't know how to deploy
> > IPv6 on their networks? :)
> 
> Our provider sale representative, who is the most tech savvy sale-rep I
> ever encountered by far, which is not a very high bar, but still, said
> something like:
> "You shouldn't worry about that, we have plenty of IPv4 addresses
> left... and besides we are "working on it(TM)"... it's going to be
> deployed next year... probably "
> 
> Needless to say I'm still waiting. :)
> 
> Ciao,
> Davide Davini

The default comeback to that is: Are you going to give the addresses
to the people I need to talk to that don't have a unshared IPv4
addresses but do have IPv6 addressess?  I thought not, so get off
you a#$e and deliver IPv6 today.  You are already way too late
delivering IPv6.  It's not like you didn't already have a decade
to plan how to deliver it.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

From diotonante at gmail.com  Mon Jul 11 08:47:29 2016
From: diotonante at gmail.com (Davide Davini)
Date: Mon, 11 Jul 2016 10:47:29 +0200
Subject: IPv6 deployment excuses
In-Reply-To: <20160711072419.77CF44DF3704@rock.dv.isc.org>
References: <CAAAas8FTX1Bn9hMMbTP4tLusxW-mRs1L+e8Thnz4QpFuH6pHBg@mail.gmail.com>
 <222bac2d-800b-93c7-7d17-bd469e858184@gmail.com>
 <20160711072419.77CF44DF3704@rock.dv.isc.org>
Message-ID: <182fd1fe-2650-1e3a-0840-ac0a6b426ce8@gmail.com>

On 11/07/2016 09:24, Mark Andrews wrote:
>> Our provider sale representative, who is the most tech savvy sale-rep I
>> ever encountered by far, which is not a very high bar, but still, said
>> something like:
>> "You shouldn't worry about that, we have plenty of IPv4 addresses
>> left... and besides we are "working on it(TM)"... it's going to be
>> deployed next year... probably "
>>
>> Needless to say I'm still waiting. :)
>
> The default comeback to that is: Are you going to give the addresses
> to the people I need to talk to that don't have a unshared IPv4
> addresses but do have IPv6 addresses?  I thought not, so get off
> you a#$e and deliver IPv6 today.  You are already way too late
> delivering IPv6.  It's not like you didn't already have a decade
> to plan how to deliver it.

I don't think it's going to go a long way being rude to them. :)

We would have chosen another ISP that offered IPv6 if the alternatives
in the price range were half as good but they ain't...

More people should ask for it, that's the way to go in my opinion. As
for us I'm going to keep pestering them on regular basis on the subject
but it's obvious I'm not part of a majority. The truth is though IPv6 is
not yet mandatory for our business and that's why we prefer a all-around
better provider then a lesser one that deployed IPv6.

My 2 euro cents.

Ciao,
Davide Davini

From prnpetrov at yandex.com  Sun Jul 10 18:53:52 2016
From: prnpetrov at yandex.com (Nikolai Petrov)
Date: Sun, 10 Jul 2016 21:53:52 +0300
Subject: New Office, New Network. Questions.
Message-ID: <460541468176832@web10h.yandex.ru>

Hello NANOG,
I am Nikolai and I am a Network Administrator in a Russian middle-sized company. We do not have a large list with Networks in Russia so I am using the American list. I hope you can help me with some problems that I have. 

We are moving to our new offices in two months and I have access to the building already. My task is to set up the entire network for the company. The previous administrator has left the company and I thought of taking the chance to remove some "technical debt" and make everything from scratch again. I am alone in the network administration and about one month ago I got an intern to help me but she is a student so she doesn't know much.

I was told to move the networks this week and I have spent a lot of time thinking about how I should do it. I am sitting here with an initial plan but I have some questions that I did not manage to find complete information about. I would like your help if you can give it. I summarized my questins below and no matter how much I looked I could not find a lot of inromation and I am still confused.

1. Currently we do not have IPv6 in our network but I have seen the ISP is giving us a "/56 Block" which from what I understand is a couple hundred "/64 Subnets". I think you can only have /64 subnets in IPv6. In our IPv4 setup we have 32 addresses, four of which I will use for NAT and the remaining needed for online services and servers. In IPv6 we have a lot of addresses but I am not sure whether I should give an address of the ISP to every device. I found that there is an organization that can help avoid collisions in private IPs: https://www.sixxs.net/tools/grh/ula/ . From what I can tell it is just a registry, but I am thinking of registering the ranges there and then use these subnets and NAT them to the IPv6 address of the router. However, I noticed something strange. The WAN port of our router gets a /64 IPv6 address which is not in our IPv6. Should I use this for NAT or one of "our" addresses?

2. The previous administrator did some bad job in some parts of the network. We have an internal router protocol to move traffic between routers, but in some cases he used NAT instead of adding these subnets to the router protocol. Everything works and all things that have to be reached are reachable, however I think this is bad and we should use the router protocol for all parts of the network. I have found two protocols in our router that are good and support IPv6 and they are OSPF and BGP. I did not manage to have BGP work and it is slow so I am thinking of OSPF. Do uou think it is a good choice for IPv6 and IPv4? If I have two separate paths of 1 Gb/s, will I transfer files at 2 Gb/s?

3. In our old network we use "VRRP" which from what I know is a system for routers to shae IPs and load balance or "failover" the traffic. I have seen that IPv6 has a built-in system which is similar and has something like priorities, etc. What happens if I have two routers with same priority? Whic is used as default gateway? Is it load balancing? Also, can I use "VRRP" to load balance traffic to our DNS look-up "recursor"? 

Thank you for your answers,
Nikolai.

From Valdis.Kletnieks at vt.edu  Mon Jul 11 14:56:07 2016
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 11 Jul 2016 10:56:07 -0400
Subject: New Office, New Network. Questions.
In-Reply-To: <460541468176832@web10h.yandex.ru>
References: <460541468176832@web10h.yandex.ru>
Message-ID: <73676.1468248967@turing-police.cc.vt.edu>

On Sun, 10 Jul 2016 21:53:52 +0300, Nikolai Petrov said:

> 1. Currently we do not have IPv6 in our network but I have seen the ISP is
> giving us a "/56 Block" which from what I understand is a couple hundred "/64
> Subnets". I think you can only have /64 subnets in IPv6. In our IPv4 setup we

You can have other sized subnets, but 64 is very handy if you intend to use
SLAAC auto-configure.  There's also the danger of running into broken equipment
that doesn't understand other sized subnets (similar to very old IPv4 gear that
understood a /24, but exploded if told about a /23 or /25).

> have 32 addresses, four of which I will use for NAT and the remaining needed
> for online services and servers. In IPv6 we have a lot of addresses but I am
> not sure whether I should give an address of the ISP to every device. I found

Assign a /64 to everyplace that you would assign a subnet in IPv4.  Give each
device on that subnet its own address. Use DHCPv6 or SLAAC or both, whatever
gets the job done in your situation. Don't worry about NAT anymore, you have
enough addresses.

> that there is an organization that can help avoid collisions in private IPs:
> https://www.sixxs.net/tools/grh/ula/ . From what I can tell it is just a
> registry, but I am thinking of registering the ranges there and then use these
> subnets and NAT them to the IPv6 address of the router.

Don't do that. NAT was invented to fix a problem that IPv6 doesn't have. Feel
free to give every single device a global address. (You'll still want a
stateful firewall someplace, but it doesn't have to do NAT, it just has to keep
track of legitimate versus malicious traffic).

And don't freak out if a device has more than one address.  As I'm writing this
from the sofa in my living room, my laptop wireless has:

ra0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.150  netmask 255.255.255.224  broadcast 192.168.1.159
        inet6 2601:5c0:c100:6431:cad7:19ff:fe37:c02  prefixlen 64  scopeid 0x0<global>
        inet6 2601:5c0:c100:6431:c01:a589:19a4:236e  prefixlen 64  scopeid 0x0<global>
        inet6 2601:5c0:c100:6431::d67  prefixlen 128  scopeid 0x0<global>
        inet6 2601:5c0:c100:6431:1dc3:657:eda6:8abf  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::cad7:19ff:fe37:c02  prefixlen 64  scopeid 0x20<link>
        inet6 2601:5c0:c100:6431:ad68:c60c:583:19e9  prefixlen 64  scopeid 0x0<global>
        ether c8:d7:19:37:0c:02  txqueuelen 1000  (Ethernet)

(One DHCPv6 - ::d67.  One SLAAC - the one with ff:fe in it.  And 4 different
RFC3041 privacy addresses that it's chunked out over the weekend.  It works
just fine that way - and it's *designed* to do so.  (Of course, in a corporate
environment, you may want to turn the privacy addresses off, and only use
one of DHCPv6/SLAAC - I do it this way because it tests for broken software...)

Oh, and don't block ICMPv6. :)

> something strange. The WAN port of our router gets a /64 IPv6 address which is
> not in our IPv6. Should I use this for NAT or one of "our" addresses?

You use it for the IP address of the provider-facing interface of your router.
Assign the "inside" interface(s) addresses on the appropriate /64 subnet that
they will be on.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160711/8929de30/attachment.pgp>

From nanogml at Mail.DDoS-Mitigator.net  Mon Jul 11 15:57:56 2016
From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog)
Date: Mon, 11 Jul 2016 08:57:56 -0700
Subject: New Office, New Network. Questions.
In-Reply-To: <460541468176832@web10h.yandex.ru>
References: <460541468176832@web10h.yandex.ru>
Message-ID: <20160711155756.GA7091@Mail.DDoS-Mitigator.net>


hi nikolai

- oops.. this got long based on my experiences/opinions :-)

On 07/10/16 at 09:53pm, Nikolai Petrov wrote:
> We are moving to our new offices in two months and I have access to the building already.
> My task is to set up the entire network for the company.
> The previous administrator has left the company and I thought of taking the chance to remove some "technical debt" and make everything from scratch again.

all good ... 

> I was told to move the networks this week 

do you have the routers, switches, cables, few servers for testing ?
has your ISP installed their internet uplink connectivity to the bldg ?

if so, than the above management is on their toes 
otherwise, you'd need to rattle some $$$ loose to buying missing hw :-)

> and I have spent a lot of time thinking about how I should do it.

good ... now's the chance to fix the problems if any ..

> 1. Currently we do not have IPv6 in our network 

implies a learning IPv6 curve ( red flag for possible time-wasting hogs )

if the task is to mvoe the entire "mid-sized" from current bldg to new bdlg, 
i'd suggest use "known/good/working/best-practices" methodology to move
the company.  first get the new bldg with new test servers working
with IPv4 ( the way you want it done ) and "working" the current bldg 
which should take a few hours :-)

than work with IPv6 issues 

> but I have seen the ISP is giving us a "/56 Block" 

good

> which from what I understand is a couple hundred "/64 Subnets".
> I think you can only have /64 subnets in IPv6.

nah ... you can subnet your /56 into whatever you want

> In our IPv4 setup we have 32 addresses,
> four of which I will use for NAT 
> and the remaining needed for online services and servers.

good ... use that to test everything 

since you want or going to use NAT, you have the standard
internal LAN for the bldg can use the standard 10/8 or 
192.168/16 or 172.16/12

so far.. nothing new/special/problematic

> In IPv6 we have a lot of addresses but I am not sure whether 
> I should give an address of the ISP to every device.

why would you want to complicate time-restricted ( 1month )
to get the new bldg working with IPv6 w/out having prior
IPv6 experience ?

remember, "all eyes" will be looking to you to move the
whole company from current bldg to new bldg without delay

> I found that there is an organization that can help avoid collisions 
> in private IPs: https://www.sixxs.net/tools/grh/ula/ .

there should never be any collision in IP#, ipv4 or ipv6

>  From what I can tell it is just a registry, but I am thinking of 
> registering the ranges there and then use these subnets and 
> NAT them to the IPv6 address of the router.

the ISP provides you the range of IPv6 assigned to you

if your current bldg does NOT have IPv6, you might not be
able to easily test the new IPv6 stuff in the new bldg

you might be able to test your new IPv6 connections
at the local coffee shop or other public places but
that's a major security violation since your new IPv6
has no security pre-cautions installed yet

you should be paranoid about trojans/worms/mailware piggie
backing into your new un-secured new bldg IPv6 infrastructure
or IPv4 infrastructure

> However, I noticed something strange. The WAN port of our
> router gets a /64 IPv6 address which is not in our IPv6.

why strange ??

routers get its IP# from dhcpv6 or statically  assigned

> Should I use this for NAT or one of "our" addresses?

you need to fix this problem before continuing .. 
( explain why the IPv6/64 is not what you're expecting )

NAT is NOT the solution ...

> 2. The previous administrator did some bad job in some parts of the network.

:-) that will always be true 90% of the time :-)

some things are always gonna be "bad"

> We have an internal router protocol to move traffic between routers, 
> but in some cases he used NAT instead of adding these subnets to the 
> router protocol. Everything works and all things that have to be 
> reached are reachable, 

if it works .. why is is "bad" ??

there might be dozens of different ways to make things work 
( "things that have to be reachable are reachable" )

> however I think this is bad 

not necessarily a bad thing

> and we should use the router protocol for all parts of the network.

why ?

> I have found two protocols in our router that are good and support 
> IPv6 and they are OSPF and BGP.

there might be more :-)

>  I did not manage to have BGP work 

what part is not working ?

google/yahoo the error messages :-) 

> and it is slow so I am thinking of OSPF. 

sometimes, which works first/better/easiest might be
a good option, thus trying other things is good, but
that can also create more headaches too .. more problems
to (fun) solve

> Do uou think it is a good choice for IPv6 and IPv4? 

i'd work with IPv4 first ... 
and more importantly... there is NO excuse why IPv4 doesn't
or cannot work in the new bldg

after IPv4 works in the new bldg as good as it does in the current
bldg, you have time for "( IPv6 ) learning experiements"

> If I have two separate paths of 1 Gb/s, will I transfer files at 2 Gb/s?

no ... you will be able to transfer 1Gb/s each ..

if you "channel bond" the two 1Gb/s into "one link",
than you might be able to see 1.9Gb/s uplinks .. never 2G/s

if you have 2 1G/s uplinks ... you should have the 2 routers
crosslinked for failover unless uplink speed is more
important than failover

> 3. In our old network we use "VRRP" which from what I know 
> is a system for routers to shae IPs and load balance or "failover" the traffic.

good

> I have seen that IPv6 has a built-in system which is similar 
> and has something like priorities, etc. What happens if I have 
> two routers with same priority?

same rules/issues apply to IPv4

one router/path should always have priority over the other
depending on destinations .... lots of testing to see which
packets goes thru which uplinks

> Whic is used as default gateway?

depends..

engineering/manufacturing uses router1
hr/accting uses router2

or

public DMZ uses router1
corp LAN uses router2

but in either case, router1 and rotuer2 should be crosslinked
if failover is important

> Is it load balancing? Also, can I use "VRRP" to load balance traffic
> to our DNS look-up "recursor"? 

dozen ways to do load balancing ... more problems to resolvea
and prioritize based on your company visibility online

load balancing should be worried about:
- dns, www traffic, email traffic, DVD/video/music downloading,

also always have 3 hot-swap complete infrastrucure and backups
fw1 + dns1 + www1 + mail1 + NAT1
fw2 + dns2 + www2 + mail2 + NAT2
fw3 + dns3 + www3 + mail3 + NAT3

fw only runs iptables for inline fw for entire dmz/localLan
dns only runs bind and iptables and nothing else
www only runs apache and iptables and nothing else
mail only runs sendmail and iptables and nothing else
nat only runs NAT + iptables

each backup its bind/sendmail/apache data to the other 2 boxes, but 
bind/sendmail/apache itself is turned off on the other hot backups

magic pixie dust
alvin
#
# DDoS-Mitigator.net
#

From bill at herrin.us  Mon Jul 11 18:40:19 2016
From: bill at herrin.us (William Herrin)
Date: Mon, 11 Jul 2016 14:40:19 -0400
Subject: New Office, New Network. Questions.
In-Reply-To: <460541468176832@web10h.yandex.ru>
References: <460541468176832@web10h.yandex.ru>
Message-ID: <CAP-guGU2nW-rYjoKpDk2xVY4bzLddGkR-vyG+iKmZ025i140RA@mail.gmail.com>

On Sun, Jul 10, 2016 at 2:53 PM, Nikolai Petrov <prnpetrov at yandex.com> wrote:
> I thought of taking the chance to remove some
> "technical debt" and make everything from
> scratch again.

Hi Nikolai,

This is a rookie mistake. Every in-place system encodes business
knowledge, most of it forgotten and much of it still relevant. From
your comments I infer that you haven't been doing the job long enough
to know where the skeletons are buried.


> 1. Currently we do not have IPv6 in our network but I
> have seen the ISP is giving us a "/56 Block" which
> from what I understand is a couple hundred "/64 Subnets".

Good for you! We've been urging folks to deploy IPv6 for years and
you're taking the advice to heart.

Now stop. IPv6 has enough inherent issues and problems that you'll
want to deploy it when your configuration is otherwise quiescent. If
you do it while also making other large changes, you're begging to get
hurt.



> 2. The previous administrator did some bad
>  job in some parts of the network. We have
> an internal router protocol to move traffic between
> routers, but in some cases he used NAT instead
> of adding these subnets to the router protocol.

I urge you to tread lightly. You don't know what business knowledge
was encoded in this configuration. Maybe the servers respond
differently depending on whether the source is internal or external
and some of the origins should be treated to the external rules.


> I have found two protocols in our router that are
> good and support IPv6 and they are OSPF
> and BGP.

OSPF is an interior gateway protocol. Use between routers within your
network. BGP is an exterior gateway protocol. Use it when you want to
talk to multiple ISPs at the same time.



> 3. In our old network we use "VRRP" which from
> what I know is a system for routers to shae IPs
> and load balance or "failover" the traffic. I have
> seen that IPv6 has a built-in system which is similar
> and has something like priorities, etc. What
> happens if I have two routers with same priority?

If the guy who wrote the stack wasn't asleep at the switch, the host
will pick one and use it as long as the router keeps advertising it.
But it's not a good idea to tempt fate - set each router at a
different priority.

IPv6 router advertisements are nothing like IPv4 VRRP. In IPv4, hosts
receive a single default gateway. VRRP lets two or more routers decide
among themselves who will serve up the IP address for that default
gateway. And then swap it when the router serving the address breaks.

IPv6 hosts can have more than one default gateway. Each router with a
path to the Internet can offer act as a default gateway and hosts will
accept and use it. Preventing machines which should not act as default
gateways from making offers that the hosts hear and use is one of the
many idiosyncrasies you'll enjoy debugging when you first deploy IPv6.


> Also, can I use "VRRP" to load balance traffic to
> our DNS look-up "recursor"?

No. VRRP is a failover system. It has nothing to do with load balancing.

Regards,
Bill Herrin



-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From brak at gameservers.com  Mon Jul 11 18:46:08 2016
From: brak at gameservers.com (Brian Rak)
Date: Mon, 11 Jul 2016 14:46:08 -0400
Subject: Comcast postmaster?
Message-ID: <8d843c14-932e-af4b-117d-7fd1c8adc9cd@gameservers.com>

Is there anyone here that can put me in touch with a Comcast mail server 
administrator?  It seems that they've firewalled off some of our IPv6 
space, and I can't seem to find any contact information.

Interestingly, I can't even fill out their blocklist removal form, 
because it only accepts IPv4 addresses.


From surfer at mauigateway.com  Mon Jul 11 19:04:29 2016
From: surfer at mauigateway.com (Scott Weeks)
Date: Mon, 11 Jul 2016 12:04:29 -0700
Subject: New Office, New Network. Questions.
Message-ID: <20160711120429.761B961B@m0087797.ppops.net>



--- bill at herrin.us wrote:
From: William Herrin <bill at herrin.us>

> Also, can I use "VRRP" to load balance traffic to
> our DNS look-up "recursor"?

No. VRRP is a failover system. It has nothing to do 
with load balancing.
------------------------------------------------


I have seen this before:

rtr1 and rtr2 have two vrrp groups.  rtr1 is set for 
primary on, say, .1 and rtr2 primary for .2.  Then, 
the dfg of all odd IP addresses (or some selection 
process like that) is .1 and all even IP addresses 
have a dfg of .2.  There're endless variations, but 
the idea is the same.  And you still get the vrrp 
failover when one router gets pissed off and walks 
away.

scott

From James at mor-pah.net  Mon Jul 11 21:49:01 2016
From: James at mor-pah.net (James Greig)
Date: Mon, 11 Jul 2016 22:49:01 +0100
Subject: packet loss question
In-Reply-To: <0050804F-9510-4605-9D89-66BF748DDC9A@beckman.org>
References: <577EAAD4.5010405@netwolves.com>
 <0050804F-9510-4605-9D89-66BF748DDC9A@beckman.org>
Message-ID: <A0A3D766-1C73-405F-B38C-5FF3D221774F@mor-pah.net>

That's the one:) 

Kind regards

James Greig 

> On 11 Jul 2016, at 01:26, Mel Beckman <mel at beckman.org> wrote:
> 
> James,
> 
> You may be thinking of this presentation: 
> 
> https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf
> 
> -mel beckman
> 
>> On Jul 10, 2016, at 4:49 PM, James Greig <James at mor-pah.net> wrote:
>> 
>> There was a useful nanog presentation somewhere that explained this really well in particular reading traceroutes correctly
>> 
>> Kind regards
>> 
>> James Greig 
>> 
>>> On 7 Jul 2016, at 20:17, Phillip Lynn <phillip.lynn at netwolves.com> wrote:
>>> 
>>> Hi all,
>>> 
>>> I am writing because I do not understand what is happening.  I ran mtr against our email server and www.teco.comand below are the results.  I am not a network engineer so I am at a loss.  I think what I am seeing is maybe a hand off issue, between Frontier and Level3Miami2. If I am correct then what can I do?
>>> 
>>> My system is running Centos 6.5 Linux.
>>> 
>>> Thanks,
>>> 
>>> Phillip
>>> 
>>> 
>>> 
>>> (! 1011)-> sudo mtr -r netwolves.securence.com
>>> HOST: xxxxx at netwolves.comLoss%   Snt   Last   Avg Best  Wrst StDev
>>> 1. 172.24.109.1                  0.0%    10    0.6 0.6 0.6   0.7   0.0
>>> 2. lo0-100.TAMPFL-VFTTP-322.gni  0.0%    10    3.2 2.0 1.0   4.3   1.2
>>> 3. 172.99.44.214                 0.0%    10    4.0 4.9 2.3   6.9   1.5
>>> 4. ae8---0.scr02.mias.fl.fronti  0.0%    10    9.3 9.1 7.5   9.8   1.0
>>> 5. ae1---0.cbr01.mias.fl.fronti  0.0%    10    8.9   9.1   7.6 9.7 0.7
>>> 6. lag-101.ear3.Miami2.Level3.n 80.0%    10    9.0   8.9   8.8 9.0 0.1
>>> 7. 10ge9-14.core1.mia1.he.net    0.0%    10   14.3 13.0 7.6  18.1   4.3
>>> 8. 10ge1-1.core1.atl1.he.net     0.0%    10   25.6  33.2 22.4  99.7  23.6
>>> 9. 10ge10-4.core1.chi1.he.net    0.0%    10   45.6  51.8 45.5  82.7  12.5
>>> 10. 100ge14-2.core1.msp1.he.net   0.0%    10   53.6  63.9 53.6 125.2  21.8
>>> 11. t4-2-usi-cr02-mpls-usinterne  0.0%    10   53.2  73.1 53.2 225.6  54.0
>>> 12. v102.usi-cr04-mtka.usinterne  0.0%    10   53.2  53.9 53.2  55.3   0.6
>>> 13. netwolves.securence.com       0.0%    10   53.4  53.9 53.4  55.4   0.7
>>> 
>>> (! 1014)-> sudo mtr -r www.teco.com
>>> HOST: xxxxx at netwolves.comLoss%   Snt   Last   Avg Best  Wrst StDev
>>> 1. 172.24.109.1                  0.0%    10    0.6 0.6 0.6   0.7   0.0
>>> 2. lo0-100.TAMPFL-VFTTP-322.gni  0.0%    10  104.8 81.4 1.1 113.2  43.2
>>> 3. 172.99.47.198                 0.0%    10  115.0 77.8 2.9 115.0  40.2
>>> 4. ae7---0.scr01.mias.fl.fronti  0.0%    10  111.1 80.2 8.5 113.5  41.3
>>> 5. ae0---0.cbr01.mias.fl.fronti  0.0%    10  105.9  82.2   7.6 115.4 33.8
>>> 6. lag-101.ear3.Miami2.Level3.n 70.0%    10  116.1  80.2   8.5 116.1 62.0
>>> 7. NTT-level3-80G.Miami.Level3.  0.0%    10  110.0 81.5 9.0 120.3  41.9
>>> 8. ae-3.r20.miamfl02.us.bb.gin.  0.0%    10  119.8  84.0 10.0 119.8  38.5
>>> 9. ae-4.r23.asbnva02.us.bb.gin. 10.0%    10  137.4 107.6 30.1 142.7  45.7
>>> 10. ae-2.r05.asbnva02.us.bb.gin.  0.0%    10  135.0 109.9 36.6 140.0  39.1
>>> 11. xe-0-9-0-8.r05.asbnva02.us.c  0.0%    10  147.5 125.6 49.4 165.5  41.1
>>> 12. 24.52.112.21                  0.0%    10  158.6 124.0 49.6 161.3  41.5
>>> 13. 24.52.112.42                  0.0%    10  151.0 127.7 52.2 159.0  41.2
>>> 14. ???                          100.0    10    0.0 0.0 0.0   0.0   0.0
>>> 
>>> -- 
>>> Phillip Lynn
>>> Software Engineer III
>>> NetWolves
>>> Phone:813-579-3214
>>> Fax:813-882-0209
>>> Email: phillip.lynn at netwolves.com
>>> www.netwolves.com
>> 


From cpolish at surewest.net  Mon Jul 11 19:04:17 2016
From: cpolish at surewest.net (cpolish at surewest.net)
Date: Mon, 11 Jul 2016 12:04:17 -0700
Subject: packet loss question
In-Reply-To: <20160711012626.C7A4E4DDD425@rock.dv.isc.org>
References: <577EAAD4.5010405@netwolves.com>
 <20160707195247.GO18345@sizone.org>
 <577FA41A.8050303@netwolves.com>
 <25577FE1-6366-4D6D-B82E-A779193CB458@beckman.org>
 <20160711012626.C7A4E4DDD425@rock.dv.isc.org>
Message-ID: <20160711190417.GG2543@vinny.peecee3.com>

On 2016-07-11 11:26, Mark Andrews wrote:
> 
> In message <25577FE1-6366-4D6D-B82E-A779193CB458 at beckman.org>, Mel Beckman writ
> The Internet Standard MTU's are 68 octets for IPv4 (RFC 791) and
> 1280 octets for IPv6 (RFC 2460).
>
> Every size greater than those is subject to negotiation.  Now most
> paths pass packets greater than those values.  Ethernet is very
> common and passes 1500.

Thanks for identifying the source, I wish more people did this. 
My nitpick is that RFC791 doesn't label MTU=68 as "standard"; 
it says (section 3.2, p.25):

    Every internet module must be able to forward a datagram of 68
    octets without further fragmentation.  

More to your point, RFC791 also says (section 3.1, p. 13):

    All hosts must be prepared to accept datagrams of up to 576
    octets (whether they arrive whole or in fragments).  It is
    recommended that hosts only send datagrams larger than 576
    octets if they have assurance that the destination is prepared
    to accept the larger datagrams.
 
> Encapsulated / translate traffic is also very common and has MTUs
> < 1500 and affects BOTH IPv4 and IPv6 data streams and will become
> more so as we move from dual stack to IPv6 only where IPv4 is a
> service running on top of IPv6.

-- 
Charles Polisher


From sean at donelan.com  Tue Jul 12 07:25:06 2016
From: sean at donelan.com (Sean Donelan)
Date: Tue, 12 Jul 2016 03:25:06 -0400 (EDT)
Subject: packet loss question
In-Reply-To: <20160711190417.GG2543@vinny.peecee3.com>
References: <577EAAD4.5010405@netwolves.com>
 <20160707195247.GO18345@sizone.org> <577FA41A.8050303@netwolves.com>
 <25577FE1-6366-4D6D-B82E-A779193CB458@beckman.org>
 <20160711012626.C7A4E4DDD425@rock.dv.isc.org>
 <20160711190417.GG2543@vinny.peecee3.com>
Message-ID: <alpine.BSF.2.20.1607120315270.22143@cnex.qbaryna.pbz>

On Mon, 11 Jul 2016, cpolish at surewest.net wrote:
> Thanks for identifying the source, I wish more people did this.
> My nitpick is that RFC791 doesn't label MTU=68 as "standard";
> it says (section 3.2, p.25):

RFC791 was written during the internet's anti-standard era.

We reject: kings, presidents and voting. We believe in: rough consensus 
and running code



From bevan at slattery.net.au  Tue Jul 12 12:46:41 2016
From: bevan at slattery.net.au (Bevan Slattery)
Date: Tue, 12 Jul 2016 22:46:41 +1000
Subject: IX in Iran by TIC
In-Reply-To: <639FDBD6-C162-48C8-8725-B8786A4BB904@cloudflare.com>
References: <CAGqGmqa6SPLA=P3GPjpQ7RO6ryRTCuzj1NB5NNQUMgke_kt0WQ@mail.gmail.com>
 <CAMDXq5NPUgqxNgy_Jm70naAV8jqHrQqsZuFB+58thEYrabScXg@mail.gmail.com>
 <639FDBD6-C162-48C8-8725-B8786A4BB904@cloudflare.com>
Message-ID: <CAAJrYhQWJw0a2FC30CDMMUQm7wn_fszjQyKY=4pvg7=GOuK0aw@mail.gmail.com>

Great work.  Might be worthwhile to also look at throwing your fabric/IX on
Cloud Scene www.cloudscene.com .  Provides visibility for people looking
for DC's, providers and fabrics that just aren't limited to IX locations or
peers.

Cheers

[b]

On 28 June 2016 at 18:49, Marty Strong via NANOG <nanog at nanog.org> wrote:

> Can?t agree more about putting your IXPs on PeeringDB, it?s my first port
> of call when looking at locations to expand to.
>
> Also, I would say to add the data centres too, to give a better idea of
> where the IXPs are physically located.
>
> Regards,
> Marty Strong
> --------------------------------------
> CloudFlare - AS13335
> Network Engineer
> marty at cloudflare.com
> +44 7584 906 055
> smartflare (Skype)
>
> https://www.peeringdb.com/asn/13335
>
> > On 28 Jun 2016, at 02:16, Martin Hannigan <hannigan at gmail.com> wrote:
> >
> > On Mon, Jun 27, 2016 at 7:05 AM, Shahab Vahabzadeh
> > <sh.vahabzadeh at gmail.com> wrote:
> >> Hello Everybody,
> >> I am here to announce that TIC in Iran launched Neutral Internet
> Exchange
> >> Points.
> >> Right now we have four in:
> >>
> >>   - Tehran (tehran-ix.ir)
> >>   - Shiraz (shiraz-ix.ir)
> >>   - Tabriz (tabriz-ix.ir)
> >>   - Mashhad (mashhad-ix.ir)
> >>
> >> Currently we have near 45Gbps traffic on it but it will increase to
> 100Gbps
> >> within two months. Content Providers activating their BGP peering with
> >> members one by one.
> >>
> >> Also I have something interesting for you around the world, TIC is
> >> launching a International IX in Chabahar called Chabahar IX (
> chabahar-ix.ir)
> >> which can be interesting for T1 ISPs or Content Providers like Akamai,
> >> Amazon, Google, Limelight, Cloudflare and etc.
> >>
> >
> > Thanks, I'll get this to the right people internally (AKAMAI). In the
> > meantime, there are a number of peering groups on Facebook (global
> > peering forum, peering forum, peeringDB) that you may want to join to
> > discuss this as well.
> >
> > Don't forget to register in peeringDB:
> >
> >     https://www.peeringdb.com/search?q=IRAN
> >
> > And finally, great pictures!
> http://www.tehran-ix.ir/fa/news/ixp-workshop
> >
> > Good luck!
> >
> > Best,
> >
> > Martin
>
>

From jwbensley at gmail.com  Tue Jul 12 13:01:54 2016
From: jwbensley at gmail.com (James Bensley)
Date: Tue, 12 Jul 2016 14:01:54 +0100
Subject: IX in Iran by TIC
In-Reply-To: <CAAJrYhQWJw0a2FC30CDMMUQm7wn_fszjQyKY=4pvg7=GOuK0aw@mail.gmail.com>
References: <CAGqGmqa6SPLA=P3GPjpQ7RO6ryRTCuzj1NB5NNQUMgke_kt0WQ@mail.gmail.com>
 <CAMDXq5NPUgqxNgy_Jm70naAV8jqHrQqsZuFB+58thEYrabScXg@mail.gmail.com>
 <639FDBD6-C162-48C8-8725-B8786A4BB904@cloudflare.com>
 <CAAJrYhQWJw0a2FC30CDMMUQm7wn_fszjQyKY=4pvg7=GOuK0aw@mail.gmail.com>
Message-ID: <CAAWx_pW9e9wayGioFEw=aNZUwj7mDzdhsjYQfXxnsj=SDuhuuw@mail.gmail.com>

On 12 July 2016 at 13:46, Bevan Slattery <bevan at slattery.net.au> wrote:
> Great work.  Might be worthwhile to also look at throwing your fabric/IX on
> Cloud Scene www.cloudscene.com .  Provides visibility for people looking
> for DC's, providers and fabrics that just aren't limited to IX locations or
> peers.
>
> Cheers

That's a nifty site but isn't it largely overlapping with peeringdb
which is already more established?

Just my two pence.

James.

From bevan at slattery.net.au  Tue Jul 12 13:33:16 2016
From: bevan at slattery.net.au (Bevan Slattery)
Date: Tue, 12 Jul 2016 23:33:16 +1000
Subject: IX in Iran by TIC
In-Reply-To: <CAAWx_pW9e9wayGioFEw=aNZUwj7mDzdhsjYQfXxnsj=SDuhuuw@mail.gmail.com>
References: <CAGqGmqa6SPLA=P3GPjpQ7RO6ryRTCuzj1NB5NNQUMgke_kt0WQ@mail.gmail.com>
 <CAMDXq5NPUgqxNgy_Jm70naAV8jqHrQqsZuFB+58thEYrabScXg@mail.gmail.com>
 <639FDBD6-C162-48C8-8725-B8786A4BB904@cloudflare.com>
 <CAAJrYhQWJw0a2FC30CDMMUQm7wn_fszjQyKY=4pvg7=GOuK0aw@mail.gmail.com>
 <CAAWx_pW9e9wayGioFEw=aNZUwj7mDzdhsjYQfXxnsj=SDuhuuw@mail.gmail.com>
Message-ID: <CAAJrYhQAYjeSK6B105e9F7m5V1G7tjwhqGKxK0tUK5cbUAZi9w@mail.gmail.com>

Hi James,

I hear you.  Massive fan of peeringdb and this isn't about replacing that.

Peeringdb provides a list of registered peers in a DC that has an IX.
Great for looking at where to peer.

Cloud Scene looks at all providers (4,000+) whether they are peering or not
in any DC (4,800+ DC's)  whether they are IX enabled or not.  It is aimed
to give a full view of service providers in each facility around the
world.  Good list and growing over time.  A more detailed example of the
areas of differentiation is below.  Important to note that if you are a
someone that acquires/sells backhaul, L2 tails, transit, international
capacity, voice etc. then peeringdb is not really the place to get a
detailed list.

Agree in this instance peeringdb is definitely the first stop.  But no harm
in covering all bases for people who are looking for colo in that market
and find the fact one DC has an IX to be of value.

Cheers

[b]

EXAMPLE 1.
There maybe for example an enterprise  that is looking for a service
provider in a facility (XYZ in NY for example) but that provider actually
"peers" their transit routers at the ABC facility down the street.  Because
the provider doesn't peer in XYZ there is no public record of them being
there in peering DB.  Providers are in heaps of DC's/locations that they
just don't peer.  So they effectively have no central location where people
can see that they are "available to service".  This is more of a directory
of where providers are and what services they can provide.

EXAMPLE 2.
There are also now heaps of facilities that have no IX/fabric in them at
all.  Cloud Scene gives people access to understand who is in there which
is great from a network planning perspective to see which facility/ies they
may wish to instal their kit in.  Also it's good for IX's to look at where
they may extend their infra into.  In the next few weeks/months major cloud
providers will be plugged in too to give a more complete view of the cloud
scene in any city.

On 12 July 2016 at 23:01, James Bensley <jwbensley at gmail.com> wrote:

> On 12 July 2016 at 13:46, Bevan Slattery <bevan at slattery.net.au> wrote:
> > Great work.  Might be worthwhile to also look at throwing your fabric/IX
> on
> > Cloud Scene www.cloudscene.com .  Provides visibility for people looking
> > for DC's, providers and fabrics that just aren't limited to IX locations
> or
> > peers.
> >
> > Cheers
>
> That's a nifty site but isn't it largely overlapping with peeringdb
> which is already more established?
>
> Just my two pence.
>
> James.
>

From bevan at slattery.net.au  Tue Jul 12 13:36:12 2016
From: bevan at slattery.net.au (Bevan Slattery)
Date: Tue, 12 Jul 2016 23:36:12 +1000
Subject: IX in Iran by TIC
In-Reply-To: <CAAWx_pW9e9wayGioFEw=aNZUwj7mDzdhsjYQfXxnsj=SDuhuuw@mail.gmail.com>
References: <CAGqGmqa6SPLA=P3GPjpQ7RO6ryRTCuzj1NB5NNQUMgke_kt0WQ@mail.gmail.com>
 <CAMDXq5NPUgqxNgy_Jm70naAV8jqHrQqsZuFB+58thEYrabScXg@mail.gmail.com>
 <639FDBD6-C162-48C8-8725-B8786A4BB904@cloudflare.com>
 <CAAJrYhQWJw0a2FC30CDMMUQm7wn_fszjQyKY=4pvg7=GOuK0aw@mail.gmail.com>
 <CAAWx_pW9e9wayGioFEw=aNZUwj7mDzdhsjYQfXxnsj=SDuhuuw@mail.gmail.com>
Message-ID: <CAAJrYhROBAxeraPKZ9kxEncMnQ53x58iKJvo1ucYw5AU=vAvhw@mail.gmail.com>

Hi James,

I hear you.  Massive fan of peeringdb and this isn't about replacing that
(in fact love to simply integrate).

Peeringdb provides a list of registered peers in a DC that has an IX.
Great for looking at where to peer.

Cloud Scene looks at all providers (4,000+) whether they are peering or not
in any DC (4,800+ DC's)  whether they are IX enabled or not.  It is aimed
to give a full view of service providers in each facility around the
world.  Good list and growing over time.  A more detailed example is
below.  Important to note that if you are a someone that acquires/sells
backhaul, L2 tails, transit, international capacity, voice etc. then
peeringdb is not really the place to go.

Agree in this instance peeringdb is definitely the first stop.  But no harm
in covering all bases for people who are looking for colo in that market
and find the fact one DC has an IX to be of value.

Cheers

[b]

PS:  Declaration that I started Cloud Scene to help me understand better
what networks were where.  Happy to take this offline after this explainer.

EXAMPLE 1.
There maybe for example an enterprise  that is looking for a service
provider in a facility (XYZ in NY for example) but that provider actually
"peers" their transit routers at the ABC facility down the street.  Because
the provider doesn't peer in XYZ there is no public record of them being
there in peering DB.  Providers are in heaps of DC's/locations that they
just don't peer.  So they effectively have no central location where people
can see that they are "available to service".  This is more of a directory
of where providers are and what services they can provide.

EXAMPLE 2.
There are also now heaps of facilities that have no IX/fabric in them at
all.  Cloud Scene gives people access to understand who is in there which
is great from a network planning perspective to see which facility/ies they
may wish to instal their kit in.  Also it's good for IX's to look at where
they may extend their infra into.  In the next few weeks/months major cloud
providers will be plugged in too to give a more complete view of the cloud
scene in any city.

Cheers

[b]

On 12 July 2016 at 23:01, James Bensley <jwbensley at gmail.com> wrote:

> On 12 July 2016 at 13:46, Bevan Slattery <bevan at slattery.net.au> wrote:
> > Great work.  Might be worthwhile to also look at throwing your fabric/IX
> on
> > Cloud Scene www.cloudscene.com .  Provides visibility for people looking
> > for DC's, providers and fabrics that just aren't limited to IX locations
> or
> > peers.
> >
> > Cheers
>
> That's a nifty site but isn't it largely overlapping with peeringdb
> which is already more established?
>
> Just my two pence.
>
> James.
>

From brak at gameservers.com  Tue Jul 12 14:41:41 2016
From: brak at gameservers.com (Brian Rak)
Date: Tue, 12 Jul 2016 10:41:41 -0400
Subject: Comcast postmaster?
In-Reply-To: <8d843c14-932e-af4b-117d-7fd1c8adc9cd@gameservers.com>
References: <8d843c14-932e-af4b-117d-7fd1c8adc9cd@gameservers.com>
Message-ID: <37e8edda-13bc-3f0f-3eba-6c3721255d29@gameservers.com>

Taken care of, thanks!


On 7/11/2016 2:46 PM, Brian Rak wrote:
> Is there anyone here that can put me in touch with a Comcast mail 
> server administrator?  It seems that they've firewalled off some of 
> our IPv6 space, and I can't seem to find any contact information.
>
> Interestingly, I can't even fill out their blocklist removal form, 
> because it only accepts IPv4 addresses.
>


From niels=nanog at bakker.net  Tue Jul 12 15:21:19 2016
From: niels=nanog at bakker.net (Niels Bakker)
Date: Tue, 12 Jul 2016 17:21:19 +0200
Subject: IX in Iran by TIC
In-Reply-To: <CAAJrYhQAYjeSK6B105e9F7m5V1G7tjwhqGKxK0tUK5cbUAZi9w@mail.gmail.com>
References: <CAGqGmqa6SPLA=P3GPjpQ7RO6ryRTCuzj1NB5NNQUMgke_kt0WQ@mail.gmail.com>
 <CAMDXq5NPUgqxNgy_Jm70naAV8jqHrQqsZuFB+58thEYrabScXg@mail.gmail.com>
 <639FDBD6-C162-48C8-8725-B8786A4BB904@cloudflare.com>
 <CAAJrYhQWJw0a2FC30CDMMUQm7wn_fszjQyKY=4pvg7=GOuK0aw@mail.gmail.com>
 <CAAWx_pW9e9wayGioFEw=aNZUwj7mDzdhsjYQfXxnsj=SDuhuuw@mail.gmail.com>
 <CAAJrYhQAYjeSK6B105e9F7m5V1G7tjwhqGKxK0tUK5cbUAZi9w@mail.gmail.com>
Message-ID: <20160712152119.GA3955@excession.tpb.net>

* bevan at slattery.net.au (Bevan Slattery) [Tue 12 Jul 2016, 15:33 CEST]:
>Peeringdb provides a list of registered peers in a DC that has an IX.
>Great for looking at where to peer.

PeeringDB lists many datacenters without any IXP.  The difference 
seems to be that PeeringDB data is provided by the networks themselves 
rather than third parties.

Having recently asked a datacenter about what providers were present 
in their facilities and receiving an answer similar to "Who would you 
like to be there?", I much prefer PeeringDB's model of ensuring data 
completeness and correctness.


	-- Niels.

From mark.tinka at seacom.mu  Tue Jul 12 16:15:35 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Tue, 12 Jul 2016 18:15:35 +0200
Subject: IX in Iran by TIC
In-Reply-To: <20160712152119.GA3955@excession.tpb.net>
References: <CAGqGmqa6SPLA=P3GPjpQ7RO6ryRTCuzj1NB5NNQUMgke_kt0WQ@mail.gmail.com>
 <CAMDXq5NPUgqxNgy_Jm70naAV8jqHrQqsZuFB+58thEYrabScXg@mail.gmail.com>
 <639FDBD6-C162-48C8-8725-B8786A4BB904@cloudflare.com>
 <CAAJrYhQWJw0a2FC30CDMMUQm7wn_fszjQyKY=4pvg7=GOuK0aw@mail.gmail.com>
 <CAAWx_pW9e9wayGioFEw=aNZUwj7mDzdhsjYQfXxnsj=SDuhuuw@mail.gmail.com>
 <CAAJrYhQAYjeSK6B105e9F7m5V1G7tjwhqGKxK0tUK5cbUAZi9w@mail.gmail.com>
 <20160712152119.GA3955@excession.tpb.net>
Message-ID: <bd8a7715-fdfc-51cc-5c3e-180632dde733@seacom.mu>



On 12/Jul/16 17:21, Niels Bakker wrote:

>  
>
> Having recently asked a datacenter about what providers were present
> in their facilities and receiving an answer similar to "Who would you
> like to be there?", I much prefer PeeringDB's model of ensuring data
> completeness and correctness.

Awww, you didn't want to take Santa up on his offer? Bad, bad Niels :-)...

When I was a kid, I often thought recordings on VHS cassettes happened
by simply taking a pen and writing the title of the movie on the
cassette label, sitting the tape on the side of the VCR and waiting
patiently till dinner was over. All those phantom Knight Rider, Air Wolf
and Miami Vice shows I could have enjoyed growing up... oh well...

Mark.

From surfer at mauigateway.com  Tue Jul 12 20:23:42 2016
From: surfer at mauigateway.com (Scott Weeks)
Date: Tue, 12 Jul 2016 13:23:42 -0700
Subject: IX in Iran by TIC
Message-ID: <20160712132342.7611C0EB@m0087791.ppops.net>



------------------------------------------
> Might be worthwhile to also look at throwing your 
fabric/IX on XXXXX www.xxxxxx.com .  
------------------------------------------

https://www.nanog.org/list

"5.Product marketing is prohibited"

It appears from a web search that you are affiliated 
with the company you're speaking about.

scott

From cpolish at surewest.net  Tue Jul 12 20:37:22 2016
From: cpolish at surewest.net (cpolish at surewest.net)
Date: Tue, 12 Jul 2016 13:37:22 -0700
Subject: packet loss question
In-Reply-To: <alpine.BSF.2.20.1607120315270.22143@cnex.qbaryna.pbz>
References: <577EAAD4.5010405@netwolves.com>
 <20160707195247.GO18345@sizone.org>
 <577FA41A.8050303@netwolves.com>
 <25577FE1-6366-4D6D-B82E-A779193CB458@beckman.org>
 <20160711012626.C7A4E4DDD425@rock.dv.isc.org>
 <20160711190417.GG2543@vinny.peecee3.com>
 <alpine.BSF.2.20.1607120315270.22143@cnex.qbaryna.pbz>
Message-ID: <20160712203722.GH2543@vinny.peecee3.com>

On 2016-07-12 03:25, Sean Donelan wrote:
> RFC791 was written during the internet's anti-standard era.
> 
> We reject: kings, presidents and voting. We believe in: rough consensus and
> running code

Hi Sean,

Lovely quote and all, but... do you mean that when RFC791 was
drafted the IETF didn't issue 'standards'? RFC791 was written by
Jon Postel for DARPA and AFAIKT is foundational. It's referenced
by more than 420 RFCs. It begins, "This document specifies the
DoD Standard Internet Protocol." Seems about as official as
times permitted. 

Point was, 576 bytes is the minimum MTU for transporting IP
datagrams. Also see RFC1122/3.3.2, which references
RFC791 of course.

Best regards,
-- 
Charles Polisher
"Pedentic, I?"


From bross at pobox.com  Tue Jul 12 21:09:32 2016
From: bross at pobox.com (Brandon Ross)
Date: Tue, 12 Jul 2016 17:09:32 -0400 (EDT)
Subject: IX in Iran by TIC
In-Reply-To: <20160712132342.7611C0EB@m0087791.ppops.net>
References: <20160712132342.7611C0EB@m0087791.ppops.net>
Message-ID: <alpine.OSX.2.02.1607121708360.67118@brugal.local>

On Tue, 12 Jul 2016, Scott Weeks wrote:

> ------------------------------------------
>> Might be worthwhile to also look at throwing your
> fabric/IX on XXXXX www.xxxxxx.com .
> ------------------------------------------
>
> https://www.nanog.org/list
>
> "5.Product marketing is prohibited"
>
> It appears from a web search that you are affiliated
> with the company you're speaking about.

Mentioning a product that you happen to work on/for while in context 
hardly seems like it should rise to the level of prohibited marketing. 
Then again, perhaps we should hire consultants to figure that out for us.

-- 
Brandon Ross                                      Yahoo & AIM:  BrandonNRoss
+1-404-635-6667                                                ICQ:  2269442
                                                          Skype:  brandonross
Schedule a meeting:  http://www.doodle.com/bross

From bevan at slattery.net.au  Tue Jul 12 21:37:45 2016
From: bevan at slattery.net.au (Bevan Slattery)
Date: Wed, 13 Jul 2016 07:37:45 +1000
Subject: IX in Iran by TIC
In-Reply-To: <20160712132342.7611C0EB@m0087791.ppops.net>
References: <20160712132342.7611C0EB@m0087791.ppops.net>
Message-ID: <0180C155-1E2A-4721-8897-90164821348C@slattery.net.au>

Yes Scott. It was on topic and genuine in the approach, but understand the nuances around it.  I did declare the interest in the second email when a more detailed explainer was included with a request to take it offline.  That felt like I was stepping over the mark for the sake of pointing out the technical differences between peeringdb and XXXXXXXXXX hence the declaration and wanting to take it off line to not fill people's in-boxes.

That leads back to the first point to of doing it in the first place to avoid this.  Apologies.

Cheers

[b]

> On 13 Jul 2016, at 6:23 AM, Scott Weeks <surfer at mauigateway.com> wrote:
> 
> 
> 
> ------------------------------------------
>> Might be worthwhile to also look at throwing your
> fabric/IX on XXXXX www.xxxxxx.com .  
> ------------------------------------------
> 
> https://www.nanog.org/list
> 
> "5.Product marketing is prohibited"
> 
> It appears from a web search that you are affiliated 
> with the company you're speaking about.
> 
> scott

From jwbensley at gmail.com  Wed Jul 13 08:17:09 2016
From: jwbensley at gmail.com (James Bensley)
Date: Wed, 13 Jul 2016 09:17:09 +0100
Subject: IX in Iran by TIC
In-Reply-To: <CAAJrYhROBAxeraPKZ9kxEncMnQ53x58iKJvo1ucYw5AU=vAvhw@mail.gmail.com>
References: <CAGqGmqa6SPLA=P3GPjpQ7RO6ryRTCuzj1NB5NNQUMgke_kt0WQ@mail.gmail.com>
 <CAMDXq5NPUgqxNgy_Jm70naAV8jqHrQqsZuFB+58thEYrabScXg@mail.gmail.com>
 <639FDBD6-C162-48C8-8725-B8786A4BB904@cloudflare.com>
 <CAAJrYhQWJw0a2FC30CDMMUQm7wn_fszjQyKY=4pvg7=GOuK0aw@mail.gmail.com>
 <CAAWx_pW9e9wayGioFEw=aNZUwj7mDzdhsjYQfXxnsj=SDuhuuw@mail.gmail.com>
 <CAAJrYhROBAxeraPKZ9kxEncMnQ53x58iKJvo1ucYw5AU=vAvhw@mail.gmail.com>
Message-ID: <CAAWx_pVPSQUajHb1y+3TQu2qonLNt93gsjn2Qy7gRTr2wFVfLg@mail.gmail.com>

On 12 July 2016 at 14:36, Bevan Slattery <bevan at slattery.net.au> wrote:
> EXAMPLE 1.
> There maybe for example an enterprise  that is looking for a service
> provider in a facility (XYZ in NY for example) but that provider actually
> "peers" their transit routers at the ABC facility down the street.  Because
> the provider doesn't peer in XYZ there is no public record of them being
> there in peering DB.  Providers are in heaps of DC's/locations that they
> just don't peer.  So they effectively have no central location where people
> can see that they are "available to service".  This is more of a directory
> of where providers are and what services they can provide.

Hmm, so maybe I'm just a maverick, we are not using any public peering
fabrics at minute due to what can only be described as a senior
management cluster fuck, so on peeringdb we list some pops that we are
in that we are willing (and do) have private peering sessions in. It
doesn't say on peeringdb that there are IX's in some of these PoPs but
hopefully when we need to establish a private interconnect with
someone they will see we are in the same PoP as them even though there
is no IX in that PoP and put 2 and 2 together, and contact us to
discuss a cross connect.

For the avoidance of doubt, I'm not trying to poo poo the site, just
trying to work out where the different is feature set lies exactly.


Cheers,
James.

From jwbensley at gmail.com  Wed Jul 13 08:24:02 2016
From: jwbensley at gmail.com (James Bensley)
Date: Wed, 13 Jul 2016 09:24:02 +0100
Subject: IX in Iran by TIC
In-Reply-To: <CAAJrYhQAYjeSK6B105e9F7m5V1G7tjwhqGKxK0tUK5cbUAZi9w@mail.gmail.com>
References: <CAGqGmqa6SPLA=P3GPjpQ7RO6ryRTCuzj1NB5NNQUMgke_kt0WQ@mail.gmail.com>
 <CAMDXq5NPUgqxNgy_Jm70naAV8jqHrQqsZuFB+58thEYrabScXg@mail.gmail.com>
 <639FDBD6-C162-48C8-8725-B8786A4BB904@cloudflare.com>
 <CAAJrYhQWJw0a2FC30CDMMUQm7wn_fszjQyKY=4pvg7=GOuK0aw@mail.gmail.com>
 <CAAWx_pW9e9wayGioFEw=aNZUwj7mDzdhsjYQfXxnsj=SDuhuuw@mail.gmail.com>
 <CAAJrYhQAYjeSK6B105e9F7m5V1G7tjwhqGKxK0tUK5cbUAZi9w@mail.gmail.com>
Message-ID: <CAAWx_pW=kZZh+x0Txrnu2uJbXmM9r=8RVJNwXTdGecKtmbx1Dg@mail.gmail.com>

On 12 July 2016 at 14:36, Bevan Slattery <bevan at slattery.net.au> wrote:
> EXAMPLE 1.
> There maybe for example an enterprise  that is looking for a service
> provider in a facility (XYZ in NY for example) but that provider actually
> "peers" their transit routers at the ABC facility down the street.  Because
> the provider doesn't peer in XYZ there is no public record of them being
> there in peering DB.  Providers are in heaps of DC's/locations that they
> just don't peer.  So they effectively have no central location where people
> can see that they are "available to service".  This is more of a directory
> of where providers are and what services they can provide.

Hmm, so maybe I'm just a maverick, we are not using any public peering
fabrics at minute due to what can only be described as a senior
management cluster foook [1], so on peeringdb we list some pops that we are
in that we are willing (and do) have private peering sessions in. It
doesn't say on peeringdb that there are IX's in some of these PoPs but
hopefully when we need to establish a private interconnect with
someone they will see we are in the same PoP as them even though there
is no IX in that PoP and put 2 and 2 together, and contact us to
discuss a cross connect.

For the avoidance of doubt, I'm not trying to poo poo the site, just
trying to work out where the different is feature set lies exactly.


Cheers,
James.


[1] Is this a list for adults or children, my original email bounced
back because I used the work f*ck?

From prnpetrov at yandex.com  Tue Jul 12 12:30:11 2016
From: prnpetrov at yandex.com (Nikolai Petrov)
Date: Tue, 12 Jul 2016 15:30:11 +0300
Subject: New Office, New Network. Questions.
Message-ID: <219581468326611@web8h.yandex.ru>

Here are my replies on this e-mail. Sorry for the late replies!

> On Sun, 10 Jul 2016 21:53:52 +0300, Nikolai Petrov said:
> 
>> 1. Currently we do not have IPv6 in our network but I have seen the ISP is
>> giving us a "/56 Block" which from what I understand is a couple hundred "/64
>> Subnets". I think you can only have /64 subnets in IPv6. In our IPv4 setup we
> 
> You can have other sized subnets, but 64 is very handy if you intend to use
> SLAAC auto-configure. There's also the danger of running into broken equipment
> that doesn't understand other sized subnets (similar to very old IPv4 gear that
> understood a /24, but exploded if told about a /23 or /25).

I really like SLAAC and its design and I would very much like to use it. Therefore we will be using /64 IP Ranges.
Is there any way to limit the amount of devices in a subnet to avoid problems and attacks? I don't think the equipment will work with 2^64 devices in a single subnet.. 

> 
>> have 32 addresses, four of which I will use for NAT and the remaining needed
>> for online services and servers. In IPv6 we have a lot of addresses but I am
>> not sure whether I should give an address of the ISP to every device. I found
> 
> Assign a /64 to everyplace that you would assign a subnet in IPv4. Give each
> device on that subnet its own address. Use DHCPv6 or SLAAC or both, whatever
> gets the job done in your situation. Don't worry about NAT anymore, you have
> enough addresses.
> 
>> that there is an organization that can help avoid collisions in private IPs:
>> https://www.sixxs.net/tools/grh/ula/ . From what I can tell it is just a
>> registry, but I am thinking of registering the ranges there and then use these
>> subnets and NAT them to the IPv6 address of the router.
> 
> Don't do that. NAT was invented to fix a problem that IPv6 doesn't have. Feel
> free to give every single device a global address. (You'll still want a
> stateful firewall someplace, but it doesn't have to do NAT, it just has to keep
> track of legitimate versus malicious traffic).

So why are these addresses there? For installations not connected to the Internet?

> 
> And don't freak out if a device has more than one address. As I'm writing this
> from the sofa in my living room, my laptop wireless has:
> 
> ra0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
> inet 192.168.1.150 netmask 255.255.255.224 broadcast 192.168.1.159
> inet6 2601:5c0:c100:6431:cad7:19ff:fe37:c02 prefixlen 64 scopeid 0x0<global>
> inet6 2601:5c0:c100:6431:c01:a589:19a4:236e prefixlen 64 scopeid 0x0<global>
> inet6 2601:5c0:c100:6431::d67 prefixlen 128 scopeid 0x0<global>
> inet6 2601:5c0:c100:6431:1dc3:657:eda6:8abf prefixlen 64 scopeid 0x0<global>
> inet6 fe80::cad7:19ff:fe37:c02 prefixlen 64 scopeid 0x20<link>
> inet6 2601:5c0:c100:6431:ad68:c60c:583:19e9 prefixlen 64 scopeid 0x0<global>
> ether c8:d7:19:37:0c:02 txqueuelen 1000 (Ethernet)
> 
> (One DHCPv6 - ::d67. One SLAAC - the one with ff:fe in it. And 4 different
> RFC3041 privacy addresses that it's chunked out over the weekend. It works
> just fine that way - and it's *designed* to do so. (Of course, in a corporate
> environment, you may want to turn the privacy addresses off, and only use
> one of DHCPv6/SLAAC - I do it this way because it tests for broken software...)

Thanks for letting me know ahead of time. I have looked up about the privacy addresses and we don't need them as you say. Is there a reason you use DHCPv6 and SLAAC? Is it for compatibility? Can I use the DHCPv4 to give out DNSv6 addresses?

> 
> Oh, and don't block ICMPv6. :)

I was never a fan of blocking ICMP except the redirects in some cases..

> 
>> something strange. The WAN port of our router gets a /64 IPv6 address which is
>> not in our IPv6. Should I use this for NAT or one of "our" addresses?
> 
> You use it for the IP address of the provider-facing interface of your router.
> Assign the "inside" interface(s) addresses on the appropriate /64 subnet that
> they will be on.

Oh, so this is like BGP.. In my previous company we had BGP connections and we used an IPv4 /30 for these connections which was not within our IP range. I thought they would give us a /126 and not a full /64 so I did not think that was it..

Thanks!

From prnpetrov at yandex.com  Tue Jul 12 12:40:57 2016
From: prnpetrov at yandex.com (Nikolai Petrov)
Date: Tue, 12 Jul 2016 15:40:57 +0300
Subject: New Office, New Network. Questions.
Message-ID: <276891468327257@web9m.yandex.ru>

Hello! I have replied to you inline! 

> On Sun, Jul 10, 2016 at 2:53 PM, Nikolai Petrov <prnpetrov at yandex.com> wrote:
> 
>> I thought of taking the chance to remove some
>> "technical debt" and make everything from
>> scratch again.
> 
> Hi Nikolai,
> 
> This is a rookie mistake. Every in-place system encodes business
> knowledge, most of it forgotten and much of it still relevant. From
> your comments I infer that you haven't been doing the job long enough
> to know where the skeletons are buried.

Indeed, I do not have the experience of the previous person who set it up, but I have seen many things that appear not to be good and cause "friction" to the employees.

> 
>> 1. Currently we do not have IPv6 in our network but I
>> have seen the ISP is giving us a "/56 Block" which
>> from what I understand is a couple hundred "/64 Subnets".
> 
> Good for you! We've been urging folks to deploy IPv6 for years and
> you're taking the advice to heart.
> 
> Now stop. IPv6 has enough inherent issues and problems that you'll
> want to deploy it when your configuration is otherwise quiescent. If
> you do it while also making other large changes, you're begging to get
> hurt.

I know, but I think the time I have is more than enough for IPv4 and "if I don't do it now, I may never do it"..

> 
>> 2. The previous administrator did some bad
>> job in some parts of the network. We have
>> an internal router protocol to move traffic between
>> routers, but in some cases he used NAT instead
>> of adding these subnets to the router protocol.
> 
> I urge you to tread lightly. You don't know what business knowledge
> was encoded in this configuration. Maybe the servers respond
> differently depending on whether the source is internal or external
> and some of the origins should be treated to the external rules.

No, this is the same behavior and currently employees have access to routers so they can port forward so other departments can reach their computers. We also use "UPnP" in these routers because some applications need direct host to host communication. Both subnets are trusted in the current design. I wouldn't claim this if I wasn't sure. Currently I have not found a single legitimate use and I have asked users, server administrators, etc.

> 
>> I have found two protocols in our router that are
>> good and support IPv6 and they are OSPF
>> and BGP.
> 
> OSPF is an interior gateway protocol. Use between routers within your
> network. BGP is an exterior gateway protocol. Use it when you want to
> talk to multiple ISPs at the same time.

I was talking about BGP with private "ASNs" to be used internally and if we ever make a BGP connection to the Internet in the future, use a different router table and a route aggregate.

> 
>> 3. In our old network we use "VRRP" which from
>> what I know is a system for routers to shae IPs
>> and load balance or "failover" the traffic. I have
>> seen that IPv6 has a built-in system which is similar
>> and has something like priorities, etc. What
>> happens if I have two routers with same priority?
> 
> If the guy who wrote the stack wasn't asleep at the switch, the host
> will pick one and use it as long as the router keeps advertising it.
> But it's not a good idea to tempt fate - set each router at a
> different priority.

I know, but one team is responsible for marketing and is doing video editing from a file server, so we have a lot of workstations moving at Gigabit speeds. I thought of two solutions:

Buy a switch with a 10 Gb/s port to connect to the file server subnet, which seems overkill because the cheapest I can find has 48 ports and we'll need 7. The second solution was to add a 16-port Gigabit switch and then have 2-3 routers move traffic to the file servers and give each client a different gw. This ensures redundancy and possibly more bandwidth.

> 
> IPv6 router advertisements are nothing like IPv4 VRRP. In IPv4, hosts
> receive a single default gateway. VRRP lets two or more routers decide
> among themselves who will serve up the IP address for that default
> gateway. And then swap it when the router serving the address breaks.
> 
> IPv6 hosts can have more than one default gateway. Each router with a
> path to the Internet can offer act as a default gateway and hosts will
> accept and use it. Preventing machines which should not act as default
> gateways from making offers that the hosts hear and use is one of the
> many idiosyncrasies you'll enjoy debugging when you first deploy IPv6.
> 
>> Also, can I use "VRRP" to load balance traffic to
>> our DNS look-up "recursor"?
> 
> No. VRRP is a failover system. It has nothing to do with load balancing.
> 
> Regards,
> Bill Herrin
> 
> --
> William Herrin ................ herrin at dirtside.com bill at herrin.us
> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From prnpetrov at yandex.com  Tue Jul 12 12:56:16 2016
From: prnpetrov at yandex.com (Nikolai Petrov)
Date: Tue, 12 Jul 2016 15:56:16 +0300
Subject: New Office, New Network. Questions.
Message-ID: <389231468328176@web22h.yandex.ru>

Please find my replies inline. Thanks for your time!

> hi nikolai
> 
> - oops.. this got long based on my experiences/opinions :-)
> 
> On 07/10/16 at 09:53pm, Nikolai Petrov wrote:
> 
>> We are moving to our new offices in two months and I have access to the building already.
>> My task is to set up the entire network for the company.
>> The previous administrator has left the company and I thought of taking the chance to remove some "technical debt" and make everything from scratch again.
> 
> all good ...
> 
>> I was told to move the networks this week
> 
> do you have the routers, switches, cables, few servers for testing ?
> has your ISP installed their internet uplink connectivity to the bldg ?
> 
> if so, than the above management is on their toes
> otherwise, you'd need to rattle some $$$ loose to buying missing hw :-)

Since we have received funding for this scale up of the company the management decided I should buy all the hardware new. I have a large budget and I could even make the network 10 Gb/s with that money. I guess I am a lucky person. Large budget to do a network without using old stuff! The uplink is installed already from our ISP and the entire building is available to me to install the network.

> 
>> and I have spent a lot of time thinking about how I should do it.
> 
> good ... now's the chance to fix the problems if any ..

This is what I thought!

> 
>> 1. Currently we do not have IPv6 in our network
> 
> implies a learning IPv6 curve ( red flag for possible time-wasting hogs )
> 
> if the task is to mvoe the entire "mid-sized" from current bldg to new bdlg,
> i'd suggest use "known/good/working/best-practices" methodology to move
> the company. first get the new bldg with new test servers working
> with IPv4 ( the way you want it done ) and "working" the current bldg
> which should take a few hours :-)
> 
> than work with IPv6 issues

This is my plan. I have designed the IPv4 network already but I also want to install the IPv6 network right after it and not "some time in the future".

> 
>> but I have seen the ISP is giving us a "/56 Block"
> 
> good
> 
>> which from what I understand is a couple hundred "/64 Subnets".
>> I think you can only have /64 subnets in IPv6.
> 
> nah ... you can subnet your /56 into whatever you want
> 
>> In our IPv4 setup we have 32 addresses,
>> four of which I will use for NAT
>> and the remaining needed for online services and servers.
> 
> good ... use that to test everything
> 
> since you want or going to use NAT, you have the standard
> internal LAN for the bldg can use the standard 10/8 or
> 192.168/16 or 172.16/12
> 
> so far.. nothing new/special/problematic

Exactly. I intend to keep the same IP range as before since I do not have problems with it.. I may change 1-2 subnet sizes but that's it.. I want to avoid issues with DNS servers, static IP configurations since these are not 100% under my control and I do not know if the server team knows all places where an IP is located..

> 
>> In IPv6 we have a lot of addresses but I am not sure whether
>> I should give an address of the ISP to every device.
> 
> why would you want to complicate time-restricted ( 1month )
> to get the new bldg working with IPv6 w/out having prior
> IPv6 experience ?
> 
> remember, "all eyes" will be looking to you to move the
> whole company from current bldg to new bldg without delay

I think I can do the IPv4 part sooner than needed so I should use the remaining time for IPv6 + testing..

> 
>> I found that there is an organization that can help avoid collisions
>> in private IPs: https://www.sixxs.net/tools/grh/ula/ .
> 
> there should never be any collision in IP#, ipv4 or ipv6

Of course. I meant global collisions in case of a network merge or something.. 

> 
>> From what I can tell it is just a registry, but I am thinking of
>> registering the ranges there and then use these subnets and
>> NAT them to the IPv6 address of the router.
> 
> the ISP provides you the range of IPv6 assigned to you
> 
> if your current bldg does NOT have IPv6, you might not be
> able to easily test the new IPv6 stuff in the new bldg

The new building has full connectivity and when I add our router it gets the IPv4 and IPv6 addresses. The optical fiber of the ISP comes to the building directly.

> 
> you might be able to test your new IPv6 connections
> at the local coffee shop or other public places but
> that's a major security violation since your new IPv6
> has no security pre-cautions installed yet
> 

I am not sure I understand this part. How can I test our IPv6 company set up in a coffee shop?

> you should be paranoid about trojans/worms/mailware piggie
> backing into your new un-secured new bldg IPv6 infrastructure
> or IPv4 infrastructure
> 
>> However, I noticed something strange. The WAN port of our
>> router gets a /64 IPv6 address which is not in our IPv6.
> 
> why strange ??
> 
> routers get its IP# from dhcpv6 or statically assigned

Because it is a /64 range and not a /126. In my previous company we used an IPv4 /30 for our BGP. Isn't a /64 a waste?

> 
>> Should I use this for NAT or one of "our" addresses?
> 
> you need to fix this problem before continuing ..
> ( explain why the IPv6/64 is not what you're expecting )
> 
> NAT is NOT the solution ...
> 
>> 2. The previous administrator did some bad job in some parts of the network.
> 
> :-) that will always be true 90% of the time :-)
> 
> some things are always gonna be "bad"
> 
>> We have an internal router protocol to move traffic between routers,
>> but in some cases he used NAT instead of adding these subnets to the
>> router protocol. Everything works and all things that have to be
>> reached are reachable,
> 
> if it works .. why is is "bad" ??
> 
> there might be dozens of different ways to make things work
> ( "things that have to be reachable are reachable" )
> 
>> however I think this is bad
> 
> not necessarily a bad thing
> 
>> and we should use the router protocol for all parts of the network.
> 
> why ?

Well, currently we have issues with this: NAT makes all computers communicate with all computers but we need to give users access to the routers ( ! ) so they can port forward so employees from other departments can reach their computers and we also do UPnP. Currently there are employees with access to three routers so they can port forward the port forward of the port forward to reach other workstations.. If we used the router protocols it would be direct host to host communication.

> 
>> I have found two protocols in our router that are good and support
>> IPv6 and they are OSPF and BGP.
> 
> there might be more :-)

I have found some more like RIP but it is not good enough I think. I also found ISIS but I don't think it provides much benefit over OSPF and it is not supported by all routers..

> 
>> I did not manage to have BGP work
> 
> what part is not working ?

I can successfully peer with the other router using IPv6 but unfortunately no IPv6 routes are exchanged between the routers or propagated to others if I set the IP ranges manually.

> 
> google/yahoo the error messages :-)
> 
>> and it is slow so I am thinking of OSPF.
> 
> sometimes, which works first/better/easiest might be
> a good option, thus trying other things is good, but
> that can also create more headaches too .. more problems
> to (fun) solve
> 
>> Do uou think it is a good choice for IPv6 and IPv4?
> 
> i'd work with IPv4 first ...
> and more importantly... there is NO excuse why IPv4 doesn't
> or cannot work in the new bldg
> 
> after IPv4 works in the new bldg as good as it does in the current
> bldg, you have time for "( IPv6 ) learning experiements"
> 
>> If I have two separate paths of 1 Gb/s, will I transfer files at 2 Gb/s?
> 
> no ... you will be able to transfer 1Gb/s each ..

Let me clarify this is not transfer to the Internet but between two hosts in the internal network.. 

> 
> if you "channel bond" the two 1Gb/s into "one link",
> than you might be able to see 1.9Gb/s uplinks .. never 2G/s
> 
> if you have 2 1G/s uplinks ... you should have the 2 routers
> crosslinked for failover unless uplink speed is more
> important than failover
> 
>> 3. In our old network we use "VRRP" which from what I know
>> is a system for routers to shae IPs and load balance or "failover" the traffic.
> 
> good
> 
>> I have seen that IPv6 has a built-in system which is similar
>> and has something like priorities, etc. What happens if I have
>> two routers with same priority?
> 
> same rules/issues apply to IPv4
> 
> one router/path should always have priority over the other
> depending on destinations .... lots of testing to see which
> packets goes thru which uplinks
> 
>> Whic is used as default gateway?
> 
> depends..
> 
> engineering/manufacturing uses router1
> hr/accting uses router2
> 
> or
> 
> public DMZ uses router1
> corp LAN uses router2
> 
> but in either case, router1 and rotuer2 should be crosslinked
> if failover is important
> 
>> Is it load balancing? Also, can I use "VRRP" to load balance traffic
>> to our DNS look-up "recursor"?
> 
> dozen ways to do load balancing ... more problems to resolvea
> and prioritize based on your company visibility online
> 
> load balancing should be worried about:
> - dns, www traffic, email traffic, DVD/video/music downloading,
> 
> also always have 3 hot-swap complete infrastrucure and backups
> fw1 + dns1 + www1 + mail1 + NAT1
> fw2 + dns2 + www2 + mail2 + NAT2
> fw3 + dns3 + www3 + mail3 + NAT3
> 
> fw only runs iptables for inline fw for entire dmz/localLan
> dns only runs bind and iptables and nothing else
> www only runs apache and iptables and nothing else
> mail only runs sendmail and iptables and nothing else
> nat only runs NAT + iptables
> 
> each backup its bind/sendmail/apache data to the other 2 boxes, but
> bind/sendmail/apache itself is turned off on the other hot backups
> 
> magic pixie dust
> alvin
> #
> # DDoS-Mitigator.net
> #

From joe at theneutral.net  Wed Jul 13 16:42:04 2016
From: joe at theneutral.net (Joe Carroll)
Date: Wed, 13 Jul 2016 12:42:04 -0400
Subject: Softlayer
Message-ID: <CACkdJ4T1T3J_hZss8y+wqdR63GYFYOVGUeonA6WYVDtefDeuQg@mail.gmail.com>

Is there an admin from the softlayer network ?    We're experiencing
routing issues getting traffic to the softlayer network.

From chuckchurch at gmail.com  Wed Jul 13 18:47:26 2016
From: chuckchurch at gmail.com (Chuck Church)
Date: Wed, 13 Jul 2016 14:47:26 -0400
Subject: IX in Iran by TIC
In-Reply-To: <CAAWx_pW=kZZh+x0Txrnu2uJbXmM9r=8RVJNwXTdGecKtmbx1Dg@mail.gmail.com>
References: <CAGqGmqa6SPLA=P3GPjpQ7RO6ryRTCuzj1NB5NNQUMgke_kt0WQ@mail.gmail.com>
 <CAMDXq5NPUgqxNgy_Jm70naAV8jqHrQqsZuFB+58thEYrabScXg@mail.gmail.com>
 <639FDBD6-C162-48C8-8725-B8786A4BB904@cloudflare.com>
 <CAAJrYhQWJw0a2FC30CDMMUQm7wn_fszjQyKY=4pvg7=GOuK0aw@mail.gmail.com>
 <CAAWx_pW9e9wayGioFEw=aNZUwj7mDzdhsjYQfXxnsj=SDuhuuw@mail.gmail.com>
 <CAAJrYhQAYjeSK6B105e9F7m5V1G7tjwhqGKxK0tUK5cbUAZi9w@mail.gmail.com>
 <CAAWx_pW=kZZh+x0Txrnu2uJbXmM9r=8RVJNwXTdGecKtmbx1Dg@mail.gmail.com>
Message-ID: <00b701d1dd37$00e87870$02b96950$@gmail.com>

Foul language is frowned upon.

https://www.nanog.org/list

Chuck

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of James Bensley
Sent: Wednesday, July 13, 2016 4:24 AM
To: nanog <nanog at nanog.org>
Subject: Re: IX in Iran by TIC

On 12 July 2016 at 14:36, Bevan Slattery <bevan at slattery.net.au> wrote:
> EXAMPLE 1.
> There maybe for example an enterprise  that is looking for a service 
> provider in a facility (XYZ in NY for example) but that provider 
> actually "peers" their transit routers at the ABC facility down the 
> street.  Because the provider doesn't peer in XYZ there is no public 
> record of them being there in peering DB.  Providers are in heaps of 
> DC's/locations that they just don't peer.  So they effectively have no 
> central location where people can see that they are "available to 
> service".  This is more of a directory of where providers are and what services they can provide.

Hmm, so maybe I'm just a maverick, we are not using any public peering fabrics at minute due to what can only be described as a senior management cluster foook [1], so on peeringdb we list some pops that we are in that we are willing (and do) have private peering sessions in. It doesn't say on peeringdb that there are IX's in some of these PoPs but hopefully when we need to establish a private interconnect with someone they will see we are in the same PoP as them even though there is no IX in that PoP and put 2 and 2 together, and contact us to discuss a cross connect.

For the avoidance of doubt, I'm not trying to poo poo the site, just trying to work out where the different is feature set lies exactly.


Cheers,
James.


[1] Is this a list for adults or children, my original email bounced back because I used the work f*ck?


From Valdis.Kletnieks at vt.edu  Wed Jul 13 18:53:55 2016
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 13 Jul 2016 14:53:55 -0400
Subject: New Office, New Network. Questions.
In-Reply-To: <219581468326611@web8h.yandex.ru>
References: <219581468326611@web8h.yandex.ru>
Message-ID: <17532.1468436035@turing-police.cc.vt.edu>

On Tue, 12 Jul 2016 15:30:11 +0300, Nikolai Petrov said:

> Is there any way to limit the amount of devices in a subnet to avoid problems
> and attacks? I don't think the equipment will work with 2^64 devices in a
> single subnet..

Sure. Just don't connect that many devices to one subnet, just the same as you
do in IPv4. No need to drop them all into one subnet. You got a /56, so you can
make 256 /64s out of it.  Carve it up whatever way your cabling says to do it.
Maybe one subnet for your external router to all your in-building switches,
then each switch has a subnet for one floor/office suite/whatever and 1
interface on your organization-wide fabric.  Maybe something else - but in
general you'll be using a subnet everyplace you'd use one in IPv4.

> So why are these addresses there? For installations not connected to the Internet?

Exactly.  It's an attempt to avoid the current mess during corporate acquisitions
where they find out that both companies used 10.16.12.0/24 for different things.

> Is there a reason you use DHCPv6 and SLAAC? Is it for compatibility?

My laptop works just fine at both home and work just using SLAAC - I hit both
mostly to make sure that if I'm travelling and hit someplace where the routers
don't do SLAAC, I'll still configure.

And as I noted, I do it at least partially to stress-test for stuff like
network logging tools, to make sure they don't fall over if they see an address
that isn't either SLAAC or DHCPv6, and so on...

> Can I use the DHCPv4 to give out DNSv6 addresses?

No. You'll need to use either SLAAC or DHCPv6 for that.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160713/b508462e/attachment.pgp>

From baldur.norddahl at gmail.com  Wed Jul 13 22:53:01 2016
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Thu, 14 Jul 2016 00:53:01 +0200
Subject: New Office, New Network. Questions.
In-Reply-To: <219581468326611@web8h.yandex.ru>
References: <219581468326611@web8h.yandex.ru>
Message-ID: <CAPkb-7DgDgipaGDqiObA6dENm+BhDqFSZVVzAL9Fz7_rxc72cw@mail.gmail.com>

"Is there a reason you use DHCPv6 and SLAAC? Is it for compatibility? Can I
use the DHCPv4 to give out DNSv6 addresses?"

Unless you plan om having IPv6 only hosts, there is no advantage in
providing IPv6 DNS servers. Just stay with IPv4 for your DNS resolver in
the DHCPv4 config. Notice that your IPv4 DNs resolver is perfectly capable
of providing AAAA IPv6 replies.

Using DHCPv6 in a corporate environment makes it easier to track which
machine has an IP address as you can lookup the info in the DHCP lease
database. Also some prefers the nice short addresses that you get from DHCP
compared to SLAAC.

My network has both enabled, so my tablet has the following two addresses:

SLAAC: 2a00:7660:5c6:0:74cd:d48c:8230:a44f
DHCP: 2a00:7660:5c6::701

The later is easier to type if you have to add rules to your firewall etc.

Regards

Baldur

From owen at delong.com  Thu Jul 14 02:42:22 2016
From: owen at delong.com (Owen DeLong)
Date: Wed, 13 Jul 2016 19:42:22 -0700
Subject: New Office, New Network. Questions.
In-Reply-To: <CAPkb-7DgDgipaGDqiObA6dENm+BhDqFSZVVzAL9Fz7_rxc72cw@mail.gmail.com>
References: <219581468326611@web8h.yandex.ru>
 <CAPkb-7DgDgipaGDqiObA6dENm+BhDqFSZVVzAL9Fz7_rxc72cw@mail.gmail.com>
Message-ID: <785EC4AB-0A42-405D-88FC-C821F2576107@delong.com>

To provide some additional clarity and detail:

1.	No, you can?t to the best of my knowledge hand out any IPv6
	parameters via IPv4, nor should you really want to.

2.	You can hand out IPv6 DNS resolver information from either or both
	of SLAAC and DHCPv6.

	For SLAAC, you?ll need routers that support RFC 6106. Juniper finally
	added this in 14.1.

	Cisco added it in 15.4(1)T, 15.3(2)S

	More information here: https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems

	To the best of my knowledge, DNS is a configuration option in all DHCPv6
	implementations.

3.	I disagree with Baldur about not bothering with IPv6 DNS resolvers.
	Given that the long term goal is to get back to single-stack networking,
	but with the single stack being IPv6, each and every vestigial IPv4
	dependency you leave lying around is just another thing you need to clean
	up at some point in the future. Since it?s so completely easy to enable
	dual-stack (or even better IPv6-only) resolving when you first deploy
	IPv6 to your end-systems, why not just do that?

Owen

> On Jul 13, 2016, at 15:53 , Baldur Norddahl <baldur.norddahl at gmail.com> wrote:
> 
> "Is there a reason you use DHCPv6 and SLAAC? Is it for compatibility? Can I
> use the DHCPv4 to give out DNSv6 addresses?"
> 
> Unless you plan om having IPv6 only hosts, there is no advantage in
> providing IPv6 DNS servers. Just stay with IPv4 for your DNS resolver in
> the DHCPv4 config. Notice that your IPv4 DNs resolver is perfectly capable
> of providing AAAA IPv6 replies.
> 
> Using DHCPv6 in a corporate environment makes it easier to track which
> machine has an IP address as you can lookup the info in the DHCP lease
> database. Also some prefers the nice short addresses that you get from DHCP
> compared to SLAAC.
> 
> My network has both enabled, so my tablet has the following two addresses:
> 
> SLAAC: 2a00:7660:5c6:0:74cd:d48c:8230:a44f
> DHCP: 2a00:7660:5c6::701
> 
> The later is easier to type if you have to add rules to your firewall etc.
> 
> Regards
> 
> Baldur


From ryan at finnesey.com  Thu Jul 14 04:46:01 2016
From: ryan at finnesey.com (Ryan Finnesey)
Date: Thu, 14 Jul 2016 04:46:01 +0000
Subject: Canadian Internet Registration Authority (CIRA)
Message-ID: <BLUPR05MB595010AB3CD228F7C045A57B4320@BLUPR05MB595.namprd05.prod.outlook.com>

Is anyone from the Canadian Internet Registration Authority (CIRA) monitoring the list?  I was hoping they can ping me off list.  I have a few questions around there policy's and a program we would like to put in place.

Cheers
Ryan


From ryan at finnesey.com  Fri Jul 15 02:21:31 2016
From: ryan at finnesey.com (Ryan Finnesey)
Date: Fri, 15 Jul 2016 02:21:31 +0000
Subject: issues?
Message-ID: <BLUPR05MB59563AAB7A33F8F2973A53CB4330@BLUPR05MB595.namprd05.prod.outlook.com>

Is this list having issues?  The last message I received was late Tuesday.

Cheers
Ryan


From cboyd at gizmopartners.com  Fri Jul 15 02:43:57 2016
From: cboyd at gizmopartners.com (Chris Boyd)
Date: Thu, 14 Jul 2016 21:43:57 -0500
Subject: issues?
In-Reply-To: <BLUPR05MB59563AAB7A33F8F2973A53CB4330@BLUPR05MB595.namprd05.prod.outlook.com>
References: <BLUPR05MB59563AAB7A33F8F2973A53CB4330@BLUPR05MB595.namprd05.prod.outlook.com>
Message-ID: <E801FCA8-3229-48A9-81AB-34C04707486E@gizmopartners.com>


> On Jul 14, 2016, at 9:21 PM, Ryan Finnesey <ryan at finnesey.com> wrote:
> 
> Is this list having issues?  The last message I received was late Tuesday.

You didn?t get a message from your router vendor(s) that it?s time for the biennial cleaning of the intartubes and emptying of the bit buckets?

?Chris

From mark.tinka at seacom.mu  Fri Jul 15 05:06:40 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Fri, 15 Jul 2016 07:06:40 +0200
Subject: SAFNOG-3: Just 3 Weeks Left
Message-ID: <a9f96444-320b-f0fb-e371-6ce6c06e4880@seacom.mu>

Hello all.

With a little over 3 weeks left to SAFNOG-3, the program is shaping up
to be very exciting. You can view it here:

	http://www.safnog.org/event-name/

If you are interested in participating in SAFNOG-3 as a speaker or
panelist, there are still a few slots left in the agenda. Kindly review
the details of the CfP and submit your talk at the link below:

	http://www.safnog.org/#callforpapers

Travel and hotel venue information about Windhoek, Namibia, can be found
here:

	http://www.safnog.org/travel-information

For the social events at this year's SAFNOG meeting, we have organized
welcome drinks from 1700hrs by the pool side at the hotel venue on the
7th August:

	https://www.safarihotelsnamibia.com/safari-court-hotel/

On the 8th August, an opening cocktail in the evening has been planned
for at Joe's Beer House:

	http://www.joesbeerhouse.com/home.html

Our closing social will take place on the 9th August, with a braai and
dinner at the hotel venue.

On the 10th August, a game drive has been prepared at the Okapuka Ranch:

	http://www.okapuka-ranch.com/main.html

All social events will be complimentary to our SAFNOG-3 delegates.

We look forward to seeing you in Windhoek.

Cheers,

Mark Tinka
On Behalf of the SAFNOG Management Committee

From mianosm at gmail.com  Fri Jul 15 10:48:49 2016
From: mianosm at gmail.com (Steven Miano)
Date: Fri, 15 Jul 2016 06:48:49 -0400
Subject: issues?
In-Reply-To: <E801FCA8-3229-48A9-81AB-34C04707486E@gizmopartners.com>
References: <BLUPR05MB59563AAB7A33F8F2973A53CB4330@BLUPR05MB595.namprd05.prod.outlook.com>
 <E801FCA8-3229-48A9-81AB-34C04707486E@gizmopartners.com>
Message-ID: <CACkP6kmYrk4cEbrKKYuhodhwx=WKCT64st1fnPio83r3MnwB4Q@mail.gmail.com>

@Ryan

I've been receiving a lighter amount of messages, but there was traffic on
Tuesday, Wednesday, and Thursday....may want to check your spam/junk
folders?

On Thu, Jul 14, 2016 at 10:43 PM, Chris Boyd <cboyd at gizmopartners.com>
wrote:

>
> > On Jul 14, 2016, at 9:21 PM, Ryan Finnesey <ryan at finnesey.com> wrote:
> >
> > Is this list having issues?  The last message I received was late
> Tuesday.
>
> You didn?t get a message from your router vendor(s) that it?s time for the
> biennial cleaning of the intartubes and emptying of the bit buckets?
>
> ?Chris




-- 
Miano, Steven M.
http://stevenmiano.com

From cscora at apnic.net  Fri Jul 15 18:01:41 2016
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 16 Jul 2016 04:01:41 +1000 (AEST)
Subject: Weekly Routing Table Report
Message-ID: <20160715180141.37CB79BEEA@thyme.apnic.net>

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG,
SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG.

Daily listings are sent to bgp-stats at lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith <pfsinoz at gmail.com>.

Routing Table Report   04:00 +10GMT Sat 16 Jul, 2016

Report Website:     http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              604283
    Prefixes after maximum aggregation (per Origin AS):          218714
    Deaggregation factor:                                          2.76
    Unique aggregates announced (without unneeded subnets):      294430
Total ASes present in the Internet Routing Table:                 54306
    Prefixes per ASN:                                             11.13
Origin-only ASes present in the Internet Routing Table:           36527
Origin ASes announcing only one prefix:                           15528
Transit ASes present in the Internet Routing Table:                6435
Transit-only ASes present in the Internet Routing Table:            161
Average AS path length visible in the Internet Routing Table:       4.3
    Max AS path length visible:                                      54
    Max AS path prepend of ASN ( 55644)                              51
Prefixes from unregistered ASNs in the Routing Table:                56
    Unregistered ASNs in the Routing Table:                          12
Number of 32-bit ASNs allocated by the RIRs:                      14649
Number of 32-bit ASNs visible in the Routing Table:               11344
Prefixes from 32-bit ASNs in the Routing Table:                   44758
Number of bogon 32-bit ASNs visible in the Routing Table:            11
Special use prefixes present in the Routing Table:                    0
Prefixes being announced from unallocated address space:            388
Number of addresses announced to Internet:                   2821308388
    Equivalent to 168 /8s, 41 /16s and 191 /24s
    Percentage of available address space announced:               76.2
    Percentage of allocated address space announced:               76.2
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               98.2
Total number of prefixes smaller than registry allocations:      196731

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                   155939
    Total APNIC prefixes after maximum aggregation:               42673
    APNIC Deaggregation factor:                                    3.65
Prefixes being announced from the APNIC address blocks:          168048
    Unique aggregates announced from the APNIC address blocks:    68014
APNIC Region origin ASes present in the Internet Routing Table:    5196
    APNIC Prefixes per ASN:                                       32.34
APNIC Region origin ASes announcing only one prefix:               1179
APNIC Region transit ASes present in the Internet Routing Table:    934
Average APNIC Region AS path length visible:                        4.3
    Max APNIC Region AS path length visible:                         54
Number of APNIC region 32-bit ASNs visible in the Routing Table:   2225
Number of APNIC addresses announced to Internet:              759067716
    Equivalent to 45 /8s, 62 /16s and 116 /24s
    Percentage of available APNIC address space announced:         88.7

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 63488-64098, 64297-64395, 131072-137529
APNIC Address Blocks     1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
                        49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
                       106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
                       116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
                       123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
                       163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
                       203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
                       222/8, 223/8,

ARIN Region Analysis Summary
----------------------------

Prefixes being announced by ARIN Region ASes:                    182913
    Total ARIN prefixes after maximum aggregation:                89387
    ARIN Deaggregation factor:                                     2.05
Prefixes being announced from the ARIN address blocks:           188573
    Unique aggregates announced from the ARIN address blocks:     88343
ARIN Region origin ASes present in the Internet Routing Table:    16302
    ARIN Prefixes per ASN:                                        11.57
ARIN Region origin ASes announcing only one prefix:                5786
ARIN Region transit ASes present in the Internet Routing Table:    1699
Average ARIN Region AS path length visible:                         3.8
    Max ARIN Region AS path length visible:                          23
Number of ARIN region 32-bit ASNs visible in the Routing Table:    1327
Number of ARIN addresses announced to Internet:              1105487328
    Equivalent to 65 /8s, 228 /16s and 101 /24s
    Percentage of available ARIN address space announced:          58.5

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 62464-63487, 64198-64296, 393216-397212
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  45/8,  47/8,  48/8,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/8,  63/8,  64/8,
                        65/8,  66/8,  67/8,  68/8,  69/8,  70/8,  71/8,
                        72/8,  73/8,  74/8,  75/8,  76/8,  96/8,  97/8,
                        98/8,  99/8, 100/8, 104/8, 107/8, 108/8, 128/8,
                       129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8,
                       137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8,
                       146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8,
                       157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8,
                       165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8,
                       173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8,
                       205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8,
                       216/8,

RIPE Region Analysis Summary
----------------------------

Prefixes being announced by RIPE Region ASes:                    144900
    Total RIPE prefixes after maximum aggregation:                71186
    RIPE Deaggregation factor:                                     2.04
Prefixes being announced from the RIPE address blocks:           154555
    Unique aggregates announced from the RIPE address blocks:     94995
RIPE Region origin ASes present in the Internet Routing Table:    18083
    RIPE Prefixes per ASN:                                         8.55
RIPE Region origin ASes announcing only one prefix:                7822
RIPE Region transit ASes present in the Internet Routing Table:    2992
Average RIPE Region AS path length visible:                         4.4
    Max RIPE Region AS path length visible:                          27
Number of RIPE region 32-bit ASNs visible in the Routing Table:    4922
Number of RIPE addresses announced to Internet:               705542272
    Equivalent to 42 /8s, 13 /16s and 184 /24s
    Percentage of available RIPE address space announced:         102.6

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       59392-61439, 61952-62463, 196608-204287
RIPE Address Blocks      2/8,   5/8,  25/8,  31/8,  37/8,  46/8,  51/8,
                        62/8,  77/8,  78/8,  79/8,  80/8,  81/8,  82/8,
                        83/8,  84/8,  85/8,  86/8,  87/8,  88/8,  89/8,
                        90/8,  91/8,  92/8,  93/8,  94/8,  95/8, 109/8,
                       141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8,
                       193/8, 194/8, 195/8, 212/8, 213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   61513
    Total LACNIC prefixes after maximum aggregation:              12272
    LACNIC Deaggregation factor:                                   5.01
Prefixes being announced from the LACNIC address blocks:          76566
    Unique aggregates announced from the LACNIC address blocks:   36665
LACNIC Region origin ASes present in the Internet Routing Table:   2476
    LACNIC Prefixes per ASN:                                      30.92
LACNIC Region origin ASes announcing only one prefix:               562
LACNIC Region transit ASes present in the Internet Routing Table:   564
Average LACNIC Region AS path length visible:                       4.8
    Max LACNIC Region AS path length visible:                        26
Number of LACNIC region 32-bit ASNs visible in the Routing Table:  2632
Number of LACNIC addresses announced to Internet:             170025536
    Equivalent to 10 /8s, 34 /16s and 98 /24s
    Percentage of available LACNIC address space announced:       101.3

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       61440-61951, 64099-64197, 262144-265628 + ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       191/8, 200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                  14203
    Total AfriNIC prefixes after maximum aggregation:              3186
    AfriNIC Deaggregation factor:                                  4.46
Prefixes being announced from the AfriNIC address blocks:         16153
    Unique aggregates announced from the AfriNIC address blocks:   6053
AfriNIC Region origin ASes present in the Internet Routing Table:   737
    AfriNIC Prefixes per ASN:                                     21.92
AfriNIC Region origin ASes announcing only one prefix:              179
AfriNIC Region transit ASes present in the Internet Routing Table:  177
Average AfriNIC Region AS path length visible:                      4.6
    Max AfriNIC Region AS path length visible:                       19
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:  238
Number of AfriNIC addresses announced to Internet:             80838912
    Equivalent to 4 /8s, 209 /16s and 129 /24s
    Percentage of available AfriNIC address space announced:       80.3

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 154/8, 196/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4538     5556       4191          75   ERX-CERNET-BKB China Education and Rese
 7545     3415        384         254   TPG-INTERNET-AP TPG Telecom Limited, AU
 4766     3179      11144        1130   KIXS-AS-KR Korea Telecom, KR
17974     2937        907          82   TELKOMNET-AS2-AP PT Telekomunikasi Indo
 9829     2560       1485         515   BSNL-NIB National Internet Backbone, IN
 1659     2492       1466          38   ERX-TANET-ASN1 Taiwan Academic Network 
 9808     2153       8761          40   CMNET-GD Guangdong Mobile Communication
 4755     2079        431         239   TATACOMM-AS TATA Communications formerl
 4808     1716       2317         556   CHINA169-BJ China Unicom Beijing Provin
38197     1494         93         274   SUNHK-DATA-AS-AP Sun Network (Hong Kong

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC

ARIN Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
22773     3483       2965         144   ASN-CXA-ALL-CCI-22773-RDC - Cox Communi
 6389     2225       3671          41   BELLSOUTH-NET-BLK - BellSouth.net Inc.,
18566     2197        405         110   MEGAPATH5-US - MegaPath Corporation, US
20115     1928       1951         408   CHARTER-NET-HKY-NC - Charter Communicat
  209     1713       5103         656   CENTURYLINK-US-LEGACY-QWEST - Qwest Com
30036     1689        339         438   MEDIACOM-ENTERPRISE-BUSINESS - Mediacom
 6983     1687        849         228   ITCDELTA - Earthlink, Inc., US
 7018     1346      20075        1000   ATT-INTERNET4 - AT&T Services, Inc., US
11492     1336        236         550   CABLEONE - CABLE ONE, INC., US
16509     1333       2475         422   AMAZON-02 - Amazon.com, Inc., US

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN

RIPE Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
39891     3329        169          15   ALJAWWALSTC-AS , SA
20940     2715       1053        1923   AKAMAI-ASN1 , US
34984     1974        327         358   TELLCOM-AS , TR
 8551     1279        377          46   BEZEQ-INTERNATIONAL-AS Bezeqint Interne
12479     1277       1002          45   UNI2-AS , ES
 6849     1148        355          21   UKRTELNET , UA
13188     1090         98          65   BANKINFORM-AS , UA
 8402     1041        544          15   CORBINA-AS Russia, RU
31148     1017         47          44   FREENET-AS , UA
 6830      888       2752         462   LGI-UPC formerly known as UPC Broadband

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
10620     3479        543         124   Telmex Colombia S.A., CO
 8151     2274       3365         560   Uninet S.A. de C.V., MX
 7303     1531        949         240   Telecom Argentina S.A., AR
11830     1489        369          66   Instituto Costarricense de Electricidad
 6503     1364        437          54   Axtel, S.A.B. de C.V., MX
 6147     1106        377          27   Telefonica del Peru S.A.A., PE
 3816     1001        477         179   COLOMBIA TELECOMUNICACIONES S.A. ESP, C
 7738      994       1882          40   Telemar Norte Leste S.A., BR
11172      907        125          76   Alestra, S. de R.L. de C.V., MX
28573      877       2178         159   CLARO S.A., BR

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC

AfriNIC Region per AS prefix count summary
------------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
24863     1228        402          48   LINKdotNET-AS, EG
36903      656        330         109   MT-MPLS, MA
37611      646         48           2   Afrihost, ZA
36992      541       1357          26   ETISALAT-MISR, EG
 8452      505       1472          15   TE-AS TE-AS, EG
37492      378        234          68   ORANGE-TN, TN
24835      329        594          15   RAYA-AS, EG
29571      299         37          12   CITelecom-AS, CI
 2018      257        327          74   TENET-1, ZA
36947      225        855          15   ALGTEL-AS, DZ

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC

Global Per AS prefix count summary
----------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4538     5556       4191          75   ERX-CERNET-BKB China Education and Rese
22773     3483       2965         144   ASN-CXA-ALL-CCI-22773-RDC - Cox Communi
10620     3479        543         124   Telmex Colombia S.A., CO
 7545     3415        384         254   TPG-INTERNET-AP TPG Telecom Limited, AU
39891     3329        169          15   ALJAWWALSTC-AS , SA
 4766     3179      11144        1130   KIXS-AS-KR Korea Telecom, KR
17974     2937        907          82   TELKOMNET-AS2-AP PT Telekomunikasi Indo
20940     2715       1053        1923   AKAMAI-ASN1 , US
 9829     2560       1485         515   BSNL-NIB National Internet Backbone, IN
 1659     2492       1466          38   ERX-TANET-ASN1 Taiwan Academic Network 

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
10620      3479        3355      Telmex Colombia S.A., CO
22773      3483        3339      ASN-CXA-ALL-CCI-22773-RDC - Cox Communi
39891      3329        3314      ALJAWWALSTC-AS , SA
 7545      3415        3161      TPG-INTERNET-AP TPG Telecom Limited, AU
17974      2937        2855      TELKOMNET-AS2-AP PT Telekomunikasi Indo
 1659      2492        2454      ERX-TANET-ASN1 Taiwan Academic Network 
 6389      2225        2184      BELLSOUTH-NET-BLK - BellSouth.net Inc.,
 9808      2153        2113      CMNET-GD Guangdong Mobile Communication
18566      2197        2087      MEGAPATH5-US - MegaPath Corporation, US
 4766      3179        2049      KIXS-AS-KR Korea Telecom, KR

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS  Designation  Network              Transit AS  Description
65001   PRIVATE      5.143.176.0/20       15468       KLGELECS-AS 38, Teatralnaya st
65001   PRIVATE      31.172.192.0/20      15468       KLGELECS-AS 38, Teatralnaya st
65001   PRIVATE      31.172.192.0/21      15468       KLGELECS-AS 38, Teatralnaya st
65001   PRIVATE      31.172.200.0/21      15468       KLGELECS-AS 38, Teatralnaya st
65001   PRIVATE      31.172.208.0/21      15468       KLGELECS-AS 38, Teatralnaya st
65001   PRIVATE      31.172.216.0/21      15468       KLGELECS-AS 38, Teatralnaya st
65000   PRIVATE      31.219.177.0/25       8966       ETISALAT-AS P.O. Box 1150, Dub
65000   PRIVATE      31.219.177.128/25     8966       ETISALAT-AS P.O. Box 1150, Dub
65001   PRIVATE      46.237.32.0/20       13118       ASN-YARTELECOM Verhnevolzhsky 
64502   RESERVED     92.38.215.0/24       12695       DINET-AS , RU

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
23.249.144.0/20      40430     COLO4JAX-AS - colo4jax, LLC, US
27.100.7.0/24        56096     UNKNOWN
41.73.1.0/24         37004     -Reserved AS-, ZZ
41.73.2.0/24         37004     -Reserved AS-, ZZ
41.73.3.0/24         37004     -Reserved AS-, ZZ
41.73.4.0/24         37004     -Reserved AS-, ZZ
41.73.5.0/24         37004     -Reserved AS-, ZZ
41.73.6.0/24         37004     -Reserved AS-, ZZ
41.73.7.0/24         37004     -Reserved AS-, ZZ
41.73.8.0/24         37004     -Reserved AS-, ZZ

Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA

Number of prefixes announced per prefix length (Global)
-------------------------------------------------------

 /1:0        /2:0        /3:0        /4:0        /5:0        /6:0       
 /7:0        /8:16       /9:13      /10:36      /11:101     /12:266     
/13:518     /14:1049    /15:1772    /16:13165   /17:7812    /18:12757   
/19:25309   /20:38237   /21:40145   /22:66925   /23:58566   /24:335940  
/25:562     /26:587     /27:377     /28:49      /29:32      /30:16      
/31:1       /32:32      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
39891     2896          3329      ALJAWWALSTC-AS , SA
22773     2717          3483      ASN-CXA-ALL-CCI-22773-RDC - Cox Communi
18566     2089          2197      MEGAPATH5-US - MegaPath Corporation, US
30036     1503          1689      MEDIACOM-ENTERPRISE-BUSINESS - Mediacom
 6389     1440          2225      BELLSOUTH-NET-BLK - BellSouth.net Inc.,
10620     1383          3479      Telmex Colombia S.A., CO
 6983     1339          1687      ITCDELTA - Earthlink, Inc., US
34984     1257          1974      TELLCOM-AS , TR
11492     1236          1336      CABLEONE - CABLE ONE, INC., US
 6849      968          1148      UKRTELNET , UA

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:1577      2:728       4:21        5:2139      6:31        8:972    
  12:1777     13:41       14:1721     15:45       16:2        17:84     
  18:112      20:49       22:1        23:1690     24:1783     27:2282   
  31:1787     32:67       33:3        34:2        35:5        36:304    
  37:2267     38:1233     39:35       40:94       41:2740     42:444    
  43:1809     44:43       45:2095     46:2520     47:83       49:1158   
  50:892      51:20       52:515      54:338      55:9        56:7      
  57:42       58:1595     59:937      60:351      61:1832     62:1486   
  63:1931     64:4519     65:2176     66:4279     67:2217     68:1120   
  69:3286     70:1254     71:483      72:2026     74:2547     75:343    
  76:378      77:1429     78:1266     79:877      80:1249     81:1378   
  82:967      83:719      84:852      85:1599     86:483      87:1097   
  88:552      89:2020     90:189      91:6068     92:957      93:2381   
  94:2408     95:2472     96:522      97:372      98:948      99:41     
 100:75      101:1067    103:11555   104:2510    105:127     106:433    
 107:1392    108:662     109:2233    110:1277    111:1634    112:1022   
 113:1120    114:1080    115:1654    116:1610    117:1526    118:1980   
 119:1602    120:1268    121:1168    122:2185    123:2037    124:1582   
 125:1726    128:698     129:422     130:410     131:1343    132:597    
 133:175     134:467     135:135     136:379     137:394     138:1751   
 139:296     140:712     141:453     142:648     143:919     144:711    
 145:184     146:889     147:648     148:1362    149:533     150:653    
 151:1020    152:636     153:302     154:651     155:956     156:513    
 157:488     158:417     159:1141    160:505     161:726     162:2343   
 163:921     164:890     165:1055    166:314     167:1158    168:1969   
 169:670     170:1775    171:262     172:595     173:1641    174:755    
 175:721     176:1728    177:4056    178:2213    179:1134    180:2081   
 181:1814    182:1954    183:980     184:834     185:6927    186:2994   
 187:2069    188:2174    189:1725    190:7846    191:1262    192:9045   
 193:5723    194:4451    195:3830    196:1706    197:1048    198:5544   
 199:5747    200:7043    201:3752    202:10046   203:10041   204:4507   
 205:2728    206:2994    207:3103    208:4089    209:3881    210:4256   
 211:2039    212:2725    213:2302    214:870     215:70      216:5857   
 217:1984    218:801     219:623     220:1634    221:862     222:678    
 223:1269   

End of report

From bzs at theworld.com  Fri Jul 15 20:44:44 2016
From: bzs at theworld.com (bzs at theworld.com)
Date: Fri, 15 Jul 2016 16:44:44 -0400
Subject: Military coup in Turkey?
Message-ID: <22409.19260.479161.861731@pcls8.std.com>


It looks to me like the Turkish internet is unreachable.

-- 
        -Barry Shein

Software Tool & Die    | bzs at TheWorld.com             | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

From patrick at ianai.net  Fri Jul 15 20:46:01 2016
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Fri, 15 Jul 2016 16:46:01 -0400
Subject: Military coup in Turkey?
In-Reply-To: <22409.19260.479161.861731@pcls8.std.com>
References: <22409.19260.479161.861731@pcls8.std.com>
Message-ID: <D80C0F73-B2AA-45E8-AEBF-C82800014B6A@ianai.net>

http://www.telegraph.co.uk/news/2016/07/15/turkey-low-flying-jets-and-gunfire-heard-in-ankara1/

-- 
TTFN,
patrick

> On Jul 15, 2016, at 4:44 PM, bzs at theworld.com wrote:
> 
> 
> It looks to me like the Turkish internet is unreachable.
> 
> -- 
>        -Barry Shein
> 
> Software Tool & Die    | bzs at TheWorld.com             | http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*


From dovid at telecurve.com  Fri Jul 15 20:48:28 2016
From: dovid at telecurve.com (Dovid Bender)
Date: Fri, 15 Jul 2016 20:48:28 +0000
Subject: Military coup in Turkey?
In-Reply-To: <22409.19260.479161.861731@pcls8.std.com>
References: <22409.19260.479161.861731@pcls8.std.com>
Message-ID: <1359648051-1468615709-cardhu_decombobulator_blackberry.rim.net-870821358-@b16.c1.bise6.blackberry>

Seems so. Check twitter. Its been on there for about an hour.

Regards,

Dovid

-----Original Message-----
From: bzs at theworld.com
Sender: "NANOG" <nanog-bounces at nanog.org>Date: Fri, 15 Jul 2016 16:44:44 
To: <nanog at nanog.org>
Subject: Military coup in Turkey?


It looks to me like the Turkish internet is unreachable.

-- 
        -Barry Shein

Software Tool & Die    | bzs at TheWorld.com             | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*


From jra at baylink.com  Fri Jul 15 22:55:08 2016
From: jra at baylink.com (Jay R. Ashworth)
Date: Fri, 15 Jul 2016 22:55:08 +0000 (UTC)
Subject: issues?
In-Reply-To: <BLUPR05MB59563AAB7A33F8F2973A53CB4330@BLUPR05MB595.namprd05.prod.outlook.com>
References: <BLUPR05MB59563AAB7A33F8F2973A53CB4330@BLUPR05MB595.namprd05.prod.outlook.com>
Message-ID: <270480737.7384.1468623308084.JavaMail.zimbra@baylink.com>

----- Original Message -----
> From: "Ryan Finnesey" <ryan at finnesey.com>

> Is this list having issues?  The last message I received was late Tuesday.

Do you have an email vendor in Turkey?  

:-)

No; I've got 10-20 messages a day all week sitting in my folder.

There *were* a couple of bursts of hi-rate spam ostensibly from NANOGers
again this past week, so that might have ticked off your spam filter.

Cheers,
-- jra

-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274

From freetexwatson at gmail.com  Sat Jul 16 00:56:35 2016
From: freetexwatson at gmail.com (B F)
Date: Fri, 15 Jul 2016 20:56:35 -0400
Subject: Bat Blue cloud security
Message-ID: <8cm96sya0h63l9uwkprdivia.1468630335305@email.android.com>


    
Happy Friday list,
Any experiences/opinions to share about batblue.Com ?
tia, ed

From jhaustin at gmail.com  Sun Jul 17 23:50:02 2016
From: jhaustin at gmail.com (Jeremy Austin)
Date: Sun, 17 Jul 2016 15:50:02 -0800
Subject: University of Alaska AS7774 NOC?
Message-ID: <CABNB40VhbBZy-rEuhkE9Tr+Dn=7J0LK9ESf-qvMk4cZS-r=4Xw@mail.gmail.com>

If there's anyone on call at network operations for the University of
Alaska, AS7774, please contact me or ACS NOC, who have an open trouble
ticket.

We appear to be having BPG reachability issues on your ACS peering.

Thank you,

-- 
Jeremy Austin

(907) 895-2311
(907) 803-5422
jhaustin at gmail.com

Heritage NetWorks
Whitestone Power & Communications
Vertical Broadband, LLC

Schedule a meeting: http://doodle.com/jermudgeon

From jhaustin at gmail.com  Mon Jul 18 04:19:05 2016
From: jhaustin at gmail.com (Jeremy Austin)
Date: Sun, 17 Jul 2016 20:19:05 -0800
Subject: University of Alaska AS7774 NOC?
In-Reply-To: <CABNB40VhbBZy-rEuhkE9Tr+Dn=7J0LK9ESf-qvMk4cZS-r=4Xw@mail.gmail.com>
References: <CABNB40VhbBZy-rEuhkE9Tr+Dn=7J0LK9ESf-qvMk4cZS-r=4Xw@mail.gmail.com>
Message-ID: <CABNB40W7AWmC6eQJN0AArjGsZZ=cS8R1-LGAOMqtjFwsbZHJBQ@mail.gmail.com>

On Sun, Jul 17, 2016 at 3:50 PM, Jeremy Austin <jhaustin at gmail.com> wrote:

> If there's anyone on call at network operations for the University of
> Alaska, AS7774, please contact me or ACS NOC, who have an open trouble
> ticket.
>
> We appear to be having BPG reachability issues on your ACS peering.
>

I want to extend thanks to the folks at University of Alaska, several of
whom contacted me immediately.

The issue turned out to be with ACS (AS7782), whose network engineers are
also on NANOG and called me almost right away, even the one on leave whom
the NOC couldn't reach.

That's what I call service. Thanks again, you deserve a shout out.


-- 
Jeremy Austin

(907) 895-2311
(907) 803-5422
jhaustin at gmail.com

Heritage NetWorks
Whitestone Power & Communications
Vertical Broadband, LLC

Schedule a meeting: http://doodle.com/jermudgeon

From xcellula at gmail.com  Wed Jul 13 21:37:44 2016
From: xcellula at gmail.com (eric c)
Date: Wed, 13 Jul 2016 16:37:44 -0500
Subject: akamai abnormal spike
Message-ID: <CAA3RQS8eqG-x6eMg8D6SnbnV=G3eDjezHGDUmrP=9N-GJ=wprg@mail.gmail.com>

Good afternoon,

Has anyone notice any abnormal spike in Akamai trafic in the last 24-48
hours compared to other days. I know it was black tuesday yesterday but
traffic from last month didn't even come close to what we saw from Akamai.

We have some caching servers and even notice a spike to them as well.

Limelight even showed up on our network.

thanks
eric

From sharath at cis-india.org  Fri Jul 15 10:10:14 2016
From: sharath at cis-india.org (Sharath Chandra)
Date: Fri, 15 Jul 2016 15:40:14 +0530
Subject: Report on Airtel (Indian Mobile Operator) Sniffing Cloudfare
Message-ID: <25AF5923-8475-4CE8-91E1-801F438E30D1@cis-india.org>

Dear List

Last week, this report has now created bit of a stir within the net-neutrality policy circles and ISPs in India.

I was hoping anyone here could see if this analysis and hunch about Airtel India?s sneaky practices is indeed correct :
https://medium.com/@karthikb351/airtel-is-sniffing-and-censoring-cloudflares-traffic-in-india-and-they-don-t-even-know-it-90935f7f6d98#.b56b4n927 <https://medium.com/@karthikb351/airtel-is-sniffing-and-censoring-cloudflares-traffic-in-india-and-they-don-t-even-know-it-90935f7f6d98#.b56b4n927>

Regards
Sharath Chandra Ram
Twitter: @AgentSpock
Signal Lab: http://goo.gl/rssCdH <http://goo.gl/rssCdH>





From deji.fatunla at gmail.com  Fri Jul 15 20:50:31 2016
From: deji.fatunla at gmail.com (Deji Fatunla)
Date: Fri, 15 Jul 2016 14:50:31 -0600
Subject: Military coup in Turkey?
In-Reply-To: <D80C0F73-B2AA-45E8-AEBF-C82800014B6A@ianai.net>
References: <22409.19260.479161.861731@pcls8.std.com>
 <D80C0F73-B2AA-45E8-AEBF-C82800014B6A@ianai.net>
Message-ID: <CAGW=EHwvVGA3iJO9kBstnAcTVFAeZnXh6zhwWiiGMHEKEnG-2A@mail.gmail.com>

http://edition.cnn.com/2016/07/15/asia/turkey-military-action/index.html?adkey=bn

On 15 July 2016 at 14:46, Patrick W. Gilmore <patrick at ianai.net> wrote:

>
> http://www.telegraph.co.uk/news/2016/07/15/turkey-low-flying-jets-and-gunfire-heard-in-ankara1/
>
> --
> TTFN,
> patrick
>
> > On Jul 15, 2016, at 4:44 PM, bzs at theworld.com wrote:
> >
> >
> > It looks to me like the Turkish internet is unreachable.
> >
> > --
> >        -Barry Shein
> >
> > Software Tool & Die    | bzs at TheWorld.com             |
> http://www.TheWorld.com
> > Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
> > The World: Since 1989  | A Public Information Utility | *oo*
>
>


-- 
Geek by Nature, Linux by choice!

From gdupin at taho.fr  Fri Jul 15 20:56:49 2016
From: gdupin at taho.fr (Gerard Dupin)
Date: Fri, 15 Jul 2016 22:56:49 +0200
Subject: Military coup in Turkey?
In-Reply-To: <1359648051-1468615709-cardhu_decombobulator_blackberry.rim.net-870821358-@b16.c1.bise6.blackberry>
References: <22409.19260.479161.861731@pcls8.std.com>
 <1359648051-1468615709-cardhu_decombobulator_blackberry.rim.net-870821358-@b16.c1.bise6.blackberry>
Message-ID: <8D75EF1B-B645-4212-925F-43936BC807AA@taho.fr>

Look at reddit 
https://www.reddit.com/live/x9gf3donjlkq
:)
Ge

> Le 15 juil. 2016 ? 22:48, Dovid Bender <dovid at telecurve.com> a ?crit :
> 
> Seems so. Check twitter. Its been on there for about an hour.
> 
> Regards,
> 
> Dovid
> 
> -----Original Message-----
> From: bzs at theworld.com
> Sender: "NANOG" <nanog-bounces at nanog.org>Date: Fri, 15 Jul 2016 16:44:44 
> To: <nanog at nanog.org>
> Subject: Military coup in Turkey?
> 
> 
> It looks to me like the Turkish internet is unreachable.
> 
> -- 
>        -Barry Shein
> 
> Software Tool & Die    | bzs at TheWorld.com             | http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*
> 


From listsen at 0x906.com  Fri Jul 15 21:09:31 2016
From: listsen at 0x906.com (0x906)
Date: Fri, 15 Jul 2016 17:09:31 -0400
Subject: Military coup in Turkey?
In-Reply-To: <608129.c6234d813a077bcee75485878eafbf00cf3622e1@popretr.messagingengine.com>
References: <22409.19260.479161.861731@pcls8.std.com>
 <608129.c6234d813a077bcee75485878eafbf00cf3622e1@popretr.messagingengine.com>
 <1359648051-1468615709-cardhu_decombobulator_blackberry.rim.net-870821358-@b16.c1.bise6.blackberry>
Message-ID: <1468616971.1316486.667627217.4D67F8C7@webmail.messagingengine.com>

It might be an attempt actually and not a real coup.  

On Fri, Jul 15, 2016, at 04:48 PM, Dovid Bender wrote:
> Seems so. Check twitter. Its been on there for about an hour.
> 
> Regards,
> 
> Dovid
> 
> -----Original Message-----
> From: bzs at theworld.com
> Sender: "NANOG" <nanog-bounces at nanog.org>Date: Fri, 15 Jul 2016 16:44:44 
> To: <nanog at nanog.org>
> Subject: Military coup in Turkey?
> 
> 
> It looks to me like the Turkish internet is unreachable.
> 
> -- 
>         -Barry Shein
> 
> Software Tool & Die    | bzs at TheWorld.com             |
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*

From bortzmeyer at nic.fr  Mon Jul 18 13:24:28 2016
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Mon, 18 Jul 2016 15:24:28 +0200
Subject: NANOG is five days late?
Message-ID: <20160718132428.GA18991@nic.fr>

This message just arrived...

Received: from mail.nanog.org (localhost [127.0.0.1])
        by mail.nanog.org (Postfix) with ESMTP id 96AA42D47BB;
        Mon, 18 Jul 2016 13:15:14 +0000 (UTC)
X-Original-To: nanog at nanog.org
Delivered-To: nanog at nanog.org
Received: from mail-it0-x245.google.com (mail-it0-x245.google.com
        [IPv6:2607:f8b0:4001:c0b::245])
        by mail.nanog.org (Postfix) with ESMTPS id 823B72D4651
        for <nanog at nanog.org>; Wed, 13 Jul 2016 21:37:45 +0000 (UTC)
Received: by mail-it0-x245.google.com with SMTP id f6so105118753ith.3
        for <nanog at nanog.org>; Wed, 13 Jul 2016 14:37:45 -0700 (PDT)

From clayton at MNSi.Net  Mon Jul 18 13:26:09 2016
From: clayton at MNSi.Net (Clayton Zekelman)
Date: Mon, 18 Jul 2016 09:26:09 -0400
Subject: akamai abnormal spike
In-Reply-To: <CAA3RQS8eqG-x6eMg8D6SnbnV=G3eDjezHGDUmrP=9N-GJ=wprg@mail.g
 mail.com>
References: <CAA3RQS8eqG-x6eMg8D6SnbnV=G3eDjezHGDUmrP=9N-GJ=wprg@mail.gmail.com>
Message-ID: <1468848371_93759@surgemail.mnsi.net>



We noticed on the 12th and 13th there was a significant up tick in 
traffic served from our Akamai servers as well.


At 05:37 PM 13/07/2016, eric c wrote:
>Good afternoon,
>
>Has anyone notice any abnormal spike in Akamai trafic in the last 24-48
>hours compared to other days. I know it was black tuesday yesterday but
>traffic from last month didn't even come close to what we saw from Akamai.
>
>We have some caching servers and even notice a spike to them as well.
>
>Limelight even showed up on our network.
>
>thanks
>eric

-- 

Clayton Zekelman
Managed Network Systems Inc. (MNSi)
3363 Tecumseh Rd. E
Windsor, Ontario
N8W 1H4

tel. 519-985-8410
fax. 519-985-8409        


From math at sizone.org  Mon Jul 18 13:30:32 2016
From: math at sizone.org (Ken Chase)
Date: Mon, 18 Jul 2016 09:30:32 -0400
Subject: Military coup in Turkey?
In-Reply-To: <8D75EF1B-B645-4212-925F-43936BC807AA@taho.fr>
References: <22409.19260.479161.861731@pcls8.std.com>
 <1359648051-1468615709-cardhu_decombobulator_blackberry.rim.net-870821358-@b16.c1.bise6.blackberry>
 <8D75EF1B-B645-4212-925F-43936BC807AA@taho.fr>
Message-ID: <20160718133032.GB28053@sizone.org>

Lil late to the party?

Received: from mail.nanog.org (localhost [127.0.0.1])                                     
        by mail.nanog.org (Postfix) with ESMTP id E884C2D4872;                            
        Mon, 18 Jul 2016 13:15:20 +0000 (UTC)                                             
X-Original-To: nanog at nanog.org                                                            
Delivered-To: nanog at nanog.org                                                             
Received: from mail-wm0-f70.google.com (mail-wm0-f70.google.com [74.125.82.70])           
        by mail.nanog.org (Postfix) with ESMTPS id 348402D46CA                            
        for <nanog at nanog.org>; Fri, 15 Jul 2016 20:56:53 +0000 (UTC)                      

sup?

/kc


On Fri, Jul 15, 2016 at 10:56:49PM +0200, Gerard Dupin said:
  >Look at reddit 
  >https://www.reddit.com/live/x9gf3donjlkq
  >:)
  >Ge
  >
  >> Le 15 juil. 2016 ?? 22:48, Dovid Bender <dovid at telecurve.com> a ??crit :
  >> 
  >> Seems so. Check twitter. Its been on there for about an hour.
  >> 
  >> Regards,
  >> 
  >> Dovid
  >> 
  >> -----Original Message-----
  >> From: bzs at theworld.com
  >> Sender: "NANOG" <nanog-bounces at nanog.org>Date: Fri, 15 Jul 2016 16:44:44 
  >> To: <nanog at nanog.org>
  >> Subject: Military coup in Turkey?
  >> 
  >> 
  >> It looks to me like the Turkish internet is unreachable.
  >> 
  >> -- 
  >>        -Barry Shein
  >> 
  >> Software Tool & Die    | bzs at TheWorld.com             | http://www.TheWorld.com
  >> Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
  >> The World: Since 1989  | A Public Information Utility | *oo*
  >> 
  >

-- 
Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada
Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W.

From blake at ispn.net  Mon Jul 18 13:49:21 2016
From: blake at ispn.net (Blake Hudson)
Date: Mon, 18 Jul 2016 08:49:21 -0500
Subject: akamai abnormal spike
In-Reply-To: <1468848371_93759@surgemail.mnsi.net>
References: <CAA3RQS8eqG-x6eMg8D6SnbnV=G3eDjezHGDUmrP=9N-GJ=wprg@mail.gmail.com>
 <1468848371_93759@surgemail.mnsi.net>
Message-ID: <c39b3f31-6a6e-c3ec-cec0-87bde9ff8577@ispn.net>

We noticed that on the 12th-14th we had multiple subscribers on ~5Mbps 
subscription rates that were being sent ~50Mbps of data sourced from TCP 
port 80 (apparently HTTP) from Limelight Networks' servers. The data did 
appear to be user requested, still not sure why TCP didn't throttle the 
data rate appropriately. The 50Mbps was distributed across multiple LLNW 
servers. Makes me wonder if the customer was requesting one batch of 
data and multiple servers were responding.

The issue cleared up on its own and I never was able to perform a full 
packet capture to investigate. I have not noticed the same behavior from 
Akamai servers.

Clayton Zekelman wrote on 7/18/2016 8:26 AM:
>
>
> We noticed on the 12th and 13th there was a significant up tick in 
> traffic served from our Akamai servers as well.
>
>
> At 05:37 PM 13/07/2016, eric c wrote:
>> Good afternoon,
>>
>> Has anyone notice any abnormal spike in Akamai trafic in the last 24-48
>> hours compared to other days. I know it was black tuesday yesterday but
>> traffic from last month didn't even come close to what we saw from 
>> Akamai.
>>
>> We have some caching servers and even notice a spike to them as well.
>>
>> Limelight even showed up on our network.
>>
>> thanks
>> eric
>


From bhatton at htva.net  Mon Jul 18 13:50:02 2016
From: bhatton at htva.net (Benjamin Hatton)
Date: Mon, 18 Jul 2016 09:50:02 -0400
Subject: NANOG is five days late?
In-Reply-To: <20160718132428.GA18991@nic.fr>
References: <20160718132428.GA18991@nic.fr>
Message-ID: <CADvg1U-nKgceBc2uyWkRrZJNogHPMSy7aYyXK6HM9-oeLus8HQ@mail.gmail.com>

I also am seeing messages from several threads being delayed 3-5 days

*Ben Hatton*

Network Engineer

Haefele TV Inc.

d:(607)589-8000

bhatton at htva.net

www.htva.net

On Mon, Jul 18, 2016 at 9:24 AM, Stephane Bortzmeyer <bortzmeyer at nic.fr>
wrote:

> This message just arrived...
>
> Received: from mail.nanog.org (localhost [127.0.0.1])
>         by mail.nanog.org (Postfix) with ESMTP id 96AA42D47BB;
>         Mon, 18 Jul 2016 13:15:14 +0000 (UTC)
> X-Original-To: nanog at nanog.org
> Delivered-To: nanog at nanog.org
> Received: from mail-it0-x245.google.com (mail-it0-x245.google.com
>         [IPv6:2607:f8b0:4001:c0b::245])
>         by mail.nanog.org (Postfix) with ESMTPS id 823B72D4651
>         for <nanog at nanog.org>; Wed, 13 Jul 2016 21:37:45 +0000 (UTC)
> Received: by mail-it0-x245.google.com with SMTP id f6so105118753ith.3
>         for <nanog at nanog.org>; Wed, 13 Jul 2016 14:37:45 -0700 (PDT)
>

From ak47 at gawul.net  Mon Jul 18 14:02:45 2016
From: ak47 at gawul.net (Andy Koch)
Date: Mon, 18 Jul 2016 09:02:45 -0500
Subject: NANOG is five days late?
In-Reply-To: <20160718132428.GA18991@nic.fr>
References: <20160718132428.GA18991@nic.fr>
Message-ID: <20160718140245.GE4176@nutcracker.gawul.net>

On Mon, Jul 18, 2016 at 03:24:28PM +0200, Stephane Bortzmeyer wrote:
> This message just arrived...


Hi Stephane and the list,

The NANOG mailing list has a policy to hold the first post from all new
subscribers and those who have not posted in a long time (one year+).
As it is a manual process to clear the moderation flag on subscribers
and release the messages, it us up to a few humans that will take some
time away on occasion. We find it is best to release the messages late
when this does happen. Sorry for the delay.

Andy Koch
NANOG CC

From bortzmeyer at nic.fr  Mon Jul 18 14:20:02 2016
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Mon, 18 Jul 2016 16:20:02 +0200
Subject: NANOG is five days late?
In-Reply-To: <20160718135244.GC4176@nutcracker.gawul.net>
References: <20160718132428.GA18991@nic.fr>
 <20160718135244.GC4176@nutcracker.gawul.net>
Message-ID: <20160718142002.GA26043@nic.fr>

On Mon, Jul 18, 2016 at 08:53:02AM -0500,
 Andy Koch <andy at gawul.net> wrote 
 a message of 15 lines which said:

> The NANOG mailing list has a policy to hold the first post from all
> new subscribers and those who have not posted in a long time (one
> year+).

So, the batch of messages which has just been "liberated" were all by
newcomers?

From nanog at ics-il.net  Mon Jul 18 14:57:17 2016
From: nanog at ics-il.net (Mike Hammett)
Date: Mon, 18 Jul 2016 09:57:17 -0500 (CDT)
Subject: akamai abnormal spike
In-Reply-To: <c39b3f31-6a6e-c3ec-cec0-87bde9ff8577@ispn.net>
References: <CAA3RQS8eqG-x6eMg8D6SnbnV=G3eDjezHGDUmrP=9N-GJ=wprg@mail.gmail.com>
 <1468848371_93759@surgemail.mnsi.net>
 <c39b3f31-6a6e-c3ec-cec0-87bde9ff8577@ispn.net>
Message-ID: <1588971553.2606.1468853835713.JavaMail.mhammett@ThunderFuck>

Several of my WISP colleagues have noticed this behavior (CDN sending way more traffic than the customer's pipe can handle) from (I believe) multiple CDNs. Not sure if it is intention on behalf of the CDN or an error, but it has been on-going for several months if not years. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


----- Original Message -----

From: "Blake Hudson" <blake at ispn.net> 
To: nanog at nanog.org 
Sent: Monday, July 18, 2016 8:49:21 AM 
Subject: Re: akamai abnormal spike 

We noticed that on the 12th-14th we had multiple subscribers on ~5Mbps 
subscription rates that were being sent ~50Mbps of data sourced from TCP 
port 80 (apparently HTTP) from Limelight Networks' servers. The data did 
appear to be user requested, still not sure why TCP didn't throttle the 
data rate appropriately. The 50Mbps was distributed across multiple LLNW 
servers. Makes me wonder if the customer was requesting one batch of 
data and multiple servers were responding. 

The issue cleared up on its own and I never was able to perform a full 
packet capture to investigate. I have not noticed the same behavior from 
Akamai servers. 

Clayton Zekelman wrote on 7/18/2016 8:26 AM: 
> 
> 
> We noticed on the 12th and 13th there was a significant up tick in 
> traffic served from our Akamai servers as well. 
> 
> 
> At 05:37 PM 13/07/2016, eric c wrote: 
>> Good afternoon, 
>> 
>> Has anyone notice any abnormal spike in Akamai trafic in the last 24-48 
>> hours compared to other days. I know it was black tuesday yesterday but 
>> traffic from last month didn't even come close to what we saw from 
>> Akamai. 
>> 
>> We have some caching servers and even notice a spike to them as well. 
>> 
>> Limelight even showed up on our network. 
>> 
>> thanks 
>> eric 
> 



From nick at flhsi.com  Mon Jul 18 15:30:19 2016
From: nick at flhsi.com (Nick Olsen)
Date: Mon, 18 Jul 2016 11:30:19 -0400
Subject: Google NOC Contact?
Message-ID: <365b658cca7a4dd7a74804584efca7d8@flhsi.com>

Wondering if anyone from the Google NOC is on-list.
  
 Having issues reaching your authoritative name servers that appear to be 
anycasted on Level3's network.
  
 Traffic to your name servers 216.239.32.10, 216.239.34.10, 216.239.36.10 
and 216.239.38.10 dies in what appears to be Legacy Global Crossing 
territory.
  
 216.239.38.10 (ns4.google.com)
  Host                                                      Loss%   Snt   
Last   Avg  Best  Wrst StDev
 1. eth-vl0504-far1.coco-vr.flhsi.com                       0.0%   320    
0.2   0.2   0.1   0.8   0.0
 2. eth-ge0007-car1.coco-vr.flhsi.com                       0.0%   320    
0.2   0.2   0.2   0.6   0.0
 3. eth-sf0004-bar1.coco-vr.flhsi.com                       0.0%   320    
0.2   0.2   0.2   6.5   0.3
 4. 66-194-200-17.static.twtelecom.net                      0.0%   320    
5.2   4.3   4.1  11.1   0.5
 5. ae19-20G.scr4.MIA1.gblx.net                             0.0%   320   
19.9  20.6  19.8  64.4   4.2
 6. ???
  
   
  flhsi at flhsi01:~$ dig google.com @216.239.38.10
 ; <<>> DiG 9.8.1-P1 <<>> google.com @216.239.38.10
;; global options: +cmd
;; connection timed out; no servers could be reached

  
 Nick Olsen
 Sr. Network Engineer
 Florida High Speed Internet
 (321) 205-1100 x106

  

  
  



From hannigan at gmail.com  Mon Jul 18 15:34:34 2016
From: hannigan at gmail.com (Martin Hannigan)
Date: Mon, 18 Jul 2016 11:34:34 -0400
Subject: akamai abnormal spike
In-Reply-To: <CAA3RQS8eqG-x6eMg8D6SnbnV=G3eDjezHGDUmrP=9N-GJ=wprg@mail.gmail.com>
References: <CAA3RQS8eqG-x6eMg8D6SnbnV=G3eDjezHGDUmrP=9N-GJ=wprg@mail.gmail.com>
Message-ID: <CAMDXq5N+doi0vWQpsW4cow+b5p+VB6_pkNK283Z0E05w87D=4Q@mail.gmail.com>

On Wed, Jul 13, 2016 at 5:37 PM, eric c <xcellula at gmail.com> wrote:
> Good afternoon,
>
> Has anyone notice any abnormal spike in Akamai trafic in the last 24-48
> hours compared to other days. I know it was black tuesday yesterday but
> traffic from last month didn't even come close to what we saw from Akamai.
>
> We have some caching servers and even notice a spike to them as well.


Hi Eric,

There were two major software updates that spanned Tuesday and
Wednesday which are responsible for the increase you saw.

Best,

Martin Hannigan / AS 20940 / AS 32787

From morrowc.lists at gmail.com  Mon Jul 18 16:01:57 2016
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 18 Jul 2016 17:01:57 +0100
Subject: Google NOC Contact?
In-Reply-To: <365b658cca7a4dd7a74804584efca7d8@flhsi.com>
References: <365b658cca7a4dd7a74804584efca7d8@flhsi.com>
Message-ID: <CAL9jLaYoRtXiB8sS-sX3jL49S9vp3UF7VDzy6uMFqmnAdg1vtw@mail.gmail.com>

replying offlist (I'm sure I'm not the only one)

On Mon, Jul 18, 2016 at 4:30 PM, Nick Olsen <nick at flhsi.com> wrote:

> Wondering if anyone from the Google NOC is on-list.
>
>  Having issues reaching your authoritative name servers that appear to be
> anycasted on Level3's network.
>
>  Traffic to your name servers 216.239.32.10, 216.239.34.10, 216.239.36.10
> and 216.239.38.10 dies in what appears to be Legacy Global Crossing
> territory.
>
>  216.239.38.10 (ns4.google.com)
>   Host                                                      Loss%   Snt
> Last   Avg  Best  Wrst StDev
>  1. eth-vl0504-far1.coco-vr.flhsi.com                       0.0%   320
> 0.2   0.2   0.1   0.8   0.0
>  2. eth-ge0007-car1.coco-vr.flhsi.com                       0.0%   320
> 0.2   0.2   0.2   0.6   0.0
>  3. eth-sf0004-bar1.coco-vr.flhsi.com                       0.0%   320
> 0.2   0.2   0.2   6.5   0.3
>  4. 66-194-200-17.static.twtelecom.net                      0.0%   320
> 5.2   4.3   4.1  11.1   0.5
>  5. ae19-20G.scr4.MIA1.gblx.net                             0.0%   320
> 19.9  20.6  19.8  64.4   4.2
>  6. ???
>
>
>   flhsi at flhsi01:~$ dig google.com @216.239.38.10
>  ; <<>> DiG 9.8.1-P1 <<>> google.com @216.239.38.10
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
>
>
>  Nick Olsen
>  Sr. Network Engineer
>  Florida High Speed Internet
>  (321) 205-1100 x106
>
>
>
>
>
>
>
>

From eric.kuhnke at gmail.com  Mon Jul 18 16:12:21 2016
From: eric.kuhnke at gmail.com (Eric Kuhnke)
Date: Mon, 18 Jul 2016 09:12:21 -0700
Subject: Best practices for telcoflex -48VDC cabling & other power OSI layer 1
Message-ID: <CAB69EHiwB=z0kh1nb4wxRGjvO15ad9RU_pZ2FCQ8inuRDOciEQ@mail.gmail.com>

Hey all,


I'm looking for a document or set of photos/presentation on best practices
for telcoflex/-48VDC power cabling installation. Labeling, routing,
organization and termination, etc. Or a recommendation on a printed book
that covers this topic.

Not necessarily fully oldschool "we're going to teach all the technicians
how to do the kansas city stitch" stuff, but the sort of thing that's
applicable in a modern colo/IP network environment.

From SNaslund at medline.com  Mon Jul 18 16:18:29 2016
From: SNaslund at medline.com (Naslund, Steve)
Date: Mon, 18 Jul 2016 16:18:29 +0000
Subject: Best practices for telcoflex -48VDC cabling & other power OSI
 layer 1
In-Reply-To: <CAB69EHiwB=z0kh1nb4wxRGjvO15ad9RU_pZ2FCQ8inuRDOciEQ@mail.gmail.com>
References: <CAB69EHiwB=z0kh1nb4wxRGjvO15ad9RU_pZ2FCQ8inuRDOciEQ@mail.gmail.com>
Message-ID: <9578293AE169674F9A048B2BC9A081B401E664FF13@MUNPRDMBXA1.medline.com>

Not sure where to find it exactly but the Bellcore power wiring standard is what is used for central office installations.  I think if you google Bellcore standard you will find what you are looking for.

Steven Naslund
Chicago IL

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Kuhnke
Sent: Monday, July 18, 2016 11:12 AM
To: nanog at nanog.org
Subject: Best practices for telcoflex -48VDC cabling & other power OSI layer 1

Hey all,


I'm looking for a document or set of photos/presentation on best practices for telcoflex/-48VDC power cabling installation. Labeling, routing, organization and termination, etc. Or a recommendation on a printed book that covers this topic.

Not necessarily fully oldschool "we're going to teach all the technicians how to do the kansas city stitch" stuff, but the sort of thing that's applicable in a modern colo/IP network environment.

From Quincy.Marshall at reged.com  Mon Jul 18 16:02:34 2016
From: Quincy.Marshall at reged.com (Marshall, Quincy)
Date: Mon, 18 Jul 2016 16:02:34 +0000
Subject: Latency & Packet Loss Level 3 to Russia
Message-ID: <3438B611A2B2C04495EF0E1B25729C4699D48E@mbx032-e1-va-7.exch032.serverpod.net>

Began investigating packet loss and latency to Russia earlier this morning. Issue appears to be hit or miss and affecting more than others certain traffic types (lower priority?).

Are there any Level 3 engineer who can provide details/assistance?
Anyone seeing anything similar?

Host			Nr	Loss %	Sent	Recv	Best	Avrg	Worst	Last
81.23.112.129		1	0	55	55	1	5	44	2
81.23.112.33		2	0	55	55	2	7	47	5
93.174.247.242		3	0	55	55	2	7	47	3
93.174.247.241		4	0	55	55	2	15	194	3
213.242.122.101	5	2	51	50	9	13	60	10
4.69.140.226		6	5	47	45	165	260	659	223
4.69.140.226		7	5	47	45	165	264	665	213
166.90.118.222		8	0	55	55	166	171	213	171
209.59.28.22		9	0	55	55	166	171	216	171

Report is from earlier this AM... seeing ~15% at the trouble point now.

Q. Marshall | RegEd | phone: 919.653.5431? | ITS-771 | quincy.marshall at reged.com
---------------------------------------------------------------------------------------
 This email has been scanned for email related threats and delivered safely by Mimecast.
 For more information please visit http://www.mimecast.com
---------------------------------------------------------------------------------------

From Daniel.Jameson at tdstelecom.com  Mon Jul 18 16:27:46 2016
From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel)
Date: Mon, 18 Jul 2016 16:27:46 +0000
Subject: Best practices for telcoflex -48VDC cabling & other power OSI
 layer 1
In-Reply-To: <9578293AE169674F9A048B2BC9A081B401E664FF13@MUNPRDMBXA1.medline.com>
References: <CAB69EHiwB=z0kh1nb4wxRGjvO15ad9RU_pZ2FCQ8inuRDOciEQ@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E664FF13@MUNPRDMBXA1.medline.com>
Message-ID: <E0D94351C6498041ABE98D73FB9F30EA139DA362@cmailbox5>

ATT TP76300, section 4 goes over installation best practices,  although it doesn't cover Engineering guidelines.  It's adapted from the Telcordia  GR - 1275 standard,  little easier to read.  Is there a specific question you're looking to answer?

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Naslund, Steve
Sent: Monday, July 18, 2016 10:18 AM
To: nanog at nanog.org
Subject: RE: Best practices for telcoflex -48VDC cabling & other power OSI layer 1

Not sure where to find it exactly but the Bellcore power wiring standard is what is used for central office installations.  I think if you google Bellcore standard you will find what you are looking for.

Steven Naslund
Chicago IL

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Kuhnke
Sent: Monday, July 18, 2016 11:12 AM
To: nanog at nanog.org
Subject: Best practices for telcoflex -48VDC cabling & other power OSI layer 1

Hey all,


I'm looking for a document or set of photos/presentation on best practices for telcoflex/-48VDC power cabling installation. Labeling, routing, organization and termination, etc. Or a recommendation on a printed book that covers this topic.

Not necessarily fully oldschool "we're going to teach all the technicians how to do the kansas city stitch" stuff, but the sort of thing that's applicable in a modern colo/IP network environment.

From eric.kuhnke at gmail.com  Mon Jul 18 16:57:19 2016
From: eric.kuhnke at gmail.com (Eric Kuhnke)
Date: Mon, 18 Jul 2016 09:57:19 -0700
Subject: Best practices for telcoflex -48VDC cabling & other power OSI
 layer 1
In-Reply-To: <E0D94351C6498041ABE98D73FB9F30EA139DA362@cmailbox5>
References: <CAB69EHiwB=z0kh1nb4wxRGjvO15ad9RU_pZ2FCQ8inuRDOciEQ@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E664FF13@MUNPRDMBXA1.medline.com>
 <E0D94351C6498041ABE98D73FB9F30EA139DA362@cmailbox5>
Message-ID: <CAB69EHgDuvX+xRGdNdF5KjJWTB_wBjomuDYVaqRHeUCQqHWdjQ@mail.gmail.com>

Pretty much this, hoping somebody out there might have developed
photographic training materials based on the DC cabling & installation
section of TP76300 with illustrated "Do it like this, don't do this"
examples. Or would be willing to share photographic examples of their own
work which is done in an exemplary way.




On Mon, Jul 18, 2016 at 9:27 AM, Jameson, Daniel <
Daniel.Jameson at tdstelecom.com> wrote:

> ATT TP76300, section 4 goes over installation best practices,  although it
> doesn't cover Engineering guidelines.  It's adapted from the Telcordia  GR
> - 1275 standard,  little easier to read.  Is there a specific question
> you're looking to answer?
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Naslund, Steve
> Sent: Monday, July 18, 2016 10:18 AM
> To: nanog at nanog.org
> Subject: RE: Best practices for telcoflex -48VDC cabling & other power OSI
> layer 1
>
> Not sure where to find it exactly but the Bellcore power wiring standard
> is what is used for central office installations.  I think if you google
> Bellcore standard you will find what you are looking for.
>
> Steven Naslund
> Chicago IL
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Kuhnke
> Sent: Monday, July 18, 2016 11:12 AM
> To: nanog at nanog.org
> Subject: Best practices for telcoflex -48VDC cabling & other power OSI
> layer 1
>
> Hey all,
>
>
> I'm looking for a document or set of photos/presentation on best practices
> for telcoflex/-48VDC power cabling installation. Labeling, routing,
> organization and termination, etc. Or a recommendation on a printed book
> that covers this topic.
>
> Not necessarily fully oldschool "we're going to teach all the technicians
> how to do the kansas city stitch" stuff, but the sort of thing that's
> applicable in a modern colo/IP network environment.
>

From jflowers at atlassian.com  Mon Jul 18 17:24:46 2016
From: jflowers at atlassian.com (Joe Flowers)
Date: Mon, 18 Jul 2016 10:24:46 -0700
Subject: Latency & Packet Loss Level 3 to Russia
In-Reply-To: <3438B611A2B2C04495EF0E1B25729C4699D48E@mbx032-e1-va-7.exch032.serverpod.net>
References: <3438B611A2B2C04495EF0E1B25729C4699D48E@mbx032-e1-va-7.exch032.serverpod.net>
Message-ID: <CAJwDsw_H8N6bCxzvXvqa3m0VVojELc2X5bj8poq-xWe3b__B8A@mail.gmail.com>

Things look ok from here:

 2  216.182.224.138 (216.182.224.138)  50.787 ms  50.775 ms  50.773 ms
 3  100.66.8.180 (100.66.8.180)  14.457 ms 100.66.8.190 (100.66.8.190)
 14.991 ms 100.66.8.170 (100.66.8.170)  14.833 ms
 4  100.66.11.160 (100.66.11.160)  16.969 ms 100.66.11.192
(100.66.11.192)  33.043 ms 100.66.11.134 (100.66.11.134)  20.515 ms
 5  100.66.6.47 (100.66.6.47)  20.337 ms 100.66.6.203 (100.66.6.203)
18.458 ms 100.66.6.227 (100.66.6.227)  17.512 ms
 6  100.66.4.73 (100.66.4.73)  29.798 ms 100.66.4.59 (100.66.4.59)
18.320 ms 100.66.4.201 (100.66.4.201)  13.686 ms
 7  100.65.11.193 (100.65.11.193)  0.586 ms 100.65.9.161
(100.65.9.161)  0.613 ms 100.65.10.161 (100.65.10.161)  0.706 ms
 8  205.251.244.222 (205.251.244.222)  1.514 ms 205.251.244.220
(205.251.244.220)  1.513 ms 205.251.245.237 (205.251.245.237)  1.554
ms
 9  54.239.110.26 (54.239.110.26)  19.964 ms 54.239.111.92
(54.239.111.92)  24.399 ms 54.239.111.94 (54.239.111.94)  19.988 ms
10  54.239.109.221 (54.239.109.221)  1.714 ms 54.239.109.151
(54.239.109.151)  1.630 ms 54.239.110.41 (54.239.110.41)  1.557 ms
11  * * lag-105.ear2.Washington12.Level3.net (4.16.74.17)  2.023 ms
12  2-1-3-332.bear1.Russia2.Level3.net (213.242.122.101)  138.540 ms
138.255 ms  138.535 ms

?

On Mon, Jul 18, 2016 at 9:02 AM, Marshall, Quincy <Quincy.Marshall at reged.com
> wrote:

> Began investigating packet loss and latency to Russia earlier this
> morning. Issue appears to be hit or miss and affecting more than others
> certain traffic types (lower priority?).
>
> Are there any Level 3 engineer who can provide details/assistance?
> Anyone seeing anything similar?
>
> Host                    Nr      Loss %  Sent    Recv    Best    Avrg
> Worst   Last
> 81.23.112.129                1       0       55      55      1       5
>    44      2
> 81.23.112.33            2       0       55      55      2       7
>  47      5
> 93.174.247.242          3       0       55      55      2       7
>  47      3
> 93.174.247.241          4       0       55      55      2       15
> 194     3
> 213.242.122.101 5       2       51      50      9       13      60      10
> 4.69.140.226            6       5       47      45      165     260
>  659     223
> 4.69.140.226            7       5       47      45      165     264
>  665     213
> 166.90.118.222          8       0       55      55      166     171
>  213     171
> 209.59.28.22            9       0       55      55      166     171
>  216     171
>
> Report is from earlier this AM... seeing ~15% at the trouble point now.
>
> Q. Marshall | RegEd | phone: 919.653.5431  | ITS-771 |
> quincy.marshall at reged.com
>
> ---------------------------------------------------------------------------------------
>  This email has been scanned for email related threats and delivered
> safely by Mimecast.
>  For more information please visit http://www.mimecast.com
>
> ---------------------------------------------------------------------------------------
>



-- 
Joe Flowers

Senior Systems Engineer

512.666.0611

jflowers at atlassian.com


<http://atlassian.com/careers>

From jason at rice.edu  Mon Jul 18 17:38:28 2016
From: jason at rice.edu (Jason Bothe)
Date: Mon, 18 Jul 2016 12:38:28 -0500
Subject: Best practices for telcoflex -48VDC cabling & other power OSI
 layer 1
In-Reply-To: <CAB69EHgDuvX+xRGdNdF5KjJWTB_wBjomuDYVaqRHeUCQqHWdjQ@mail.gmail.com>
References: <CAB69EHiwB=z0kh1nb4wxRGjvO15ad9RU_pZ2FCQ8inuRDOciEQ@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E664FF13@MUNPRDMBXA1.medline.com>
 <E0D94351C6498041ABE98D73FB9F30EA139DA362@cmailbox5>
 <CAB69EHgDuvX+xRGdNdF5KjJWTB_wBjomuDYVaqRHeUCQqHWdjQ@mail.gmail.com>
Message-ID: <80DE3601-5768-4FC6-AC73-9E41A5831CDF@rice.edu>

I'm happy to help. Feel free to contact me offline. 

Jason Bothe, Manager of Networking
Rice University
o  +1 713 348 5500
m +1 713 703 3552

Sent from mobile

> On Jul 18, 2016, at 11:57, Eric Kuhnke <eric.kuhnke at gmail.com> wrote:
> 
> Pretty much this, hoping somebody out there might have developed
> photographic training materials based on the DC cabling & installation
> section of TP76300 with illustrated "Do it like this, don't do this"
> examples. Or would be willing to share photographic examples of their own
> work which is done in an exemplary way.
> 
> 
> 
> 
> On Mon, Jul 18, 2016 at 9:27 AM, Jameson, Daniel <
> Daniel.Jameson at tdstelecom.com> wrote:
> 
>> ATT TP76300, section 4 goes over installation best practices,  although it
>> doesn't cover Engineering guidelines.  It's adapted from the Telcordia  GR
>> - 1275 standard,  little easier to read.  Is there a specific question
>> you're looking to answer?
>> 
>> -----Original Message-----
>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Naslund, Steve
>> Sent: Monday, July 18, 2016 10:18 AM
>> To: nanog at nanog.org
>> Subject: RE: Best practices for telcoflex -48VDC cabling & other power OSI
>> layer 1
>> 
>> Not sure where to find it exactly but the Bellcore power wiring standard
>> is what is used for central office installations.  I think if you google
>> Bellcore standard you will find what you are looking for.
>> 
>> Steven Naslund
>> Chicago IL
>> 
>> -----Original Message-----
>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Kuhnke
>> Sent: Monday, July 18, 2016 11:12 AM
>> To: nanog at nanog.org
>> Subject: Best practices for telcoflex -48VDC cabling & other power OSI
>> layer 1
>> 
>> Hey all,
>> 
>> 
>> I'm looking for a document or set of photos/presentation on best practices
>> for telcoflex/-48VDC power cabling installation. Labeling, routing,
>> organization and termination, etc. Or a recommendation on a printed book
>> that covers this topic.
>> 
>> Not necessarily fully oldschool "we're going to teach all the technicians
>> how to do the kansas city stitch" stuff, but the sort of thing that's
>> applicable in a modern colo/IP network environment.
> 

From blanderson3 at alaska.edu  Mon Jul 18 21:16:53 2016
From: blanderson3 at alaska.edu (Britton Anderson)
Date: Mon, 18 Jul 2016 13:16:53 -0800
Subject: University of Alaska AS7774 NOC?
In-Reply-To: <CABNB40W7AWmC6eQJN0AArjGsZZ=cS8R1-LGAOMqtjFwsbZHJBQ@mail.gmail.com>
References: <CABNB40VhbBZy-rEuhkE9Tr+Dn=7J0LK9ESf-qvMk4cZS-r=4Xw@mail.gmail.com>
 <CABNB40W7AWmC6eQJN0AArjGsZZ=cS8R1-LGAOMqtjFwsbZHJBQ@mail.gmail.com>
Message-ID: <CAHm2qBtkhu5S9aNyMfdQHJRE_xbQ1v9Hc7trKwKKjHe9YfSY3A@mail.gmail.com>

We responded to Jeremy off-list, which turned out to be a different issue,
but its worth noting. We swung AS7774 over to a different provider
yesterday morning at our three peering points. We spot checked several
route views and looking glass servers for AS paths around the globe and
didn't find any issues, but if folks wouldn't mind running traces to
137.229.0.0/16 & 199.165.64.0/18 and pinging me with any anomalies, that
would be great.

Thanks,
Britton


Britton Anderson <blanderson3 at alaska.edu> |  Senior Network Communications
Specialist |  University of Alaska <http://www.alaska.edu/oit> |
907.450.8250

On Sun, Jul 17, 2016 at 8:19 PM, Jeremy Austin <jhaustin at gmail.com> wrote:

> On Sun, Jul 17, 2016 at 3:50 PM, Jeremy Austin <jhaustin at gmail.com> wrote:
>
> > If there's anyone on call at network operations for the University of
> > Alaska, AS7774, please contact me or ACS NOC, who have an open trouble
> > ticket.
> >
> > We appear to be having BPG reachability issues on your ACS peering.
> >
>
> I want to extend thanks to the folks at University of Alaska, several of
> whom contacted me immediately.
>
> The issue turned out to be with ACS (AS7782), whose network engineers are
> also on NANOG and called me almost right away, even the one on leave whom
> the NOC couldn't reach.
>
> That's what I call service. Thanks again, you deserve a shout out.
>
>
> --
> Jeremy Austin
>
> (907) 895-2311
> (907) 803-5422
> jhaustin at gmail.com
>
> Heritage NetWorks
> Whitestone Power & Communications
> Vertical Broadband, LLC
>
> Schedule a meeting: http://doodle.com/jermudgeon
>

From eric.kuhnke at gmail.com  Mon Jul 18 22:52:03 2016
From: eric.kuhnke at gmail.com (Eric Kuhnke)
Date: Mon, 18 Jul 2016 15:52:03 -0700
Subject: [AFMUG] Mimosa B11 Tx power at varying modulations
In-Reply-To: <etPan.578d4dd5.1ce1fc3.13727@mimosa.co>
References: <01000155efb3aa76-8a45d0a3-86d0-4bb4-a34d-76db5127d961-000000@email.amazonses.com>
 <etPan.578d4dd5.1ce1fc3.13727@mimosa.co>
Message-ID: <CAB69EHg-xJh1NZdU1FvKGH9hQ3WutPJpALfeTe15Lqn4us6QWQ@mail.gmail.com>

I found this as well, which is very helpful. Wish more radio manufacturers
were as clear about this in the spec sheet:

http://backhaul.help.mimosa.co/backhaul-faq-maximum-tx-power-details

In one channel, two chains, it's +24, if using two channels and four chains
+21 Tx power. Then it's possible to manually do the link budget and path
loss calculations based on that (or plug Tx power dBm + dBi gain for
preliminary PTP link calculations into something like Radio Mobile).


On Mon, Jul 18, 2016 at 2:44 PM, Jaime Fink <jaime at mimosa.co> wrote:

> Eric, I think you?re more looking for SNR required for each modulation
> coding rate, which care listed here:
>
> http://backhaul.help.mimosa.co/backhaul-faq-snr-mcs
>
> Cheers,
>
> Jaime Fink ? Mimosa <http://www.mimosa.co> ? CPO & Co-Founder
>
> On July 15, 2016 at 10:56:20 AM, Eric Kuhnke (eric.kuhnke at gmail.com)
> wrote:
>
> Trying to manually do a link budget/path loss/rain fade calculation for a
> possible long B11 link...
>
> Does Mimosa have a table of Tx power vs. modulation level published
> somewhere? The datasheet just says +27 Tx power, which I am guessing is its
> Tx power at QPSK modulation or something.
>
> I am doubtful it's +27 at 256QAM with a low-overhead-percentage code rate.
>
> https://www.mimosa.co/uploads/docs/Mimosa-B11-Datasheet.pdf
>
> Is it +17, +18 or +19 Tx at 256QAM?
>
>
>

From eric.kuhnke at gmail.com  Mon Jul 18 22:56:03 2016
From: eric.kuhnke at gmail.com (Eric Kuhnke)
Date: Mon, 18 Jul 2016 15:56:03 -0700
Subject: [AFMUG] Mimosa B11 Tx power at varying modulations
In-Reply-To: <CAB69EHg-xJh1NZdU1FvKGH9hQ3WutPJpALfeTe15Lqn4us6QWQ@mail.gmail.com>
References: <01000155efb3aa76-8a45d0a3-86d0-4bb4-a34d-76db5127d961-000000@email.amazonses.com>
 <etPan.578d4dd5.1ce1fc3.13727@mimosa.co>
 <CAB69EHg-xJh1NZdU1FvKGH9hQ3WutPJpALfeTe15Lqn4us6QWQ@mail.gmail.com>
Message-ID: <CAB69EHiQ71GTJK5t72J=kNkGViag7ExUKH-Y9J8ksjWrwGgqbQ@mail.gmail.com>

Apologies for that, it went to the wrong list. While the OSI layer 1
characteristics of new PTP microwave bridges are undoubtedly fascinating,
such discussion may be a little too fine grained for network operational
lists.


On Mon, Jul 18, 2016 at 3:52 PM, Eric Kuhnke <eric.kuhnke at gmail.com> wrote:

> I found this as well, which is very helpful. Wish more radio manufacturers
> were as clear about this in the spec sheet:
>
> http://backhaul.help.mimosa.co/backhaul-faq-maximum-tx-power-details
>
> In one channel, two chains, it's +24, if using two channels and four
> chains +21 Tx power. Then it's possible to manually do the link budget and
> path loss calculations based on that (or plug Tx power dBm + dBi gain for
> preliminary PTP link calculations into something like Radio Mobile).
>
>
> On Mon, Jul 18, 2016 at 2:44 PM, Jaime Fink <jaime at mimosa.co> wrote:
>
>> Eric, I think you?re more looking for SNR required for each modulation
>> coding rate, which care listed here:
>>
>> http://backhaul.help.mimosa.co/backhaul-faq-snr-mcs
>>
>> Cheers,
>>
>> Jaime Fink ? Mimosa <http://www.mimosa.co> ? CPO & Co-Founder
>>
>> On July 15, 2016 at 10:56:20 AM, Eric Kuhnke (eric.kuhnke at gmail.com)
>> wrote:
>>
>> Trying to manually do a link budget/path loss/rain fade calculation for a
>> possible long B11 link...
>>
>> Does Mimosa have a table of Tx power vs. modulation level published
>> somewhere? The datasheet just says +27 Tx power, which I am guessing is its
>> Tx power at QPSK modulation or something.
>>
>> I am doubtful it's +27 at 256QAM with a low-overhead-percentage code rate.
>>
>> https://www.mimosa.co/uploads/docs/Mimosa-B11-Datasheet.pdf
>>
>> Is it +17, +18 or +19 Tx at 256QAM?
>>
>>
>>
>

From joelja at bogus.com  Tue Jul 19 07:16:42 2016
From: joelja at bogus.com (joel jaeggli)
Date: Tue, 19 Jul 2016 09:16:42 +0200
Subject: akamai abnormal spike
In-Reply-To: <1588971553.2606.1468853835713.JavaMail.mhammett@ThunderFuck>
References: <CAA3RQS8eqG-x6eMg8D6SnbnV=G3eDjezHGDUmrP=9N-GJ=wprg@mail.gmail.com>
 <1468848371_93759@surgemail.mnsi.net>
 <c39b3f31-6a6e-c3ec-cec0-87bde9ff8577@ispn.net>
 <1588971553.2606.1468853835713.JavaMail.mhammett@ThunderFuck>
Message-ID: <4526dd00-30be-0374-a8f1-ab5e189bf080@bogus.com>

On 7/18/16 4:57 PM, Mike Hammett wrote:
> Several of my WISP colleagues have noticed this behavior (CDN sending
> way more traffic than the customer's pipe can handle) from (I
> believe) multiple CDNs. Not sure if it is intention on behalf of the
> CDN or an error, but it has been on-going for several months if not
> years.

It's not a healthy tcp flow if the number of packets associated with the
flow stays well in excess of the link capacity for a while... if you
have recourse to to l4 header flags you might find that it was an ack
flood or repeated retramission of the same PDUs. Either way someones
state machine has a bug.

joel

> 
> 
> 
> ----- Mike Hammett Intelligent Computing Solutions 
> http://www.ics-il.com
> 
> 
> 
> Midwest Internet Exchange http://www.midwest-ix.com
> 
> 
> ----- Original Message -----
> 
> From: "Blake Hudson" <blake at ispn.net> To: nanog at nanog.org Sent:
> Monday, July 18, 2016 8:49:21 AM Subject: Re: akamai abnormal spike
> 
> We noticed that on the 12th-14th we had multiple subscribers on
> ~5Mbps subscription rates that were being sent ~50Mbps of data
> sourced from TCP port 80 (apparently HTTP) from Limelight Networks'
> servers. The data did appear to be user requested, still not sure why
> TCP didn't throttle the data rate appropriately. The 50Mbps was
> distributed across multiple LLNW servers. Makes me wonder if the
> customer was requesting one batch of data and multiple servers were
> responding.
> 
> The issue cleared up on its own and I never was able to perform a
> full packet capture to investigate. I have not noticed the same
> behavior from Akamai servers.
> 
> Clayton Zekelman wrote on 7/18/2016 8:26 AM:
>> 
>> 
>> We noticed on the 12th and 13th there was a significant up tick in
>>  traffic served from our Akamai servers as well.
>> 
>> 
>> At 05:37 PM 13/07/2016, eric c wrote:
>>> Good afternoon,
>>> 
>>> Has anyone notice any abnormal spike in Akamai trafic in the last
>>> 24-48 hours compared to other days. I know it was black tuesday
>>> yesterday but traffic from last month didn't even come close to
>>> what we saw from Akamai.
>>> 
>>> We have some caching servers and even notice a spike to them as
>>> well.
>>> 
>>> Limelight even showed up on our network.
>>> 
>>> thanks eric
>> 
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160719/3a1d467a/attachment.pgp>

From hannigan at gmail.com  Tue Jul 19 15:24:06 2016
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 19 Jul 2016 11:24:06 -0400
Subject: [apops] BGP Update Report
In-Reply-To: <201607152200.u6FM07rQ051930@wattle.apnic.net>
References: <201607152200.u6FM07rQ051930@wattle.apnic.net>
Message-ID: <CAMDXq5Pvgic2CBVKwiB2hWEvUYZ7RAqqnoRMn4uCa=issy274w@mail.gmail.com>

On Fri, Jul 15, 2016 at 6:00 PM,  <cidr-report at potaroo.net> wrote:

> 15 - 104.111.200.0/21   6948  0.2%   AS16625 -- AKAMAI-AS - Akamai Technologies, Inc., US
>                                      AS20940 -- AKAMAI-ASN1 , US


This has been addressed. Appreciated Potaroo Team.


Best,

-M<

From jra at baylink.com  Tue Jul 19 23:55:40 2016
From: jra at baylink.com (Jay R. Ashworth)
Date: Tue, 19 Jul 2016 23:55:40 +0000 (UTC)
Subject: Fwd: [ PRIVACY Forum ] Critical bug threatens to bite mobile phones
 and networks
In-Reply-To: <mailman.1597.1468969969.1498.privacy@vortex.com>
References: <mailman.1597.1468969969.1498.privacy@vortex.com>
Message-ID: <1968751399.18964.1468972540060.JavaMail.zimbra@baylink.com>

Heap overflow bug in either a widely used ASN.1 library from Objective Systems,
apparently popular with cell-radio industry people.  Not sure if this will 
leak over into NANOG land -- but neither are you, and that's most of my point.

DO *you* know if this library is used in your routers?  Can you find out?

How easily and quickly?

Cheers,
-- jra

----- Forwarded Message -----
> From: "PRIVACY Forum mailing list" <privacy at vortex.com>
> To: privacy-list at vortex.com
> Sent: Tuesday, July 19, 2016 7:12:47 PM
> Subject: [ PRIVACY Forum ] Critical bug threatens to bite mobile phones and networks

> Critical bug threatens to bite mobile phones and networks
> 
> http://arstechnica.com/security/2016/07/software-flaw-puts-mobile-phones-and-networks-at-risk-of-complete-takeover/
> 
>  	A newly disclosed vulnerability could allow attackers to seize
>	control of mobile phones and key parts of the world's
>	telecommunications infrastructure and make it possible to
>	eavesdrop or disrupt entire networks, security experts warned
>	Tuesday.  The bug resides in a code library used in a wide
>	range of telecommunication products, including radios in cell
>	towers, routers, and switches, as well as the baseband chips
>	in individual phones. Although exploiting the heap overflow
>	vulnerability would require great skill and resources,
>	attackers who managed to succeed would have the ability to
>	execute malicious code on virtually all of those devices. The
>	code library was developed by Pennsylvania-based Objective
>	Systems and is used to implement a telephony standard known as
>	ASN.1, short for Abstract Syntax Notation One.
> 
> - - -
> 
> --Lauren--
> Lauren Weinstein (lauren at vortex.com): http://www.vortex.com/lauren
> Founder:
> - Network Neutrality Squad: http://www.nnsquad.org
> - PRIVACY Forum: http://www.vortex.com/privacy-info
> Co-Founder: People For Internet Responsibility: http://www.pfir.org/pfir-info
> Member: ACM Committee on Computers and Public Policy
> Lauren's Blog: http://lauren.vortex.com
> Google+: http://google.com/+LaurenWeinstein
> Twitter: http://twitter.com/laurenweinstein
> Tel: +1 (818) 225-2800 / Skype: vortex.com
> I have consulted to Google, but I am not currently
> doing so -- my opinions expressed here are mine alone.
> _______________________________________________
> privacy mailing list
> http://lists.vortex.com/mailman/listinfo/privacy

-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274

From mike at mtcc.com  Wed Jul 20 00:13:50 2016
From: mike at mtcc.com (Michael Thomas)
Date: Tue, 19 Jul 2016 17:13:50 -0700
Subject: Fwd: [ PRIVACY Forum ] Critical bug threatens to bite mobile
 phones and networks
In-Reply-To: <1968751399.18964.1468972540060.JavaMail.zimbra@baylink.com>
References: <mailman.1597.1468969969.1498.privacy@vortex.com>
 <1968751399.18964.1468972540060.JavaMail.zimbra@baylink.com>
Message-ID: <6a224150-4778-0a5e-b8ce-6af887ae1b25@mtcc.com>

On 07/19/2016 04:55 PM, Jay R. Ashworth wrote:
> Heap overflow bug in either a widely used ASN.1 library from Objective Systems,
> apparently popular with cell-radio industry people.  Not sure if this will
> leak over into NANOG land -- but neither are you, and that's most of my point.
>
> DO *you* know if this library is used in your routers?  Can you find out?
>
> How easily and quickly?

Friends don't let friends use asn.1

Mike


From saper at saper.info  Wed Jul 20 00:16:28 2016
From: saper at saper.info (Marcin Cieslak)
Date: Wed, 20 Jul 2016 00:16:28 +0000
Subject: Fwd: [ PRIVACY Forum ] Critical bug threatens to bite mobile
 phones and networks
In-Reply-To: <1968751399.18964.1468972540060.JavaMail.zimbra@baylink.com>
References: <mailman.1597.1468969969.1498.privacy@vortex.com>
 <1968751399.18964.1468972540060.JavaMail.zimbra@baylink.com>
Message-ID: <alpine.BSF.2.20.1607200010260.96411@z.fncre.vasb>

On Tue, 19 Jul 2016, Jay R. Ashworth wrote:

> Heap overflow bug in either a widely used ASN.1 library from Objective Systems,
> apparently popular with cell-radio industry people.  Not sure if this will 
> leak over into NANOG land -- but neither are you, and that's most of my point.
> 
> DO *you* know if this library is used in your routers?  Can you find out?
> 
> How easily and quickly?

CERT/CC has published a list of contacted vendors:

http://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=790839&SearchOrder=4

>From the timeline:

https://github.com/programa-stic/security-advisories/tree/master/ObjSys/CVE-2016-5080#8-report-timeline

it is not clear if all vendors have been contacted.

Wonder how to grep for rtxMemHeapAlloc in the possibly encrypted
baseband module firmware.


Marcin

From janusz at speedchecker.xyz  Wed Jul 20 11:07:56 2016
From: janusz at speedchecker.xyz (Janusz Jezowicz)
Date: Wed, 20 Jul 2016 13:07:56 +0200
Subject: Speedtest.net not accessible in Chrome due to deceptive ads
Message-ID: <CAA6dEZNy64iWvJcdkEzmMOoaC81EwGH6F4FQOejhkM=DQWeYQw@mail.gmail.com>

Since this morning Speedtest.net is not accessible in Chrome
Reason:
https://www.google.com/transparencyreport/safebrowsing/diagnostic/#url=c.speedtest.net

For any ISPs/content providers linking to speedtest.net you may want to
swap links to a different website or host your own speed test.

e.g. Netflix at http://fast.com

Regards,

Janusz Jezowicz
*Speedchecker Ltd*
*email*: janusz at speedchecker.xyz
*skype*: jezowicz
*phone*: +442032863573
*web*: www.speedchecker.xyz
The Black Church, St. Mary?s Place, Dublin 7, D07 P4AX, Ireland

From A.L.M.Buxey at lboro.ac.uk  Wed Jul 20 12:09:10 2016
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Wed, 20 Jul 2016 12:09:10 +0000
Subject: Speedtest.net not accessible in Chrome due to deceptive ads
In-Reply-To: <CAA6dEZNy64iWvJcdkEzmMOoaC81EwGH6F4FQOejhkM=DQWeYQw@mail.gmail.com>
References: <CAA6dEZNy64iWvJcdkEzmMOoaC81EwGH6F4FQOejhkM=DQWeYQw@mail.gmail.com>
Message-ID: <20160720120910.GA27233@lboro.ac.uk>

Hi,

> Since this morning Speedtest.net is not accessible in Chrome
> Reason:
> https://www.google.com/transparencyreport/safebrowsing/diagnostic/#url=c.speedtest.net

someones complained about the URL based on them stupidly installing 'cleanmymac' or such?

use the non flash junk HTML5 version instead

http://beta.speedtest.net/

still bleats about "Deceptive site ahead"

and PS "is not accessible in Chrome" - not true.

click DETAILS,  then click on 

visit this unsafe site.

(with the pre-condition of " if you understand the risks to your security"


I personally dont want or need Google to start being my nanny on the internet  :/


alan

PS you may have other interests involved here given your affiliation to speedchecker.xyz 

From janusz at speedchecker.xyz  Wed Jul 20 12:55:31 2016
From: janusz at speedchecker.xyz (Janusz Jezowicz)
Date: Wed, 20 Jul 2016 14:55:31 +0200
Subject: Speedtest.net not accessible in Chrome due to deceptive ads
In-Reply-To: <20160720120910.GA27233@lboro.ac.uk>
References: <CAA6dEZNy64iWvJcdkEzmMOoaC81EwGH6F4FQOejhkM=DQWeYQw@mail.gmail.com>
 <20160720120910.GA27233@lboro.ac.uk>
Message-ID: <CAA6dEZMNg=vABFEe2C_4iEmRhbgxZPsqmvHV5arUQEyeY89d0g@mail.gmail.com>

It seems that some users reporting the site is back. I am counting 6+ hours
of outage.

Alan - what you describe is something normal user will never do. When user
sees red screen like that, he runs screaming. So in theory yes, it was
accessible, but ... wasn't.

Its hard to avoid Google nanny when they offer so many useful services



On 20 July 2016 at 14:09, <A.L.M.Buxey at lboro.ac.uk> wrote:

> Hi,
>
> > Since this morning Speedtest.net is not accessible in Chrome
> > Reason:
> >
> https://www.google.com/transparencyreport/safebrowsing/diagnostic/#url=c.speedtest.net
>
> someones complained about the URL based on them stupidly installing
> 'cleanmymac' or such?
>
> use the non flash junk HTML5 version instead
>
> http://beta.speedtest.net/
>
> still bleats about "Deceptive site ahead"
>
> and PS "is not accessible in Chrome" - not true.
>
> click DETAILS,  then click on
>
> visit this unsafe site.
>
> (with the pre-condition of " if you understand the risks to your security"
>
>
> I personally dont want or need Google to start being my nanny on the
> internet  :/
>
>
> alan
>
> PS you may have other interests involved here given your affiliation to
> speedchecker.xyz
>

From sakamura at gmail.com  Wed Jul 20 14:32:43 2016
From: sakamura at gmail.com (Ishmael Rufus)
Date: Wed, 20 Jul 2016 09:32:43 -0500
Subject: Speedtest.net not accessible in Chrome due to deceptive ads
In-Reply-To: <CAA6dEZMNg=vABFEe2C_4iEmRhbgxZPsqmvHV5arUQEyeY89d0g@mail.gmail.com>
References: <CAA6dEZNy64iWvJcdkEzmMOoaC81EwGH6F4FQOejhkM=DQWeYQw@mail.gmail.com>
 <20160720120910.GA27233@lboro.ac.uk>
 <CAA6dEZMNg=vABFEe2C_4iEmRhbgxZPsqmvHV5arUQEyeY89d0g@mail.gmail.com>
Message-ID: <CAL-SDLEfK+k2jv16F2RnHOG1F_ECZkGcAPff2o3svP2Jgv+4AA@mail.gmail.com>

http://www.measurementlab.net/tools/ndt/

100% ad free.

On Wed, Jul 20, 2016 at 7:55 AM, Janusz Jezowicz <janusz at speedchecker.xyz>
wrote:

> It seems that some users reporting the site is back. I am counting 6+ hours
> of outage.
>
> Alan - what you describe is something normal user will never do. When user
> sees red screen like that, he runs screaming. So in theory yes, it was
> accessible, but ... wasn't.
>
> Its hard to avoid Google nanny when they offer so many useful services
>
>
>
> On 20 July 2016 at 14:09, <A.L.M.Buxey at lboro.ac.uk> wrote:
>
> > Hi,
> >
> > > Since this morning Speedtest.net is not accessible in Chrome
> > > Reason:
> > >
> >
> https://www.google.com/transparencyreport/safebrowsing/diagnostic/#url=c.speedtest.net
> >
> > someones complained about the URL based on them stupidly installing
> > 'cleanmymac' or such?
> >
> > use the non flash junk HTML5 version instead
> >
> > http://beta.speedtest.net/
> >
> > still bleats about "Deceptive site ahead"
> >
> > and PS "is not accessible in Chrome" - not true.
> >
> > click DETAILS,  then click on
> >
> > visit this unsafe site.
> >
> > (with the pre-condition of " if you understand the risks to your
> security"
> >
> >
> > I personally dont want or need Google to start being my nanny on the
> > internet  :/
> >
> >
> > alan
> >
> > PS you may have other interests involved here given your affiliation to
> > speedchecker.xyz
> >
>

From rjacobs at pslightwave.com  Wed Jul 20 14:42:51 2016
From: rjacobs at pslightwave.com (Robert Jacobs)
Date: Wed, 20 Jul 2016 14:42:51 +0000
Subject: Speedtest.net not accessible in Chrome due to deceptive ads
In-Reply-To: <CAL-SDLEfK+k2jv16F2RnHOG1F_ECZkGcAPff2o3svP2Jgv+4AA@mail.gmail.com>
References: <CAA6dEZNy64iWvJcdkEzmMOoaC81EwGH6F4FQOejhkM=DQWeYQw@mail.gmail.com>
 <20160720120910.GA27233@lboro.ac.uk>
 <CAA6dEZMNg=vABFEe2C_4iEmRhbgxZPsqmvHV5arUQEyeY89d0g@mail.gmail.com>
 <CAL-SDLEfK+k2jv16F2RnHOG1F_ECZkGcAPff2o3svP2Jgv+4AA@mail.gmail.com>
Message-ID: <BN1PR06MB232B09DF9786CD34DD9AB48A9080@BN1PR06MB232.namprd06.prod.outlook.com>

It is back for us in Houston via NTT and Level 3 ... no warnings when you got to site... 

Robert Jacobs | Network Director/Architect 

Direct:? 832-615-7742
Main:?? 832-615-8000
Fax:??? 713-510-1650

5959 Corporate Dr. Suite 3300; Houston, TX 77036



A Certified Woman-Owned Business 

24x7x365 Customer? Support: 832-615-8000 | support at pslightwave.com
This electronic message contains information from Phonoscope Lightwave which may be privileged and confidential. The information is intended to be for the use of individual(s) or entity named above. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify me by telephone or e-mail immediately.



-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ishmael Rufus
Sent: Wednesday, July 20, 2016 9:33 AM
To: Janusz Jezowicz <janusz at speedchecker.xyz>
Cc: NANOG list <nanog at nanog.org>
Subject: Re: Speedtest.net not accessible in Chrome due to deceptive ads

http://www.measurementlab.net/tools/ndt/

100% ad free.

On Wed, Jul 20, 2016 at 7:55 AM, Janusz Jezowicz <janusz at speedchecker.xyz>
wrote:

> It seems that some users reporting the site is back. I am counting 6+ 
> hours of outage.
>
> Alan - what you describe is something normal user will never do. When 
> user sees red screen like that, he runs screaming. So in theory yes, 
> it was accessible, but ... wasn't.
>
> Its hard to avoid Google nanny when they offer so many useful services
>
>
>
> On 20 July 2016 at 14:09, <A.L.M.Buxey at lboro.ac.uk> wrote:
>
> > Hi,
> >
> > > Since this morning Speedtest.net is not accessible in Chrome
> > > Reason:
> > >
> >
> https://www.google.com/transparencyreport/safebrowsing/diagnostic/#url
> =c.speedtest.net
> >
> > someones complained about the URL based on them stupidly installing 
> > 'cleanmymac' or such?
> >
> > use the non flash junk HTML5 version instead
> >
> > http://beta.speedtest.net/
> >
> > still bleats about "Deceptive site ahead"
> >
> > and PS "is not accessible in Chrome" - not true.
> >
> > click DETAILS,  then click on
> >
> > visit this unsafe site.
> >
> > (with the pre-condition of " if you understand the risks to your
> security"
> >
> >
> > I personally dont want or need Google to start being my nanny on the 
> > internet  :/
> >
> >
> > alan
> >
> > PS you may have other interests involved here given your affiliation 
> > to speedchecker.xyz
> >
>

From jacques.latour at cira.ca  Wed Jul 20 18:52:36 2016
From: jacques.latour at cira.ca (Jacques Latour)
Date: Wed, 20 Jul 2016 18:52:36 +0000
Subject: Speedtest.net not accessible in Chrome due to deceptive ads
In-Reply-To: <CAL-SDLEfK+k2jv16F2RnHOG1F_ECZkGcAPff2o3svP2Jgv+4AA@mail.gmail.com>
References: <CAA6dEZNy64iWvJcdkEzmMOoaC81EwGH6F4FQOejhkM=DQWeYQw@mail.gmail.com>
 <20160720120910.GA27233@lboro.ac.uk>
 <CAA6dEZMNg=vABFEe2C_4iEmRhbgxZPsqmvHV5arUQEyeY89d0g@mail.gmail.com>
 <CAL-SDLEfK+k2jv16F2RnHOG1F_ECZkGcAPff2o3svP2Jgv+4AA@mail.gmail.com>
Message-ID: <C059877D829F76429F49E0B48705D888E2C6FCCA@EXCH-01.CORP.CIRA.CA>

In that case, for Canadians, go to http://performance.cira.ca, it's MLAB-NDT based and checks IPv6 and DNSSEC :-)

100% ad free

>-----Original Message-----
>From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ishmael Rufus
>Sent: July-20-16 10:33 AM
>To: Janusz Jezowicz
>Cc: NANOG list
>Subject: Re: Speedtest.net not accessible in Chrome due to deceptive ads
>
>http://www.measurementlab.net/tools/ndt/
>
>100% ad free.
>
>On Wed, Jul 20, 2016 at 7:55 AM, Janusz Jezowicz <janusz at speedchecker.xyz>
>wrote:
>
>> It seems that some users reporting the site is back. I am counting 6+
>> hours of outage.
>>
>> Alan - what you describe is something normal user will never do. When
>> user sees red screen like that, he runs screaming. So in theory yes,
>> it was accessible, but ... wasn't.
>>
>> Its hard to avoid Google nanny when they offer so many useful services
>>
>>
>>
>> On 20 July 2016 at 14:09, <A.L.M.Buxey at lboro.ac.uk> wrote:
>>
>> > Hi,
>> >
>> > > Since this morning Speedtest.net is not accessible in Chrome
>> > > Reason:
>> > >
>> >
>> https://www.google.com/transparencyreport/safebrowsing/diagnostic/#url
>> =c.speedtest.net
>> >
>> > someones complained about the URL based on them stupidly installing
>> > 'cleanmymac' or such?
>> >
>> > use the non flash junk HTML5 version instead
>> >
>> > http://beta.speedtest.net/
>> >
>> > still bleats about "Deceptive site ahead"
>> >
>> > and PS "is not accessible in Chrome" - not true.
>> >
>> > click DETAILS,  then click on
>> >
>> > visit this unsafe site.
>> >
>> > (with the pre-condition of " if you understand the risks to your
>> security"
>> >
>> >
>> > I personally dont want or need Google to start being my nanny on the
>> > internet  :/
>> >
>> >
>> > alan
>> >
>> > PS you may have other interests involved here given your affiliation
>> > to speedchecker.xyz
>> >
>>

From opendak at shaw.ca  Wed Jul 20 18:56:41 2016
From: opendak at shaw.ca (David)
Date: Wed, 20 Jul 2016 12:56:41 -0600
Subject: Speedtest.net not accessible in Chrome due to deceptive ads
In-Reply-To: <C059877D829F76429F49E0B48705D888E2C6FCCA@EXCH-01.CORP.CIRA.CA>
References: <CAA6dEZNy64iWvJcdkEzmMOoaC81EwGH6F4FQOejhkM=DQWeYQw@mail.gmail.com>
 <20160720120910.GA27233@lboro.ac.uk>
 <CAA6dEZMNg=vABFEe2C_4iEmRhbgxZPsqmvHV5arUQEyeY89d0g@mail.gmail.com>
 <CAL-SDLEfK+k2jv16F2RnHOG1F_ECZkGcAPff2o3svP2Jgv+4AA@mail.gmail.com>
 <C059877D829F76429F49E0B48705D888E2C6FCCA@EXCH-01.CORP.CIRA.CA>
Message-ID: <779ce14c-1d1c-15ae-3895-367c502bbb88@shaw.ca>

On 2016-07-20 12:52 PM, Jacques Latour wrote:
> In that case, for Canadians, go to http://performance.cira.ca, it's MLAB-NDT based and checks IPv6 and DNSSEC :-)
>
> 100% ad free
>

And on the flip side, refuses to work with Safari.


From jacques.latour at cira.ca  Wed Jul 20 19:24:03 2016
From: jacques.latour at cira.ca (Jacques Latour)
Date: Wed, 20 Jul 2016 19:24:03 +0000
Subject: Speedtest.net not accessible in Chrome due to deceptive ads
In-Reply-To: <779ce14c-1d1c-15ae-3895-367c502bbb88@shaw.ca>
References: <CAA6dEZNy64iWvJcdkEzmMOoaC81EwGH6F4FQOejhkM=DQWeYQw@mail.gmail.com>
 <20160720120910.GA27233@lboro.ac.uk>
 <CAA6dEZMNg=vABFEe2C_4iEmRhbgxZPsqmvHV5arUQEyeY89d0g@mail.gmail.com>
 <CAL-SDLEfK+k2jv16F2RnHOG1F_ECZkGcAPff2o3svP2Jgv+4AA@mail.gmail.com>
 <C059877D829F76429F49E0B48705D888E2C6FCCA@EXCH-01.CORP.CIRA.CA>
 <779ce14c-1d1c-15ae-3895-367c502bbb88@shaw.ca>
Message-ID: <D3B54738.3D085%jacques.latour@cira.ca>

Yup, websocket implementations across all browsers not equal

On 2016-07-20, 2:56 PM, "NANOG on behalf of David"
<nanog-bounces at nanog.org on behalf of opendak at shaw.ca> wrote:

>On 2016-07-20 12:52 PM, Jacques Latour wrote:
>> In that case, for Canadians, go to http://performance.cira.ca, it's
>>MLAB-NDT based and checks IPv6 and DNSSEC :-)
>>
>> 100% ad free
>>
>
>And on the flip side, refuses to work with Safari.


From rubensk at gmail.com  Wed Jul 20 19:28:42 2016
From: rubensk at gmail.com (Rubens Kuhl)
Date: Wed, 20 Jul 2016 16:28:42 -0300
Subject: Speedtest.net not accessible in Chrome due to deceptive ads
In-Reply-To: <779ce14c-1d1c-15ae-3895-367c502bbb88@shaw.ca>
References: <CAA6dEZNy64iWvJcdkEzmMOoaC81EwGH6F4FQOejhkM=DQWeYQw@mail.gmail.com>
 <20160720120910.GA27233@lboro.ac.uk>
 <CAA6dEZMNg=vABFEe2C_4iEmRhbgxZPsqmvHV5arUQEyeY89d0g@mail.gmail.com>
 <CAL-SDLEfK+k2jv16F2RnHOG1F_ECZkGcAPff2o3svP2Jgv+4AA@mail.gmail.com>
 <C059877D829F76429F49E0B48705D888E2C6FCCA@EXCH-01.CORP.CIRA.CA>
 <779ce14c-1d1c-15ae-3895-367c502bbb88@shaw.ca>
Message-ID: <CAGFn2k37g8V6fsafeRG8L=8D8X1TYn8Zn5uPxeHkxsVS=aa0GQ@mail.gmail.com>

On Wed, Jul 20, 2016 at 3:56 PM, David <opendak at shaw.ca> wrote:

> On 2016-07-20 12:52 PM, Jacques Latour wrote:
>
>> In that case, for Canadians, go to http://performance.cira.ca, it's
>> MLAB-NDT based and checks IPv6 and DNSSEC :-)
>>
>> 100% ad free
>>
>>
> And on the flip side, refuses to work with Safari.
>

Working with Safari might require Java which is also not a popular choice
among security conscious users... ... http://simet.nic.br requires either
Chrome or a Java-enabled browser.


Rubens

From collin at averysmallbird.com  Wed Jul 20 19:51:18 2016
From: collin at averysmallbird.com (Collin Anderson)
Date: Wed, 20 Jul 2016 15:51:18 -0400
Subject: Speedtest.net not accessible in Chrome due to deceptive ads
In-Reply-To: <CAL-SDLEfK+k2jv16F2RnHOG1F_ECZkGcAPff2o3svP2Jgv+4AA@mail.gmail.com>
References: <CAA6dEZNy64iWvJcdkEzmMOoaC81EwGH6F4FQOejhkM=DQWeYQw@mail.gmail.com>
 <20160720120910.GA27233@lboro.ac.uk>
 <CAA6dEZMNg=vABFEe2C_4iEmRhbgxZPsqmvHV5arUQEyeY89d0g@mail.gmail.com>
 <CAL-SDLEfK+k2jv16F2RnHOG1F_ECZkGcAPff2o3svP2Jgv+4AA@mail.gmail.com>
Message-ID: <CAC+VsLtySxYOZWyS-Hg6jnDq6M8TyGLaPGURXHXpt1B-zsZcfQ@mail.gmail.com>

Thanks for the mention ? for what it's worth, we are testing a more
accessible interface for the web-based NDT test.

Link: https://speed.measurementlab.net/#/

Definitely interested in feedback from the NANOG community.

On Wed, Jul 20, 2016 at 10:32 AM, Ishmael Rufus <sakamura at gmail.com> wrote:

> http://www.measurementlab.net/tools/ndt/
>
> 100% ad free.
>
> On Wed, Jul 20, 2016 at 7:55 AM, Janusz Jezowicz <janusz at speedchecker.xyz>
> wrote:
>
> > It seems that some users reporting the site is back. I am counting 6+
> hours
> > of outage.
> >
> > Alan - what you describe is something normal user will never do. When
> user
> > sees red screen like that, he runs screaming. So in theory yes, it was
> > accessible, but ... wasn't.
> >
> > Its hard to avoid Google nanny when they offer so many useful services
> >
> >
> >
> > On 20 July 2016 at 14:09, <A.L.M.Buxey at lboro.ac.uk> wrote:
> >
> > > Hi,
> > >
> > > > Since this morning Speedtest.net is not accessible in Chrome
> > > > Reason:
> > > >
> > >
> >
> https://www.google.com/transparencyreport/safebrowsing/diagnostic/#url=c.speedtest.net
> > >
> > > someones complained about the URL based on them stupidly installing
> > > 'cleanmymac' or such?
> > >
> > > use the non flash junk HTML5 version instead
> > >
> > > http://beta.speedtest.net/
> > >
> > > still bleats about "Deceptive site ahead"
> > >
> > > and PS "is not accessible in Chrome" - not true.
> > >
> > > click DETAILS,  then click on
> > >
> > > visit this unsafe site.
> > >
> > > (with the pre-condition of " if you understand the risks to your
> > security"
> > >
> > >
> > > I personally dont want or need Google to start being my nanny on the
> > > internet  :/
> > >
> > >
> > > alan
> > >
> > > PS you may have other interests involved here given your affiliation to
> > > speedchecker.xyz
> > >
> >
>



-- 
*Collin David Anderson*
averysmallbird.com | @cda | Washington, D.C.

From tony at lavanauts.org  Wed Jul 20 21:00:37 2016
From: tony at lavanauts.org (Antonio Querubin)
Date: Wed, 20 Jul 2016 11:00:37 -1000 (HST)
Subject: Speedtest.net not accessible in Chrome due to deceptive ads
In-Reply-To: <CAC+VsLtySxYOZWyS-Hg6jnDq6M8TyGLaPGURXHXpt1B-zsZcfQ@mail.gmail.com>
References: <CAA6dEZNy64iWvJcdkEzmMOoaC81EwGH6F4FQOejhkM=DQWeYQw@mail.gmail.com>
 <20160720120910.GA27233@lboro.ac.uk>
 <CAA6dEZMNg=vABFEe2C_4iEmRhbgxZPsqmvHV5arUQEyeY89d0g@mail.gmail.com>
 <CAL-SDLEfK+k2jv16F2RnHOG1F_ECZkGcAPff2o3svP2Jgv+4AA@mail.gmail.com>
 <CAC+VsLtySxYOZWyS-Hg6jnDq6M8TyGLaPGURXHXpt1B-zsZcfQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.10.1607201100080.22652@sam>

On Wed, 20 Jul 2016, Collin Anderson wrote:

> Thanks for the mention ? for what it's worth, we are testing a more
> accessible interface for the web-based NDT test.
>
> Link: https://speed.measurementlab.net/#/
>
> Definitely interested in feedback from the NANOG community.

Feedback:  needs IPv6 connectivity and support.

Antonio Querubin
e-mail:  tony at lavanauts.org
xmpp:  antonioquerubin at gmail.com

From collin at averysmallbird.com  Wed Jul 20 21:42:23 2016
From: collin at averysmallbird.com (Collin Anderson)
Date: Wed, 20 Jul 2016 17:42:23 -0400
Subject: Speedtest.net not accessible in Chrome due to deceptive ads
In-Reply-To: <alpine.DEB.2.10.1607201100080.22652@sam>
References: <CAA6dEZNy64iWvJcdkEzmMOoaC81EwGH6F4FQOejhkM=DQWeYQw@mail.gmail.com>
 <20160720120910.GA27233@lboro.ac.uk>
 <CAA6dEZMNg=vABFEe2C_4iEmRhbgxZPsqmvHV5arUQEyeY89d0g@mail.gmail.com>
 <CAL-SDLEfK+k2jv16F2RnHOG1F_ECZkGcAPff2o3svP2Jgv+4AA@mail.gmail.com>
 <CAC+VsLtySxYOZWyS-Hg6jnDq6M8TyGLaPGURXHXpt1B-zsZcfQ@mail.gmail.com>
 <alpine.DEB.2.10.1607201100080.22652@sam>
Message-ID: <CAC+VsLt2r5nhodd+P+Lhi7Aqq2V5Wycbms-nNQQSB8N-ek0B1g@mail.gmail.com>

On Wed, Jul 20, 2016 at 5:00 PM, Antonio Querubin <tony at lavanauts.org>
wrote:

> Feedback:  needs IPv6 connectivity and support.
>

Point well taken. The vast majority of M-Lab sites have IPv6 connectivity,
and we have enabled it for NDT at times, but I believe there was a concern
at one point about an issue with error handling on the IPv6 side that lead
to it being disabled temporarily. We will follow through on this.


-- 
*Collin David Anderson*
averysmallbird.com | @cda | Washington, D.C.

From jra at baylink.com  Thu Jul 21 21:19:05 2016
From: jra at baylink.com (Jay R. Ashworth)
Date: Thu, 21 Jul 2016 21:19:05 +0000 (UTC)
Subject: I recommend dslreports.com/speedtest these days (was Speedtest.net
 not accessible in Chrome due to deceptive ads)
In-Reply-To: <CAA6dEZNy64iWvJcdkEzmMOoaC81EwGH6F4FQOejhkM=DQWeYQw@mail.gmail.com>
References: <CAA6dEZNy64iWvJcdkEzmMOoaC81EwGH6F4FQOejhkM=DQWeYQw@mail.gmail.com>
Message-ID: <994213489.26076.1469135945049.JavaMail.zimbra@baylink.com>

----- Original Message -----
> From: "Janusz Jezowicz" <janusz at speedchecker.xyz>

> Since this morning Speedtest.net is not accessible in Chrome
> Reason:
> https://www.google.com/transparencyreport/safebrowsing/diagnostic/#url=c.speedtest.net
> 
> For any ISPs/content providers linking to speedtest.net you may want to
> swap links to a different website or host your own speed test.

So far, I am very pleased with how it works, though I think it's letter
grades on speed are a bit pessimistic (65Mbps is a "C").

Specifically, it measures bufferbloat, with both a realtime graph and a 
letter grade -- this is, in fact, how I discovered it in the first place.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274

From D.Lasher at f5.com  Thu Jul 21 22:36:20 2016
From: D.Lasher at f5.com (Donn Lasher)
Date: Thu, 21 Jul 2016 22:36:20 +0000
Subject: I recommend dslreports.com/speedtest these days (was
 Speedtest.net not accessible in Chrome due to deceptive ads)
In-Reply-To: <994213489.26076.1469135945049.JavaMail.zimbra@baylink.com>
References: <CAA6dEZNy64iWvJcdkEzmMOoaC81EwGH6F4FQOejhkM=DQWeYQw@mail.gmail.com>
 <994213489.26076.1469135945049.JavaMail.zimbra@baylink.com>
Message-ID: <113466DC-5310-4A75-A2C4-C4D7CC8AE4C5@f5.com>

On 7/21/16, 2:19 PM, "NANOG on behalf of Jay R. Ashworth" <nanog-bounces at nanog.org on behalf of jra at baylink.com> wrote:



>----- Original Message -----
>> From: "Janusz Jezowicz" <janusz at speedchecker.xyz>
>
>> Since this morning Speedtest.net is not accessible in Chrome
>> Reason:
>> https://www.google.com/transparencyreport/safebrowsing/diagnostic/#url=c.speedtest.net
>> 
>> For any ISPs/content providers linking to speedtest.net you may want to
>> swap links to a different website or host your own speed test.
>
>So far, I am very pleased with how it works, though I think it's letter
>grades on speed are a bit pessimistic (65Mbps is a "C").
>
>Specifically, it measures bufferbloat, with both a realtime graph and a 


Are you talking about the dslreports speedtest? I like that one, very detailed results.

http://speedtest.dslreports.com/


I?d agree with the pessimistic scoring.. 160Mbit was given a ?B? grade.





From eric-list at truenet.com  Fri Jul 22 00:11:36 2016
From: eric-list at truenet.com (Eric Tykwinski)
Date: Thu, 21 Jul 2016 20:11:36 -0400
Subject: I recommend dslreports.com/speedtest these days (was
 Speedtest.net not accessible in Chrome due to deceptive ads)
In-Reply-To: <113466DC-5310-4A75-A2C4-C4D7CC8AE4C5@f5.com>
References: <CAA6dEZNy64iWvJcdkEzmMOoaC81EwGH6F4FQOejhkM=DQWeYQw@mail.gmail.com>
 <994213489.26076.1469135945049.JavaMail.zimbra@baylink.com>
 <113466DC-5310-4A75-A2C4-C4D7CC8AE4C5@f5.com>
Message-ID: <414BCE73-08E8-4D0B-9056-C629CA8F2C03@truenet.com>

This is probably for Jim Gettys directly, but I?m sure most others have input.  I could of sworn that that there was some test made to detect it directly on switches and routers?  Sort of like iperf, but to test bufferbloat specifically given the OS stack which is going to have issues as well, as shown on bufferbloat.net <http://bufferbloat.net/>. 

> On Jul 21, 2016, at 6:36 PM, Donn Lasher via NANOG <nanog at nanog.org> wrote:
> 
> On 7/21/16, 2:19 PM, "NANOG on behalf of Jay R. Ashworth" <nanog-bounces at nanog.org on behalf of jra at baylink.com> wrote:
> 
> 
> 
>> ----- Original Message -----
>>> From: "Janusz Jezowicz" <janusz at speedchecker.xyz>
>> 
>>> Since this morning Speedtest.net is not accessible in Chrome
>>> Reason:
>>> https://www.google.com/transparencyreport/safebrowsing/diagnostic/#url=c.speedtest.net
>>> 
>>> For any ISPs/content providers linking to speedtest.net you may want to
>>> swap links to a different website or host your own speed test.
>> 
>> So far, I am very pleased with how it works, though I think it's letter
>> grades on speed are a bit pessimistic (65Mbps is a "C").
>> 
>> Specifically, it measures bufferbloat, with both a realtime graph and a 
> 
> 
> Are you talking about the dslreports speedtest? I like that one, very detailed results.
> 
> http://speedtest.dslreports.com/
> 
> 
> I?d agree with the pessimistic scoring.. 160Mbit was given a ?B? grade.
> 
> 
> 
> 


From baldur.norddahl at gmail.com  Fri Jul 22 12:01:36 2016
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Fri, 22 Jul 2016 14:01:36 +0200
Subject: MTU
In-Reply-To: <CAPkb-7DtxSt=9vgBviZBSaxN57q=wkDJw+6m=RBmf01s9GtVXw@mail.gmail.com>
References: <CAPkb-7CRMNUK6Av-BBzUgMLh2YW0XfxDs4x4P4rJg6ookVNP=A@mail.gmail.com>
 <CAPkb-7BBOnWSgLkrOFGMkAp-PHyhxwD0cctmvsN+wWgzw+vp-Q@mail.gmail.com>
 <CAPkb-7CKUF76__dd9Rk2dtswbW82009A4yGY0ZMO4vTik9D0Jg@mail.gmail.com>
 <CAPkb-7BUTaims9cfAs+HKKu9cMZ-z6U0ppk0xTyovBOgi1vd=Q@mail.gmail.com>
 <CAPkb-7A0jXgq4=yyhkPhbw5Sxc_kg+fgr_Zk+N8maBPu+mn_Qg@mail.gmail.com>
 <CAPkb-7B6cav2LHgdCE6Ywq4pKgb1MqVjEgKoFZG+JzKf73cA8w@mail.gmail.com>
 <CAPkb-7CTi_ekX35OcjdwqfM+W-gdkfkfpLsHXxhH5bVr=nyv3A@mail.gmail.com>
 <CAPkb-7CnxtLuWWA+PDx2ba_xkaE54+Ei4NAbZp7TzvgdGi2Auw@mail.gmail.com>
 <CAPkb-7B3geM2iydgmidq+gFh4oJvzbCj_eznQSvLRhi3LGgvCA@mail.gmail.com>
 <CAPkb-7C78wAAYrdfgZB65W=tJRumUb3qbVGVE1u28V7DTP82Ww@mail.gmail.com>
 <CAPkb-7A1RsiN=tv6YuggARbUx2u8EDOUyHc__BJ6iB=UFWxs4Q@mail.gmail.com>
 <CAPkb-7AQTQnuv9baaO=yEG0e+s0O1ppopafsCNoP8bSuCMysxg@mail.gmail.com>
 <CAPkb-7AXhoCrVnWv+pzbJGPW86mvzGmGuitqscqQ7AJFrriDRg@mail.gmail.com>
 <CAPkb-7BaGqybRDLRd01E65bmzoc-1ebnuYsEtYsSU8VLu5dp3A@mail.gmail.com>
 <CAPkb-7BAjMO2sdY=87J6S6yd8oecyr1gyJa_jqaQUy7=XU0oAw@mail.gmail.com>
 <CAPkb-7A5TgL+dL8D48sccHSCVcHWEah9sv3hZT-7j=kN4aKnYQ@mail.gmail.com>
 <CAPkb-7DtxSt=9vgBviZBSaxN57q=wkDJw+6m=RBmf01s9GtVXw@mail.gmail.com>
Message-ID: <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>

Hi

What is best practice regarding choosing MTU on transit links?

Until now we have used the default of 1500 bytes. I now have a project were
we peer directly with another small ISP. However we need a backup so we
figured a GRE tunnel on a common IP transit carrier would work. We want to
avoid the troubles you get by having an effective MTU smaller than 1500
inside the tunnel, so the IP transit carrier agreed to configure a MTU of
9216.

Obviously I only need to increase my MTU by the size of the GRE header. But
I am thinking is there any reason not to go all in and ask every peer to go
to whatever max MTU they can support? My own equipment will do MTU of 9600
bytes.

On the other hand, none of my customers will see any actual difference
because they are end users with CPE equipment that expects a 1500 byte MTU.
Trying to deliver jumbo frames to the end users is probably going to end
badly.

Regards,

Baldur

From Jason_Livingood at comcast.com  Fri Jul 22 12:32:47 2016
From: Jason_Livingood at comcast.com (Livingood, Jason)
Date: Fri, 22 Jul 2016 12:32:47 +0000
Subject: Speedtest.net not accessible in Chrome due to deceptive ads
In-Reply-To: <CAC+VsLt2r5nhodd+P+Lhi7Aqq2V5Wycbms-nNQQSB8N-ek0B1g@mail.gmail.com>
References: <CAA6dEZNy64iWvJcdkEzmMOoaC81EwGH6F4FQOejhkM=DQWeYQw@mail.gmail.com>
 <20160720120910.GA27233@lboro.ac.uk>
 <CAA6dEZMNg=vABFEe2C_4iEmRhbgxZPsqmvHV5arUQEyeY89d0g@mail.gmail.com>
 <CAL-SDLEfK+k2jv16F2RnHOG1F_ECZkGcAPff2o3svP2Jgv+4AA@mail.gmail.com>
 <CAC+VsLtySxYOZWyS-Hg6jnDq6M8TyGLaPGURXHXpt1B-zsZcfQ@mail.gmail.com>
 <alpine.DEB.2.10.1607201100080.22652@sam>
 <CAC+VsLt2r5nhodd+P+Lhi7Aqq2V5Wycbms-nNQQSB8N-ek0B1g@mail.gmail.com>
Message-ID: <A654EDFE-E9BA-43CF-817B-633711116B8B@cable.comcast.com>

And work on accurate measurement of higher link speeds. ;-)

On 7/20/16, 11:42 PM, "NANOG on behalf of Collin Anderson" <nanog-bounces at nanog.org on behalf of collin at averysmallbird.com> wrote:

    On Wed, Jul 20, 2016 at 5:00 PM, Antonio Querubin <tony at lavanauts.org>
    wrote:
    
    > Feedback:  needs IPv6 connectivity and support.
    >
    
    Point well taken. The vast majority of M-Lab sites have IPv6 connectivity,
    and we have enabled it for NDT at times, but I believe there was a concern
    at one point about an issue with error handling on the IPv6 side that lead
    to it being disabled temporarily. We will follow through on this.
    
    
    -- 
    *Collin David Anderson*
    averysmallbird.com | @cda | Washington, D.C.
    
    


From jacques.latour at cira.ca  Fri Jul 22 12:50:58 2016
From: jacques.latour at cira.ca (Jacques Latour)
Date: Fri, 22 Jul 2016 12:50:58 +0000
Subject: Speedtest.net not accessible in Chrome due to deceptive ads
In-Reply-To: <A654EDFE-E9BA-43CF-817B-633711116B8B@cable.comcast.com>
References: <CAA6dEZNy64iWvJcdkEzmMOoaC81EwGH6F4FQOejhkM=DQWeYQw@mail.gmail.com>
 <20160720120910.GA27233@lboro.ac.uk>
 <CAA6dEZMNg=vABFEe2C_4iEmRhbgxZPsqmvHV5arUQEyeY89d0g@mail.gmail.com>
 <CAL-SDLEfK+k2jv16F2RnHOG1F_ECZkGcAPff2o3svP2Jgv+4AA@mail.gmail.com>
 <CAC+VsLtySxYOZWyS-Hg6jnDq6M8TyGLaPGURXHXpt1B-zsZcfQ@mail.gmail.com>
 <alpine.DEB.2.10.1607201100080.22652@sam>
 <CAC+VsLt2r5nhodd+P+Lhi7Aqq2V5Wycbms-nNQQSB8N-ek0B1g@mail.gmail.com>
 <A654EDFE-E9BA-43CF-817B-633711116B8B@cable.comcast.com>
Message-ID: <C059877D829F76429F49E0B48705D888E2CAEBCA@EXCH-01.CORP.CIRA.CA>

Good point, we would need a piece of websocket code to run before or after NDT that figures out MAX speed so end users we can compare with other speed tests.
NDT is about the quality of a connection, not absolute maximum quantity that can be jammed on a link irrespective of errors and all.


>-----Original Message-----
>From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Livingood,
>Jason
>Sent: July-22-16 8:33 AM
>To: Collin Anderson; Antonio Querubin
>Cc: NANOG list
>Subject: Re: Speedtest.net not accessible in Chrome due to deceptive ads
>
>And work on accurate measurement of higher link speeds. ;-)
>
>On 7/20/16, 11:42 PM, "NANOG on behalf of Collin Anderson" <nanog-
>bounces at nanog.org on behalf of collin at averysmallbird.com> wrote:
>
>    On Wed, Jul 20, 2016 at 5:00 PM, Antonio Querubin <tony at lavanauts.org>
>    wrote:
>
>    > Feedback:  needs IPv6 connectivity and support.
>    >
>
>    Point well taken. The vast majority of M-Lab sites have IPv6 connectivity,
>    and we have enabled it for NDT at times, but I believe there was a concern
>    at one point about an issue with error handling on the IPv6 side that lead
>    to it being disabled temporarily. We will follow through on this.
>
>
>    --
>    *Collin David Anderson*
>    averysmallbird.com | @cda | Washington, D.C.
>
>


From mark.tinka at seacom.mu  Fri Jul 22 12:53:51 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Fri, 22 Jul 2016 14:53:51 +0200
Subject: MTU
In-Reply-To: <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>
References: <CAPkb-7CRMNUK6Av-BBzUgMLh2YW0XfxDs4x4P4rJg6ookVNP=A@mail.gmail.com>
 <CAPkb-7B6cav2LHgdCE6Ywq4pKgb1MqVjEgKoFZG+JzKf73cA8w@mail.gmail.com>
 <CAPkb-7CTi_ekX35OcjdwqfM+W-gdkfkfpLsHXxhH5bVr=nyv3A@mail.gmail.com>
 <CAPkb-7CnxtLuWWA+PDx2ba_xkaE54+Ei4NAbZp7TzvgdGi2Auw@mail.gmail.com>
 <CAPkb-7B3geM2iydgmidq+gFh4oJvzbCj_eznQSvLRhi3LGgvCA@mail.gmail.com>
 <CAPkb-7C78wAAYrdfgZB65W=tJRumUb3qbVGVE1u28V7DTP82Ww@mail.gmail.com>
 <CAPkb-7A1RsiN=tv6YuggARbUx2u8EDOUyHc__BJ6iB=UFWxs4Q@mail.gmail.com>
 <CAPkb-7AQTQnuv9baaO=yEG0e+s0O1ppopafsCNoP8bSuCMysxg@mail.gmail.com>
 <CAPkb-7AXhoCrVnWv+pzbJGPW86mvzGmGuitqscqQ7AJFrriDRg@mail.gmail.com>
 <CAPkb-7BaGqybRDLRd01E65bmzoc-1ebnuYsEtYsSU8VLu5dp3A@mail.gmail.com>
 <CAPkb-7BAjMO2sdY=87J6S6yd8oecyr1gyJa_jqaQUy7=XU0oAw@mail.gmail.com>
 <CAPkb-7A5TgL+dL8D48sccHSCVcHWEah9sv3hZT-7j=kN4aKnYQ@mail.gmail.com>
 <CAPkb-7DtxSt=9vgBviZBSaxN57q=wkDJw+6m=RBmf01s9GtVXw@mail.gmail.com>
 <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>
Message-ID: <c70e5b4d-5363-6cbc-15a0-caca98672031@seacom.mu>



On 22/Jul/16 14:01, Baldur Norddahl wrote:

>
> Obviously I only need to increase my MTU by the size of the GRE header. But
> I am thinking is there any reason not to go all in and ask every peer to go
> to whatever max MTU they can support? My own equipment will do MTU of 9600
> bytes.

See the below:

    http://mailman.nanog.org/pipermail/nanog/2016-March/084598.html

You can reliably run Jumbo frames in your own network core, and also to
another network that can guarantee you the same (which would typically
be under some form of commercial, private arrangement like an NNI).

Across the Internet, 1,500 bytes is still safest, simply because that is
pretty much the standard. Trying to achieve Jumbo frames across an
Internet link (which includes links to your upstreams, links to your
peers and links to your customers) is an exercise in pain.

Mark.

From bill at herrin.us  Fri Jul 22 13:57:52 2016
From: bill at herrin.us (William Herrin)
Date: Fri, 22 Jul 2016 09:57:52 -0400
Subject: MTU
In-Reply-To: <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>
References: <CAPkb-7CRMNUK6Av-BBzUgMLh2YW0XfxDs4x4P4rJg6ookVNP=A@mail.gmail.com>
 <CAPkb-7BBOnWSgLkrOFGMkAp-PHyhxwD0cctmvsN+wWgzw+vp-Q@mail.gmail.com>
 <CAPkb-7CKUF76__dd9Rk2dtswbW82009A4yGY0ZMO4vTik9D0Jg@mail.gmail.com>
 <CAPkb-7BUTaims9cfAs+HKKu9cMZ-z6U0ppk0xTyovBOgi1vd=Q@mail.gmail.com>
 <CAPkb-7A0jXgq4=yyhkPhbw5Sxc_kg+fgr_Zk+N8maBPu+mn_Qg@mail.gmail.com>
 <CAPkb-7B6cav2LHgdCE6Ywq4pKgb1MqVjEgKoFZG+JzKf73cA8w@mail.gmail.com>
 <CAPkb-7CTi_ekX35OcjdwqfM+W-gdkfkfpLsHXxhH5bVr=nyv3A@mail.gmail.com>
 <CAPkb-7CnxtLuWWA+PDx2ba_xkaE54+Ei4NAbZp7TzvgdGi2Auw@mail.gmail.com>
 <CAPkb-7B3geM2iydgmidq+gFh4oJvzbCj_eznQSvLRhi3LGgvCA@mail.gmail.com>
 <CAPkb-7C78wAAYrdfgZB65W=tJRumUb3qbVGVE1u28V7DTP82Ww@mail.gmail.com>
 <CAPkb-7A1RsiN=tv6YuggARbUx2u8EDOUyHc__BJ6iB=UFWxs4Q@mail.gmail.com>
 <CAPkb-7AQTQnuv9baaO=yEG0e+s0O1ppopafsCNoP8bSuCMysxg@mail.gmail.com>
 <CAPkb-7AXhoCrVnWv+pzbJGPW86mvzGmGuitqscqQ7AJFrriDRg@mail.gmail.com>
 <CAPkb-7BaGqybRDLRd01E65bmzoc-1ebnuYsEtYsSU8VLu5dp3A@mail.gmail.com>
 <CAPkb-7BAjMO2sdY=87J6S6yd8oecyr1gyJa_jqaQUy7=XU0oAw@mail.gmail.com>
 <CAPkb-7A5TgL+dL8D48sccHSCVcHWEah9sv3hZT-7j=kN4aKnYQ@mail.gmail.com>
 <CAPkb-7DtxSt=9vgBviZBSaxN57q=wkDJw+6m=RBmf01s9GtVXw@mail.gmail.com>
 <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>
Message-ID: <CAP-guGUcE_wrbZdZX7rO2nN1GGREuqVrWfJ37CqY7MRLBZTTSw@mail.gmail.com>

On Fri, Jul 22, 2016 at 8:01 AM, Baldur Norddahl
<baldur.norddahl at gmail.com> wrote:
> What is best practice regarding choosing MTU on transit links?

Hi Baldur,

On a link containing only routers, you can safely increase the MTU to
any mutually agreed value with these caveats:

1. Not all equipment behaves well with large packets. It supposed to
but you know what they say.

2. No protocol guarantees that every device on the link has the same
MTU. It's a manual configuration task on each device and if the
maximum receive unit on any device should happen to be less than the
maximum transmit unit on any other, you will be intermittently
screwed.

This includes virtual links like the GRE tunnel. If you can guarantee
the GRE tunnel travels a 9k path, you can set a slightly smaller MTU
on the tunnel itself.


MTU should never be increased above 1500 on a link containing
workstations and servers unless you know for certain that packets
emitted on that link will never traverse the public Internet. Path MTU
discovery on the Internet is broken. It was a poor design - broke the
end to end principle - and over the years we've misimplemented it so
badly that it has no serious production-level of reliability.

Where practical, it's actually a good idea to detune your servers to a
1460 or lower packet size in order to avoid problems transiting those
parts of the Internet which have allowed themselves to fall beneath a
1500 byte MTU. This is often accomplished by asking the firewall to
adjust the TCP MSS value in flight.

Regards,
Bill Herrin



-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From mark.tinka at seacom.mu  Fri Jul 22 14:01:42 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Fri, 22 Jul 2016 16:01:42 +0200
Subject: MTU
In-Reply-To: <CAHBoRgU1oaEUe8taCp+vXYdzzP6Je9za=8mnmY9N=vgwOet7Aw@mail.gmail.com>
References: <CAPkb-7CRMNUK6Av-BBzUgMLh2YW0XfxDs4x4P4rJg6ookVNP=A@mail.gmail.com>
 <CAPkb-7CnxtLuWWA+PDx2ba_xkaE54+Ei4NAbZp7TzvgdGi2Auw@mail.gmail.com>
 <CAPkb-7B3geM2iydgmidq+gFh4oJvzbCj_eznQSvLRhi3LGgvCA@mail.gmail.com>
 <CAPkb-7C78wAAYrdfgZB65W=tJRumUb3qbVGVE1u28V7DTP82Ww@mail.gmail.com>
 <CAPkb-7A1RsiN=tv6YuggARbUx2u8EDOUyHc__BJ6iB=UFWxs4Q@mail.gmail.com>
 <CAPkb-7AQTQnuv9baaO=yEG0e+s0O1ppopafsCNoP8bSuCMysxg@mail.gmail.com>
 <CAPkb-7AXhoCrVnWv+pzbJGPW86mvzGmGuitqscqQ7AJFrriDRg@mail.gmail.com>
 <CAPkb-7BaGqybRDLRd01E65bmzoc-1ebnuYsEtYsSU8VLu5dp3A@mail.gmail.com>
 <CAPkb-7BAjMO2sdY=87J6S6yd8oecyr1gyJa_jqaQUy7=XU0oAw@mail.gmail.com>
 <CAPkb-7A5TgL+dL8D48sccHSCVcHWEah9sv3hZT-7j=kN4aKnYQ@mail.gmail.com>
 <CAPkb-7DtxSt=9vgBviZBSaxN57q=wkDJw+6m=RBmf01s9GtVXw@mail.gmail.com>
 <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>
 <c70e5b4d-5363-6cbc-15a0-caca98672031@seacom.mu>
 <CAHBoRgU1oaEUe8taCp+vXYdzzP6Je9za=8mnmY9N=vgwOet7Aw@mail.gmail.com>
Message-ID: <9a199f32-464c-7a7f-b433-1235281efdd8@seacom.mu>



On 22/Jul/16 15:42, Chris Kane wrote:

>
> My experience has been making a view phone calls and agreeing on 9,000
> is simple enough. I've only experienced one situation for which the
> MTU must match and that is on OSPF neighbor relationships, for which
> John T. Moy's book (OSPF - Anatomy of an Internet Routing Protocol)
> clearly explains why MTU became an issue during development of that
> protocol. As more and more of us choose or are forced to support
> 'jumbo' frames to accommodate Layer 2 extensions (DCI [Data Center
> Interconnects]) I find myself helping my customers work with their
> carriers to ensure that jumbo frames are supported. And frequently
> remind them to inquire that they be enabled not only on the primary
> path/s but any possible back up path as well. I've had customers
> experience DCI-related outages because their provider performed
> maintenance on the primary path and the re-route was sent across a
> path that did not support jumbo frames.

DCI links tend to be private in nature, and 100% on-net or off-net with
guarantees (NNI).

The question here is about the wider Internet.

>
> As always, YMMV but I personally feel having the discussions and
> implementation with your internal network team as well as all of your
> providers is time well spent.

I don't disagree.

The issue comes when other networks beyond your provider, and their
providers/peers, whose providers/peers, and their providers/peers, is
something you cannot control.

This falls into the same category of "Can QoS markings be honored across
the Internet" cases.

Mark.

From hugo at slabnet.com  Fri Jul 22 14:53:00 2016
From: hugo at slabnet.com (Hugo Slabbert)
Date: Fri, 22 Jul 2016 07:53:00 -0700
Subject: MTU
In-Reply-To: <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>
References: <CAPkb-7B3geM2iydgmidq+gFh4oJvzbCj_eznQSvLRhi3LGgvCA@mail.gmail.com>
 <CAPkb-7C78wAAYrdfgZB65W=tJRumUb3qbVGVE1u28V7DTP82Ww@mail.gmail.com>
 <CAPkb-7A1RsiN=tv6YuggARbUx2u8EDOUyHc__BJ6iB=UFWxs4Q@mail.gmail.com>
 <CAPkb-7AQTQnuv9baaO=yEG0e+s0O1ppopafsCNoP8bSuCMysxg@mail.gmail.com>
 <CAPkb-7AXhoCrVnWv+pzbJGPW86mvzGmGuitqscqQ7AJFrriDRg@mail.gmail.com>
 <CAPkb-7BaGqybRDLRd01E65bmzoc-1ebnuYsEtYsSU8VLu5dp3A@mail.gmail.com>
 <CAPkb-7BAjMO2sdY=87J6S6yd8oecyr1gyJa_jqaQUy7=XU0oAw@mail.gmail.com>
 <CAPkb-7A5TgL+dL8D48sccHSCVcHWEah9sv3hZT-7j=kN4aKnYQ@mail.gmail.com>
 <CAPkb-7DtxSt=9vgBviZBSaxN57q=wkDJw+6m=RBmf01s9GtVXw@mail.gmail.com>
 <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>
Message-ID: <20160722145300.GA1207@bamboo.slabnet.com>


On Fri 2016-Jul-22 14:01:36 +0200, Baldur Norddahl <baldur.norddahl at gmail.com> wrote:

>Hi
>
>What is best practice regarding choosing MTU on transit links?
>
>Until now we have used the default of 1500 bytes. I now have a project were
>we peer directly with another small ISP. However we need a backup so we
>figured a GRE tunnel on a common IP transit carrier would work. We want to
>avoid the troubles you get by having an effective MTU smaller than 1500
>inside the tunnel, so the IP transit carrier agreed to configure a MTU of
>9216.
>
>Obviously I only need to increase my MTU by the size of the GRE header. But
>I am thinking is there any reason not to go all in and ask every peer to go
>to whatever max MTU they can support? My own equipment will do MTU of 9600
>bytes.

If you're just doing this for the GRE overhead and given that you're 
talking about backup over transit and possibly $deity-knows-where paths, 
TBH I might just lean towards pinning your L3 MTU inside the tunnel to 1500 
bytes and configuring IP fragmentation post-encap.  Not pretty, but 
probably fewer chances for WTF moments than trying to push >1500 on a 
transit path.

This *might* be coloured by my past fights with having to force GRE through 
a 1500-byte path and trying to make that transparent to transit traffic, 
but there you have it...

>On the other hand, none of my customers will see any actual difference
>because they are end users with CPE equipment that expects a 1500 byte MTU.
>Trying to deliver jumbo frames to the end users is probably going to end
>badly.
>
>Regards,
>
>Baldur

-- 
Hugo Slabbert       | email, xmpp/jabber: hugo at slabnet.com
pgp key: B178313E   | also on Signal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160722/e6707ead/attachment.pgp>

From ricardofbferreira at gmail.com  Fri Jul 22 08:54:48 2016
From: ricardofbferreira at gmail.com (Ricardo Ferreira)
Date: Fri, 22 Jul 2016 10:54:48 +0200
Subject: IPv6 Deployment for Mobile Subscribers
Message-ID: <CAE0OVL9f9JEMDWx3-DzH7-nQUbWJFGAE5oWfWN-sX6MXhMtq_A@mail.gmail.com>

Is there anyone here working in an ISP where IPv6 is deployed?
We are starting to plan the roll-out IPv6 to mobile subscribers (phones) I
am interesting in knowing the mask you use for the assignment; whether it
is /64 or /128.

In RFC 3177, it says:
3. Address Delegation Recommendations

   The IESG and the IAB recommend the allocations for the boundary
   between the public and the private topology to follow those general
   rules:

      -  /48 in the general case, except for very large subscribers.
      -  /64 when it is known that one and only one subnet is needed by
         design.
      -  /128 when it is absolutely known that one and only one device
         is connecting.

Basically a sole device will be connecting to the internet so I am
wondering if this rule is follwed.

Cheers

-- 
Ricardo Ferreira

From bernat at luffy.cx  Fri Jul 22 13:01:50 2016
From: bernat at luffy.cx (Vincent Bernat)
Date: Fri, 22 Jul 2016 15:01:50 +0200
Subject: MTU
In-Reply-To: <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>
 (Baldur Norddahl's message of "Fri, 22 Jul 2016 14:01:36 +0200")
References: <CAPkb-7CRMNUK6Av-BBzUgMLh2YW0XfxDs4x4P4rJg6ookVNP=A@mail.gmail.com>
 <CAPkb-7BBOnWSgLkrOFGMkAp-PHyhxwD0cctmvsN+wWgzw+vp-Q@mail.gmail.com>
 <CAPkb-7CKUF76__dd9Rk2dtswbW82009A4yGY0ZMO4vTik9D0Jg@mail.gmail.com>
 <CAPkb-7BUTaims9cfAs+HKKu9cMZ-z6U0ppk0xTyovBOgi1vd=Q@mail.gmail.com>
 <CAPkb-7A0jXgq4=yyhkPhbw5Sxc_kg+fgr_Zk+N8maBPu+mn_Qg@mail.gmail.com>
 <CAPkb-7B6cav2LHgdCE6Ywq4pKgb1MqVjEgKoFZG+JzKf73cA8w@mail.gmail.com>
 <CAPkb-7CTi_ekX35OcjdwqfM+W-gdkfkfpLsHXxhH5bVr=nyv3A@mail.gmail.com>
 <CAPkb-7CnxtLuWWA+PDx2ba_xkaE54+Ei4NAbZp7TzvgdGi2Auw@mail.gmail.com>
 <CAPkb-7B3geM2iydgmidq+gFh4oJvzbCj_eznQSvLRhi3LGgvCA@mail.gmail.com>
 <CAPkb-7C78wAAYrdfgZB65W=tJRumUb3qbVGVE1u28V7DTP82Ww@mail.gmail.com>
 <CAPkb-7A1RsiN=tv6YuggARbUx2u8EDOUyHc__BJ6iB=UFWxs4Q@mail.gmail.com>
 <CAPkb-7AQTQnuv9baaO=yEG0e+s0O1ppopafsCNoP8bSuCMysxg@mail.gmail.com>
 <CAPkb-7AXhoCrVnWv+pzbJGPW86mvzGmGuitqscqQ7AJFrriDRg@mail.gmail.com>
 <CAPkb-7BaGqybRDLRd01E65bmzoc-1ebnuYsEtYsSU8VLu5dp3A@mail.gmail.com>
 <CAPkb-7BAjMO2sdY=87J6S6yd8oecyr1gyJa_jqaQUy7=XU0oAw@mail.gmail.com>
 <CAPkb-7A5TgL+dL8D48sccHSCVcHWEah9sv3hZT-7j=kN4aKnYQ@mail.gmail.com>
 <CAPkb-7DtxSt=9vgBviZBSaxN57q=wkDJw+6m=RBmf01s9GtVXw@mail.gmail.com>
 <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>
Message-ID: <877fcdsu69.fsf@zoro.exoscale.ch>

 ? 22 juillet 2016 14:01 CEST, Baldur Norddahl <baldur.norddahl at gmail.com>?:

> Until now we have used the default of 1500 bytes. I now have a project were
> we peer directly with another small ISP. However we need a backup so we
> figured a GRE tunnel on a common IP transit carrier would work. We want to
> avoid the troubles you get by having an effective MTU smaller than 1500
> inside the tunnel, so the IP transit carrier agreed to configure a MTU of
> 9216.
>
> Obviously I only need to increase my MTU by the size of the GRE header. But
> I am thinking is there any reason not to go all in and ask every peer to go
> to whatever max MTU they can support? My own equipment will do MTU of 9600
> bytes.

You should always match the MTU of the remote end. So, if your transit
carrier configured 9126 on its side, you should do the same on
yours. There is no MTU discovery at the L2 layer: if you setup the MTU
of your interface at 9600 and you happen to route a 9500-byte packets,
it will be silently dropped by your transit carrier.
-- 
Test input for validity and plausibility.
            - The Elements of Programming Style (Kernighan & Plauger)

From ccie14430 at gmail.com  Fri Jul 22 13:42:38 2016
From: ccie14430 at gmail.com (Chris Kane)
Date: Fri, 22 Jul 2016 09:42:38 -0400
Subject: MTU
In-Reply-To: <c70e5b4d-5363-6cbc-15a0-caca98672031@seacom.mu>
References: <CAPkb-7CRMNUK6Av-BBzUgMLh2YW0XfxDs4x4P4rJg6ookVNP=A@mail.gmail.com>
 <CAPkb-7B6cav2LHgdCE6Ywq4pKgb1MqVjEgKoFZG+JzKf73cA8w@mail.gmail.com>
 <CAPkb-7CTi_ekX35OcjdwqfM+W-gdkfkfpLsHXxhH5bVr=nyv3A@mail.gmail.com>
 <CAPkb-7CnxtLuWWA+PDx2ba_xkaE54+Ei4NAbZp7TzvgdGi2Auw@mail.gmail.com>
 <CAPkb-7B3geM2iydgmidq+gFh4oJvzbCj_eznQSvLRhi3LGgvCA@mail.gmail.com>
 <CAPkb-7C78wAAYrdfgZB65W=tJRumUb3qbVGVE1u28V7DTP82Ww@mail.gmail.com>
 <CAPkb-7A1RsiN=tv6YuggARbUx2u8EDOUyHc__BJ6iB=UFWxs4Q@mail.gmail.com>
 <CAPkb-7AQTQnuv9baaO=yEG0e+s0O1ppopafsCNoP8bSuCMysxg@mail.gmail.com>
 <CAPkb-7AXhoCrVnWv+pzbJGPW86mvzGmGuitqscqQ7AJFrriDRg@mail.gmail.com>
 <CAPkb-7BaGqybRDLRd01E65bmzoc-1ebnuYsEtYsSU8VLu5dp3A@mail.gmail.com>
 <CAPkb-7BAjMO2sdY=87J6S6yd8oecyr1gyJa_jqaQUy7=XU0oAw@mail.gmail.com>
 <CAPkb-7A5TgL+dL8D48sccHSCVcHWEah9sv3hZT-7j=kN4aKnYQ@mail.gmail.com>
 <CAPkb-7DtxSt=9vgBviZBSaxN57q=wkDJw+6m=RBmf01s9GtVXw@mail.gmail.com>
 <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>
 <c70e5b4d-5363-6cbc-15a0-caca98672031@seacom.mu>
Message-ID: <CAHBoRgU1oaEUe8taCp+vXYdzzP6Je9za=8mnmY9N=vgwOet7Aw@mail.gmail.com>

This topic seems to come up more lately. Much like it did often during
IPSec related deployments. I simplify on 9,000 as an easy number and I
don't have to split hairs (read 9,214 v 9,216) that some vendors have.

My experience has been making a view phone calls and agreeing on 9,000 is
simple enough. I've only experienced one situation for which the MTU must
match and that is on OSPF neighbor relationships, for which John T. Moy's
book (OSPF - Anatomy of an Internet Routing Protocol) clearly explains why
MTU became an issue during development of that protocol. As more and more
of us choose or are forced to support 'jumbo' frames to accommodate Layer 2
extensions (DCI [Data Center Interconnects]) I find myself helping my
customers work with their carriers to ensure that jumbo frames are
supported. And frequently remind them to inquire that they be enabled not
only on the primary path/s but any possible back up path as well. I've had
customers experience DCI-related outages because their provider performed
maintenance on the primary path and the re-route was sent across a path
that did not support jumbo frames.

As always, YMMV but I personally feel having the discussions and
implementation with your internal network team as well as all of your
providers is time well spent.

Later,
-chris









On Fri, Jul 22, 2016 at 8:53 AM, Mark Tinka <mark.tinka at seacom.mu> wrote:

>
>
> On 22/Jul/16 14:01, Baldur Norddahl wrote:
>
> >
> > Obviously I only need to increase my MTU by the size of the GRE header.
> But
> > I am thinking is there any reason not to go all in and ask every peer to
> go
> > to whatever max MTU they can support? My own equipment will do MTU of
> 9600
> > bytes.
>
> See the below:
>
>     http://mailman.nanog.org/pipermail/nanog/2016-March/084598.html
>
> You can reliably run Jumbo frames in your own network core, and also to
> another network that can guarantee you the same (which would typically
> be under some form of commercial, private arrangement like an NNI).
>
> Across the Internet, 1,500 bytes is still safest, simply because that is
> pretty much the standard. Trying to achieve Jumbo frames across an
> Internet link (which includes links to your upstreams, links to your
> peers and links to your customers) is an exercise in pain.
>
> Mark.
>



-- 
Chris Kane
CCIE 14430
614 329 1906

From saad17621 at gmail.com  Fri Jul 22 14:48:08 2016
From: saad17621 at gmail.com (Saad Abdullah)
Date: Sat, 23 Jul 2016 00:48:08 +1000
Subject: MTU
In-Reply-To: <CAOOLXZigQiwG-aRhne-R96gbBciSBpn6E6HYA6Xi94rcigmR1Q@mail.gmail.com>
References: <CAPkb-7CRMNUK6Av-BBzUgMLh2YW0XfxDs4x4P4rJg6ookVNP=A@mail.gmail.com>
 <CAPkb-7BBOnWSgLkrOFGMkAp-PHyhxwD0cctmvsN+wWgzw+vp-Q@mail.gmail.com>
 <CAPkb-7CKUF76__dd9Rk2dtswbW82009A4yGY0ZMO4vTik9D0Jg@mail.gmail.com>
 <CAPkb-7BUTaims9cfAs+HKKu9cMZ-z6U0ppk0xTyovBOgi1vd=Q@mail.gmail.com>
 <CAPkb-7A0jXgq4=yyhkPhbw5Sxc_kg+fgr_Zk+N8maBPu+mn_Qg@mail.gmail.com>
 <CAPkb-7B6cav2LHgdCE6Ywq4pKgb1MqVjEgKoFZG+JzKf73cA8w@mail.gmail.com>
 <CAPkb-7CTi_ekX35OcjdwqfM+W-gdkfkfpLsHXxhH5bVr=nyv3A@mail.gmail.com>
 <CAPkb-7CnxtLuWWA+PDx2ba_xkaE54+Ei4NAbZp7TzvgdGi2Auw@mail.gmail.com>
 <CAPkb-7B3geM2iydgmidq+gFh4oJvzbCj_eznQSvLRhi3LGgvCA@mail.gmail.com>
 <CAPkb-7C78wAAYrdfgZB65W=tJRumUb3qbVGVE1u28V7DTP82Ww@mail.gmail.com>
 <CAPkb-7A1RsiN=tv6YuggARbUx2u8EDOUyHc__BJ6iB=UFWxs4Q@mail.gmail.com>
 <CAPkb-7AQTQnuv9baaO=yEG0e+s0O1ppopafsCNoP8bSuCMysxg@mail.gmail.com>
 <CAPkb-7AXhoCrVnWv+pzbJGPW86mvzGmGuitqscqQ7AJFrriDRg@mail.gmail.com>
 <CAPkb-7BaGqybRDLRd01E65bmzoc-1ebnuYsEtYsSU8VLu5dp3A@mail.gmail.com>
 <CAPkb-7BAjMO2sdY=87J6S6yd8oecyr1gyJa_jqaQUy7=XU0oAw@mail.gmail.com>
 <CAPkb-7A5TgL+dL8D48sccHSCVcHWEah9sv3hZT-7j=kN4aKnYQ@mail.gmail.com>
 <CAPkb-7DtxSt=9vgBviZBSaxN57q=wkDJw+6m=RBmf01s9GtVXw@mail.gmail.com>
 <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>
 <CAGfMMhxOT0J9ER7X-k3vRhTLZ9tSq9qZZSMoYFCE7-i2G8185g@mail.gmail.com>
 <CAOOLXZigQiwG-aRhne-R96gbBciSBpn6E6HYA6Xi94rcigmR1Q@mail.gmail.com>
Message-ID: <CAOOLXZi38KwoRsW6VFO+zw3jd9Cjg80G3u6m-cpRqCMOA0WCPQ@mail.gmail.com>

Worth reading this on choosing MTU on transit link.

http://blog.apnic.net/2014/12/15/ip-mtu-and-tcp-mss-missmatch-an-evil-for-network-performance/

-Sad



>>
>> On Fri, Jul 22, 2016 at 10:01 PM, Baldur Norddahl <
>> baldur.norddahl at gmail.com> wrote:
>>
>>> Hi
>>>
>>> What is best practice regarding choosing MTU on transit links?
>>>
>>> Until now we have used the default of 1500 bytes. I now have a project
>>> were
>>> we peer directly with another small ISP. However we need a backup so we
>>> figured a GRE tunnel on a common IP transit carrier would work. We want
>>> to
>>> avoid the troubles you get by having an effective MTU smaller than 1500
>>> inside the tunnel, so the IP transit carrier agreed to configure a MTU of
>>> 9216.
>>>
>>> Obviously I only need to increase my MTU by the size of the GRE header.
>>> But
>>> I am thinking is there any reason not to go all in and ask every peer to
>>> go
>>> to whatever max MTU they can support? My own equipment will do MTU of
>>> 9600
>>> bytes.
>>>
>>> On the other hand, none of my customers will see any actual difference
>>> because they are end users with CPE equipment that expects a 1500 byte
>>> MTU.
>>> Trying to deliver jumbo frames to the end users is probably going to end
>>> badly.
>>>
>>> Regards,
>>>
>>> Baldur
>>>
>>
>>
>

From hvgeekwtrvl at gmail.com  Fri Jul 22 16:57:58 2016
From: hvgeekwtrvl at gmail.com (james machado)
Date: Fri, 22 Jul 2016 09:57:58 -0700
Subject: IPv6 Deployment for Mobile Subscribers
In-Reply-To: <CAE0OVL9f9JEMDWx3-DzH7-nQUbWJFGAE5oWfWN-sX6MXhMtq_A@mail.gmail.com>
References: <CAE0OVL9f9JEMDWx3-DzH7-nQUbWJFGAE5oWfWN-sX6MXhMtq_A@mail.gmail.com>
Message-ID: <CADVasu7w=CtDjXCNm186UqoALh-cK3inFxO8yMjNJMCbzr6wEA@mail.gmail.com>

Ricardo,

I know from previous discussions on this list that Android phones are
looking for DHCPD leases and not /128's or /64's.  From what I remember
this is due to the current requirement for multiple ipv6 subnets for
various applications (vpns among others) to function correctly.  As a
result Google has disabled Android from receiving a DHCP lease as it wasn't
long enough.

if you look back about 6 months there is probably 100+ posts on the subject.

All I really know is that I can not provide an ipv6 dhcp lease to an
android phone and have it receive the address.


james

On Fri, Jul 22, 2016 at 1:54 AM, Ricardo Ferreira <
ricardofbferreira at gmail.com> wrote:

> Is there anyone here working in an ISP where IPv6 is deployed?
> We are starting to plan the roll-out IPv6 to mobile subscribers (phones) I
> am interesting in knowing the mask you use for the assignment; whether it
> is /64 or /128.
>
> In RFC 3177, it says:
> 3. Address Delegation Recommendations
>
>    The IESG and the IAB recommend the allocations for the boundary
>    between the public and the private topology to follow those general
>    rules:
>
>       -  /48 in the general case, except for very large subscribers.
>       -  /64 when it is known that one and only one subnet is needed by
>          design.
>       -  /128 when it is absolutely known that one and only one device
>          is connecting.
>
> Basically a sole device will be connecting to the internet so I am
> wondering if this rule is follwed.
>
> Cheers
>
> --
> Ricardo Ferreira
>

From sryan at arbor.net  Fri Jul 22 16:59:44 2016
From: sryan at arbor.net (Ryan, Spencer)
Date: Fri, 22 Jul 2016 16:59:44 +0000
Subject: IPv6 Deployment for Mobile Subscribers
In-Reply-To: <CADVasu7w=CtDjXCNm186UqoALh-cK3inFxO8yMjNJMCbzr6wEA@mail.gmail.com>
References: <CAE0OVL9f9JEMDWx3-DzH7-nQUbWJFGAE5oWfWN-sX6MXhMtq_A@mail.gmail.com>,
 <CADVasu7w=CtDjXCNm186UqoALh-cK3inFxO8yMjNJMCbzr6wEA@mail.gmail.com>
Message-ID: <BY1PR0101MB1205B2CA1C728DA4A7A21666B00A0@BY1PR0101MB1205.prod.exchangelabs.com>

As far as I'm aware Android still today does not support DHCPv6.


https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems

________________________________
From: NANOG <nanog-bounces at nanog.org> on behalf of james machado <hvgeekwtrvl at gmail.com>
Sent: Friday, July 22, 2016 12:57:58 PM
To: Ricardo Ferreira
Cc: NANOG
Subject: Re: IPv6 Deployment for Mobile Subscribers

Ricardo,

I know from previous discussions on this list that Android phones are
looking for DHCPD leases and not /128's or /64's.  From what I remember
this is due to the current requirement for multiple ipv6 subnets for
various applications (vpns among others) to function correctly.  As a
result Google has disabled Android from receiving a DHCP lease as it wasn't
long enough.

if you look back about 6 months there is probably 100+ posts on the subject.

All I really know is that I can not provide an ipv6 dhcp lease to an
android phone and have it receive the address.


james

On Fri, Jul 22, 2016 at 1:54 AM, Ricardo Ferreira <
ricardofbferreira at gmail.com> wrote:

> Is there anyone here working in an ISP where IPv6 is deployed?
> We are starting to plan the roll-out IPv6 to mobile subscribers (phones) I
> am interesting in knowing the mask you use for the assignment; whether it
> is /64 or /128.
>
> In RFC 3177, it says:
> 3. Address Delegation Recommendations
>
>    The IESG and the IAB recommend the allocations for the boundary
>    between the public and the private topology to follow those general
>    rules:
>
>       -  /48 in the general case, except for very large subscribers.
>       -  /64 when it is known that one and only one subnet is needed by
>          design.
>       -  /128 when it is absolutely known that one and only one device
>          is connecting.
>
> Basically a sole device will be connecting to the internet so I am
> wondering if this rule is follwed.
>
> Cheers
>
> --
> Ricardo Ferreira
>

From Grzegorz at Janoszka.pl  Fri Jul 22 17:37:17 2016
From: Grzegorz at Janoszka.pl (Grzegorz Janoszka)
Date: Fri, 22 Jul 2016 19:37:17 +0200
Subject: MTU
In-Reply-To: <CAP-guGUcE_wrbZdZX7rO2nN1GGREuqVrWfJ37CqY7MRLBZTTSw@mail.gmail.com>
References: <CAPkb-7CRMNUK6Av-BBzUgMLh2YW0XfxDs4x4P4rJg6ookVNP=A@mail.gmail.com>
 <CAPkb-7CTi_ekX35OcjdwqfM+W-gdkfkfpLsHXxhH5bVr=nyv3A@mail.gmail.com>
 <CAPkb-7CnxtLuWWA+PDx2ba_xkaE54+Ei4NAbZp7TzvgdGi2Auw@mail.gmail.com>
 <CAPkb-7B3geM2iydgmidq+gFh4oJvzbCj_eznQSvLRhi3LGgvCA@mail.gmail.com>
 <CAPkb-7C78wAAYrdfgZB65W=tJRumUb3qbVGVE1u28V7DTP82Ww@mail.gmail.com>
 <CAPkb-7A1RsiN=tv6YuggARbUx2u8EDOUyHc__BJ6iB=UFWxs4Q@mail.gmail.com>
 <CAPkb-7AQTQnuv9baaO=yEG0e+s0O1ppopafsCNoP8bSuCMysxg@mail.gmail.com>
 <CAPkb-7AXhoCrVnWv+pzbJGPW86mvzGmGuitqscqQ7AJFrriDRg@mail.gmail.com>
 <CAPkb-7BaGqybRDLRd01E65bmzoc-1ebnuYsEtYsSU8VLu5dp3A@mail.gmail.com>
 <CAPkb-7BAjMO2sdY=87J6S6yd8oecyr1gyJa_jqaQUy7=XU0oAw@mail.gmail.com>
 <CAPkb-7A5TgL+dL8D48sccHSCVcHWEah9sv3hZT-7j=kN4aKnYQ@mail.gmail.com>
 <CAPkb-7DtxSt=9vgBviZBSaxN57q=wkDJw+6m=RBmf01s9GtVXw@mail.gmail.com>
 <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>
 <CAP-guGUcE_wrbZdZX7rO2nN1GGREuqVrWfJ37CqY7MRLBZTTSw@mail.gmail.com>
Message-ID: <520e997e-9c83-3d1c-b99b-b818e3ea3b16@Janoszka.pl>

On 2016-07-22 15:57, William Herrin wrote:
> On a link containing only routers, you can safely increase the MTU to
> any mutually agreed value with these caveats:

What I noticed a few years ago was that BGP convergence time was faster 
with higher MTU.
Full BGP table load took twice less time on MTU 9192 than on 1500.
Of course BGP has to be allowed to use higher MTU.

Anyone else observed something similar?

-- 
Grzegorz Janoszka

From cscora at apnic.net  Fri Jul 22 18:01:39 2016
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 23 Jul 2016 04:01:39 +1000 (AEST)
Subject: Weekly Routing Table Report
Message-ID: <20160722180139.B0691AB44B@thyme.apnic.net>

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG,
SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG.

Daily listings are sent to bgp-stats at lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith <pfsinoz at gmail.com>.

Routing Table Report   04:00 +10GMT Sat 23 Jul, 2016

Report Website:     http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              605817
    Prefixes after maximum aggregation (per Origin AS):          218806
    Deaggregation factor:                                          2.77
    Unique aggregates announced (without unneeded subnets):      294816
Total ASes present in the Internet Routing Table:                 54378
    Prefixes per ASN:                                             11.14
Origin-only ASes present in the Internet Routing Table:           36517
Origin ASes announcing only one prefix:                           15523
Transit ASes present in the Internet Routing Table:                6452
Transit-only ASes present in the Internet Routing Table:            163
Average AS path length visible in the Internet Routing Table:       4.3
    Max AS path length visible:                                      54
    Max AS path prepend of ASN ( 55644)                              51
Prefixes from unregistered ASNs in the Routing Table:                61
    Unregistered ASNs in the Routing Table:                          14
Number of 32-bit ASNs allocated by the RIRs:                      14745
Number of 32-bit ASNs visible in the Routing Table:               11409
Prefixes from 32-bit ASNs in the Routing Table:                   45128
Number of bogon 32-bit ASNs visible in the Routing Table:            15
Special use prefixes present in the Routing Table:                    0
Prefixes being announced from unallocated address space:            359
Number of addresses announced to Internet:                   2819713764
    Equivalent to 168 /8s, 17 /16s and 106 /24s
    Percentage of available address space announced:               76.2
    Percentage of allocated address space announced:               76.2
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               98.2
Total number of prefixes smaller than registry allocations:      197336

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                   156415
    Total APNIC prefixes after maximum aggregation:               42755
    APNIC Deaggregation factor:                                    3.66
Prefixes being announced from the APNIC address blocks:          168745
    Unique aggregates announced from the APNIC address blocks:    68054
APNIC Region origin ASes present in the Internet Routing Table:    5202
    APNIC Prefixes per ASN:                                       32.44
APNIC Region origin ASes announcing only one prefix:               1183
APNIC Region transit ASes present in the Internet Routing Table:    934
Average APNIC Region AS path length visible:                        4.4
    Max APNIC Region AS path length visible:                         54
Number of APNIC region 32-bit ASNs visible in the Routing Table:   2238
Number of APNIC addresses announced to Internet:              759062340
    Equivalent to 45 /8s, 62 /16s and 95 /24s
    Percentage of available APNIC address space announced:         88.7

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 63488-64098, 64297-64395, 131072-137529
APNIC Address Blocks     1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
                        49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
                       106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
                       116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
                       123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
                       163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
                       203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
                       222/8, 223/8,

ARIN Region Analysis Summary
----------------------------

Prefixes being announced by ARIN Region ASes:                    182907
    Total ARIN prefixes after maximum aggregation:                89306
    ARIN Deaggregation factor:                                     2.05
Prefixes being announced from the ARIN address blocks:           188607
    Unique aggregates announced from the ARIN address blocks:     88629
ARIN Region origin ASes present in the Internet Routing Table:    16283
    ARIN Prefixes per ASN:                                        11.58
ARIN Region origin ASes announcing only one prefix:                5773
ARIN Region transit ASes present in the Internet Routing Table:    1703
Average ARIN Region AS path length visible:                         3.8
    Max ARIN Region AS path length visible:                          23
Number of ARIN region 32-bit ASNs visible in the Routing Table:    1345
Number of ARIN addresses announced to Internet:              1103342816
    Equivalent to 65 /8s, 195 /16s and 172 /24s
    Percentage of available ARIN address space announced:          58.4

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 62464-63487, 64198-64296, 393216-397212
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  45/8,  47/8,  48/8,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/8,  63/8,  64/8,
                        65/8,  66/8,  67/8,  68/8,  69/8,  70/8,  71/8,
                        72/8,  73/8,  74/8,  75/8,  76/8,  96/8,  97/8,
                        98/8,  99/8, 100/8, 104/8, 107/8, 108/8, 128/8,
                       129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8,
                       137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8,
                       146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8,
                       157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8,
                       165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8,
                       173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8,
                       205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8,
                       216/8,

RIPE Region Analysis Summary
----------------------------

Prefixes being announced by RIPE Region ASes:                    145200
    Total RIPE prefixes after maximum aggregation:                71268
    RIPE Deaggregation factor:                                     2.04
Prefixes being announced from the RIPE address blocks:           154819
    Unique aggregates announced from the RIPE address blocks:     95081
RIPE Region origin ASes present in the Internet Routing Table:    18096
    RIPE Prefixes per ASN:                                         8.56
RIPE Region origin ASes announcing only one prefix:                7829
RIPE Region transit ASes present in the Internet Routing Table:    3002
Average RIPE Region AS path length visible:                         4.4
    Max RIPE Region AS path length visible:                          27
Number of RIPE region 32-bit ASNs visible in the Routing Table:    4936
Number of RIPE addresses announced to Internet:               705966464
    Equivalent to 42 /8s, 20 /16s and 49 /24s
    Percentage of available RIPE address space announced:         102.6

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       59392-61439, 61952-62463, 196608-204287
RIPE Address Blocks      2/8,   5/8,  25/8,  31/8,  37/8,  46/8,  51/8,
                        62/8,  77/8,  78/8,  79/8,  80/8,  81/8,  82/8,
                        83/8,  84/8,  85/8,  86/8,  87/8,  88/8,  89/8,
                        90/8,  91/8,  92/8,  93/8,  94/8,  95/8, 109/8,
                       141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8,
                       193/8, 194/8, 195/8, 212/8, 213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   61695
    Total LACNIC prefixes after maximum aggregation:              12258
    LACNIC Deaggregation factor:                                   5.03
Prefixes being announced from the LACNIC address blocks:          76891
    Unique aggregates announced from the LACNIC address blocks:   36669
LACNIC Region origin ASes present in the Internet Routing Table:   2485
    LACNIC Prefixes per ASN:                                      30.94
LACNIC Region origin ASes announcing only one prefix:               568
LACNIC Region transit ASes present in the Internet Routing Table:   572
Average LACNIC Region AS path length visible:                       4.8
    Max LACNIC Region AS path length visible:                        22
Number of LACNIC region 32-bit ASNs visible in the Routing Table:  2653
Number of LACNIC addresses announced to Internet:             170131520
    Equivalent to 10 /8s, 36 /16s and 0 /24s
    Percentage of available LACNIC address space announced:       101.4

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       61440-61951, 64099-64197, 262144-265628 + ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       191/8, 200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                  14410
    Total AfriNIC prefixes after maximum aggregation:              3209
    AfriNIC Deaggregation factor:                                  4.49
Prefixes being announced from the AfriNIC address blocks:         16396
    Unique aggregates announced from the AfriNIC address blocks:   6052
AfriNIC Region origin ASes present in the Internet Routing Table:   733
    AfriNIC Prefixes per ASN:                                     22.37
AfriNIC Region origin ASes announcing only one prefix:              170
AfriNIC Region transit ASes present in the Internet Routing Table:  172
Average AfriNIC Region AS path length visible:                      4.6
    Max AfriNIC Region AS path length visible:                       19
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:  237
Number of AfriNIC addresses announced to Internet:             80888832
    Equivalent to 4 /8s, 210 /16s and 68 /24s
    Percentage of available AfriNIC address space announced:       80.4

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 154/8, 196/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4538     5560       4191          75   ERX-CERNET-BKB China Education and Rese
 7545     3425        384         253   TPG-INTERNET-AP TPG Telecom Limited, AU
 4766     3177      11145        1126   KIXS-AS-KR Korea Telecom, KR
17974     2935        904          78   TELKOMNET-AS2-AP PT Telekomunikasi Indo
 9829     2564       1487         522   BSNL-NIB National Internet Backbone, IN
 1659     2493       1466          38   ERX-TANET-ASN1 Taiwan Academic Network 
 9808     2160       8761          40   CMNET-GD Guangdong Mobile Communication
 4755     2078        431         243   TATACOMM-AS TATA Communications formerl
 4808     1718       2318         556   CHINA169-BJ China Unicom Beijing Provin
38197     1493         92         275   SUNHK-DATA-AS-AP Sun Network (Hong Kong

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC

ARIN Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
22773     3503       2965         144   ASN-CXA-ALL-CCI-22773-RDC - Cox Communi
18566     2195        405         110   MEGAPATH5-US - MegaPath Corporation, US
 6389     2182       3671          41   BELLSOUTH-NET-BLK - BellSouth.net Inc.,
20115     1931       1952         409   CHARTER-NET-HKY-NC - Charter Communicat
30036     1715        342         385   MEDIACOM-ENTERPRISE-BUSINESS - Mediacom
  209     1708       5083         651   CENTURYLINK-US-LEGACY-QWEST - Qwest Com
 6983     1687        849         228   ITCDELTA - Earthlink, Inc., US
 7018     1347      20075        1001   ATT-INTERNET4 - AT&T Services, Inc., US
11492     1339        239         558   CABLEONE - CABLE ONE, INC., US
16509     1332       2474         423   AMAZON-02 - Amazon.com, Inc., US

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN

RIPE Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
39891     3329        169          15   ALJAWWALSTC-AS , SA
20940     2724       1054        1932   AKAMAI-ASN1 , US
34984     1974        327         358   TELLCOM-AS , TR
12479     1290       1002          46   UNI2-AS , ES
 8551     1244        377          46   BEZEQ-INTERNATIONAL-AS Bezeqint Interne
 6849     1148        355          21   UKRTELNET , UA
13188     1074         97          86   BANKINFORM-AS , UA
 8402     1032        544          15   CORBINA-AS Russia, RU
31148     1017         47          44   FREENET-AS , UA
 6830      883       2752         462   LGI-UPC formerly known as UPC Broadband

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
10620     3479        543         124   Telmex Colombia S.A., CO
 8151     2265       3366         553   Uninet S.A. de C.V., MX
 7303     1531        949         241   Telecom Argentina S.A., AR
11830     1493        369          66   Instituto Costarricense de Electricidad
 6503     1418        437          54   Axtel, S.A.B. de C.V., MX
 6147     1103        377          27   Telefonica del Peru S.A.A., PE
 3816      998        478         181   COLOMBIA TELECOMUNICACIONES S.A. ESP, C
 7738      994       1882          40   Telemar Norte Leste S.A., BR
28573      910       2180         158   CLARO S.A., BR
11172      907        125          76   Alestra, S. de R.L. de C.V., MX

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC

AfriNIC Region per AS prefix count summary
------------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
24863     1163        402          48   LINKdotNET-AS, EG
36903      656        330         109   MT-MPLS, MA
37611      648         48           2   Afrihost, ZA
36992      537       1357          26   ETISALAT-MISR, EG
 8452      504       1472          15   TE-AS TE-AS, EG
37492      373        234          68   ORANGE-TN, TN
24835      330        594          15   RAYA-AS, EG
29571      299         37          12   CITelecom-AS, CI
15399      289         35           6   WANANCHI-KE, KE
 2018      264        327          73   TENET-1, ZA

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC

Global Per AS prefix count summary
----------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4538     5560       4191          75   ERX-CERNET-BKB China Education and Rese
22773     3503       2965         144   ASN-CXA-ALL-CCI-22773-RDC - Cox Communi
10620     3479        543         124   Telmex Colombia S.A., CO
 7545     3425        384         253   TPG-INTERNET-AP TPG Telecom Limited, AU
39891     3329        169          15   ALJAWWALSTC-AS , SA
 4766     3177      11145        1126   KIXS-AS-KR Korea Telecom, KR
17974     2935        904          78   TELKOMNET-AS2-AP PT Telekomunikasi Indo
20940     2724       1054        1932   AKAMAI-ASN1 , US
 9829     2564       1487         522   BSNL-NIB National Internet Backbone, IN
 1659     2493       1466          38   ERX-TANET-ASN1 Taiwan Academic Network 

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
22773      3503        3359      ASN-CXA-ALL-CCI-22773-RDC - Cox Communi
10620      3479        3355      Telmex Colombia S.A., CO
39891      3329        3314      ALJAWWALSTC-AS , SA
 7545      3425        3172      TPG-INTERNET-AP TPG Telecom Limited, AU
17974      2935        2857      TELKOMNET-AS2-AP PT Telekomunikasi Indo
 1659      2493        2455      ERX-TANET-ASN1 Taiwan Academic Network 
 6389      2182        2141      BELLSOUTH-NET-BLK - BellSouth.net Inc.,
 9808      2160        2120      CMNET-GD Guangdong Mobile Communication
18566      2195        2085      MEGAPATH5-US - MegaPath Corporation, US
 4766      3177        2051      KIXS-AS-KR Korea Telecom, KR

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS  Designation  Network              Transit AS  Description
65001   PRIVATE      5.143.176.0/20       15468       KLGELECS-AS 38, Teatralnaya st
65001   PRIVATE      31.172.192.0/20      15468       KLGELECS-AS 38, Teatralnaya st
65001   PRIVATE      31.172.192.0/21      15468       KLGELECS-AS 38, Teatralnaya st
65001   PRIVATE      31.172.200.0/21      15468       KLGELECS-AS 38, Teatralnaya st
65001   PRIVATE      31.172.208.0/21      15468       KLGELECS-AS 38, Teatralnaya st
65001   PRIVATE      31.172.216.0/21      15468       KLGELECS-AS 38, Teatralnaya st
65000   PRIVATE      31.219.177.0/25       8966       ETISALAT-AS P.O. Box 1150, Dub
65000   PRIVATE      31.219.177.128/25     8966       ETISALAT-AS P.O. Box 1150, Dub
65412   PRIVATE      41.89.7.0/24         36866       JTL, KE
65512   PRIVATE      45.252.244.0/24      45899       VNPT-AS-VN VNPT Corp, VN

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
23.249.144.0/20      40430     COLO4JAX-AS - colo4jax, LLC, US
27.100.7.0/24        56096     UNKNOWN
41.73.1.0/24         37004     -Reserved AS-, ZZ
41.73.2.0/24         37004     -Reserved AS-, ZZ
41.73.3.0/24         37004     -Reserved AS-, ZZ
41.73.4.0/24         37004     -Reserved AS-, ZZ
41.73.5.0/24         37004     -Reserved AS-, ZZ
41.73.6.0/24         37004     -Reserved AS-, ZZ
41.73.7.0/24         37004     -Reserved AS-, ZZ
41.73.8.0/24         37004     -Reserved AS-, ZZ

Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA

Number of prefixes announced per prefix length (Global)
-------------------------------------------------------

 /1:0        /2:0        /3:0        /4:0        /5:0        /6:0       
 /7:0        /8:16       /9:13      /10:36      /11:100     /12:266     
/13:518     /14:1049    /15:1766    /16:13169   /17:7816    /18:12749   
/19:25323   /20:38278   /21:40173   /22:67117   /23:58796   /24:336973  
/25:564     /26:587     /27:377     /28:49      /29:32      /30:16      
/31:1       /32:33      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
39891     2896          3329      ALJAWWALSTC-AS , SA
22773     2732          3503      ASN-CXA-ALL-CCI-22773-RDC - Cox Communi
18566     2087          2195      MEGAPATH5-US - MegaPath Corporation, US
30036     1530          1715      MEDIACOM-ENTERPRISE-BUSINESS - Mediacom
 6389     1414          2182      BELLSOUTH-NET-BLK - BellSouth.net Inc.,
10620     1383          3479      Telmex Colombia S.A., CO
 6983     1339          1687      ITCDELTA - Earthlink, Inc., US
34984     1257          1974      TELLCOM-AS , TR
11492     1235          1339      CABLEONE - CABLE ONE, INC., US
 6849      968          1148      UKRTELNET , UA

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:1577      2:747       4:21        5:2137      6:31        8:969    
  12:1779     13:43       14:1720     15:44       16:2        17:88     
  18:114      20:49       22:1        23:1635     24:1795     27:2293   
  31:1781     32:67       33:3        34:2        35:5        36:315    
  37:2271     38:1248     39:35       40:94       41:2959     42:457    
  43:1797     44:43       45:2079     46:2528     47:82       49:1159   
  50:902      51:12       52:517      54:340      55:9        56:7      
  57:42       58:1605     59:944      60:351      61:1815     62:1504   
  63:1929     64:4522     65:2177     66:4257     67:2201     68:1113   
  69:3286     70:1251     71:484      72:2027     74:2543     75:343    
  76:382      77:1427     78:1270     79:877      80:1244     81:1385   
  82:973      83:718      84:851      85:1606     86:486      87:1100   
  88:551      89:2098     90:211      91:6066     92:977      93:2397   
  94:2407     95:2501     96:513      97:370      98:945      99:41     
 100:76      101:1088    103:11639   104:2539    105:128     106:430    
 107:1410    108:663     109:2230    110:1286    111:1632    112:1037   
 113:1116    114:1089    115:1659    116:1614    117:1531    118:1988   
 119:1608    120:1260    121:1153    122:2189    123:2040    124:1589   
 125:1780    128:677     129:410     130:410     131:1339    132:619    
 133:175     134:466     135:139     136:382     137:394     138:1768   
 139:299     140:712     141:451     142:649     143:907     144:719    
 145:163     146:888     147:651     148:1383    149:534     150:659    
 151:1024    152:634     153:303     154:655     155:959     156:515    
 157:484     158:383     159:1137    160:513     161:720     162:2358   
 163:919     164:895     165:1061    166:318     167:1165    168:1961   
 169:669     170:1785    171:262     172:608     173:1638    174:752    
 175:743     176:1729    177:4109    178:2190    179:1140    180:2125   
 181:1812    182:1962    183:917     184:832     185:6991    186:3022   
 187:2086    188:2188    189:1749    190:7810    191:1277    192:9052   
 193:5730    194:4436    195:3830    196:1705    197:1136    198:5559   
 199:5739    200:7066    201:3771    202:10110   203:10075   204:4508   
 205:2723    206:2983    207:3102    208:4094    209:3872    210:4265   
 211:2041    212:2702    213:2326    214:869     215:70      216:5846   
 217:1982    218:800     219:623     220:1634    221:866     222:680    
 223:1263   

End of report

From pr at isprime.com  Fri Jul 22 18:20:41 2016
From: pr at isprime.com (Phil Rosenthal)
Date: Fri, 22 Jul 2016 14:20:41 -0400
Subject: MTU
In-Reply-To: <520e997e-9c83-3d1c-b99b-b818e3ea3b16@Janoszka.pl>
References: <CAPkb-7CRMNUK6Av-BBzUgMLh2YW0XfxDs4x4P4rJg6ookVNP=A@mail.gmail.com>
 <CAPkb-7CTi_ekX35OcjdwqfM+W-gdkfkfpLsHXxhH5bVr=nyv3A@mail.gmail.com>
 <CAPkb-7CnxtLuWWA+PDx2ba_xkaE54+Ei4NAbZp7TzvgdGi2Auw@mail.gmail.com>
 <CAPkb-7B3geM2iydgmidq+gFh4oJvzbCj_eznQSvLRhi3LGgvCA@mail.gmail.com>
 <CAPkb-7C78wAAYrdfgZB65W=tJRumUb3qbVGVE1u28V7DTP82Ww@mail.gmail.com>
 <CAPkb-7A1RsiN=tv6YuggARbUx2u8EDOUyHc__BJ6iB=UFWxs4Q@mail.gmail.com>
 <CAPkb-7AQTQnuv9baaO=yEG0e+s0O1ppopafsCNoP8bSuCMysxg@mail.gmail.com>
 <CAPkb-7AXhoCrVnWv+pzbJGPW86mvzGmGuitqscqQ7AJFrriDRg@mail.gmail.com>
 <CAPkb-7BaGqybRDLRd01E65bmzoc-1ebnuYsEtYsSU8VLu5dp3A@mail.gmail.com>
 <CAPkb-7BAjMO2sdY=87J6S6yd8oecyr1gyJa_jqaQUy7=XU0oAw@mail.gmail.com>
 <CAPkb-7A5TgL+dL8D48sccHSCVcHWEah9sv3hZT-7j=kN4aKnYQ@mail.gmail.com>
 <CAPkb-7DtxSt=9vgBviZBSaxN57q=wkDJw+6m=RBmf01s9GtVXw@mail.gmail.com>
 <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>
 <CAP-guGUcE_wrbZdZX7rO2nN1GGREuqVrWfJ37CqY7MRLBZTTSw@mail.gmail.com>
 <520e997e-9c83-3d1c-b99b-b818e3ea3b16@Janoszka.pl>
Message-ID: <C1414C7D-285D-420E-BD99-5027F5A2EC48@isprime.com>


> On Jul 22, 2016, at 1:37 PM, Grzegorz Janoszka <Grzegorz at Janoszka.pl> wrote:
> What I noticed a few years ago was that BGP convergence time was faster with higher MTU.
> Full BGP table load took twice less time on MTU 9192 than on 1500.
> Of course BGP has to be allowed to use higher MTU.
> 
> Anyone else observed something similar?

I have read about others experiencing this, and did some testing a few months back -- my experience was that for low latency links, there was a measurable but not huge difference. For high latency links, with Juniper anyway, there was a very negligible difference, because the TCP Window size is hard-coded at something small (16384?), so that ends up being the limit more than the tcp slow-start issues that MTU helps with.

With that said, we run MTU at >9000 on all of our transit links, and all of our internal links, with no problems. Make sure to do testing to send pings with do-not-fragment at the maximum size configured, and without do-not-fragment just slightly larger than the maximum size configured, to make sure that there are no mismatches on configuration due to vendor differences.

Best Regards,
-Phil Rosenthal

From cb.list6 at gmail.com  Fri Jul 22 18:24:50 2016
From: cb.list6 at gmail.com (Ca By)
Date: Fri, 22 Jul 2016 11:24:50 -0700
Subject: IPv6 Deployment for Mobile Subscribers
In-Reply-To: <CAE0OVL9f9JEMDWx3-DzH7-nQUbWJFGAE5oWfWN-sX6MXhMtq_A@mail.gmail.com>
References: <CAE0OVL9f9JEMDWx3-DzH7-nQUbWJFGAE5oWfWN-sX6MXhMtq_A@mail.gmail.com>
Message-ID: <CAD6AjGRoUs1p5z6N8kZxVd6vtwDsy8G=HUX7znFEH5av2TL8sA@mail.gmail.com>

On Friday, July 22, 2016, Ricardo Ferreira <ricardofbferreira at gmail.com>
wrote:

> Is there anyone here working in an ISP where IPv6 is deployed?
> We are starting to plan the roll-out IPv6 to mobile subscribers (phones) I
> am interesting in knowing the mask you use for the assignment; whether it
> is /64 or /128.
>
> In RFC 3177, it says:
> 3. Address Delegation Recommendations
>
>    The IESG and the IAB recommend the allocations for the boundary
>    between the public and the private topology to follow those general
>    rules:
>
>       -  /48 in the general case, except for very large subscribers.
>       -  /64 when it is known that one and only one subnet is needed by
>          design.
>       -  /128 when it is absolutely known that one and only one device
>          is connecting.
>
> Basically a sole device will be connecting to the internet so I am
> wondering if this rule is follwed.
>
> Cheers
>
>
Phones, as in 3gpp? If so, each phone alway gets a /64, there is no choice.

https://tools.ietf.org/html/rfc6459


> --
> Ricardo Ferreira
>

From lukasz at bromirski.net  Fri Jul 22 18:35:14 2016
From: lukasz at bromirski.net (=?utf-8?Q?=C5=81ukasz_Bromirski?=)
Date: Fri, 22 Jul 2016 20:35:14 +0200
Subject: MTU
In-Reply-To: <520e997e-9c83-3d1c-b99b-b818e3ea3b16@Janoszka.pl>
References: <CAPkb-7CRMNUK6Av-BBzUgMLh2YW0XfxDs4x4P4rJg6ookVNP=A@mail.gmail.com>
 <CAPkb-7CTi_ekX35OcjdwqfM+W-gdkfkfpLsHXxhH5bVr=nyv3A@mail.gmail.com>
 <CAPkb-7CnxtLuWWA+PDx2ba_xkaE54+Ei4NAbZp7TzvgdGi2Auw@mail.gmail.com>
 <CAPkb-7B3geM2iydgmidq+gFh4oJvzbCj_eznQSvLRhi3LGgvCA@mail.gmail.com>
 <CAPkb-7C78wAAYrdfgZB65W=tJRumUb3qbVGVE1u28V7DTP82Ww@mail.gmail.com>
 <CAPkb-7A1RsiN=tv6YuggARbUx2u8EDOUyHc__BJ6iB=UFWxs4Q@mail.gmail.com>
 <CAPkb-7AQTQnuv9baaO=yEG0e+s0O1ppopafsCNoP8bSuCMysxg@mail.gmail.com>
 <CAPkb-7AXhoCrVnWv+pzbJGPW86mvzGmGuitqscqQ7AJFrriDRg@mail.gmail.com>
 <CAPkb-7BaGqybRDLRd01E65bmzoc-1ebnuYsEtYsSU8VLu5dp3A@mail.gmail.com>
 <CAPkb-7BAjMO2sdY=87J6S6yd8oecyr1gyJa_jqaQUy7=XU0oAw@mail.gmail.com>
 <CAPkb-7A5TgL+dL8D48sccHSCVcHWEah9sv3hZT-7j=kN4aKnYQ@mail.gmail.com>
 <CAPkb-7DtxSt=9vgBviZBSaxN57q=wkDJw+6m=RBmf01s9GtVXw@mail.gmail.com>
 <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>
 <CAP-guGUcE_wrbZdZX7rO2nN1GGREuqVrWfJ37CqY7MRLBZTTSw@mail.gmail.com>
 <520e997e-9c83-3d1c- b99b-b818e3ea3b16@Janoszka.pl>
Message-ID: <690F9504-DAE7-4CCA-A3BD-8B8749245AF4@bromirski.net>


> On 22 Jul 2016, at 19:37, Grzegorz Janoszka <Grzegorz at Janoszka.pl> wrote:
> 
>> On 2016-07-22 15:57, William Herrin wrote:
>> On a link containing only routers, you can safely increase the MTU to
>> any mutually agreed value with these caveats:
> 
> What I noticed a few years ago was that BGP convergence time was faster with higher MTU.
> Full BGP table load took twice less time on MTU 9192 than on 1500.
> Of course BGP has to be allowed to use higher MTU.

Quite obvious thing - BGP by default on Cisco and Juniper will use up to max allowed 4k message per packet, which for typical unicast IPv4/v6 helps to pack all attributes with prefix. This not only improves  (lowers) CPU load on sending side but also on the receiving end and helps with routing convergence.

There was a draft to use up to 9k for BGP messaging, but I belive it's buried somewhere on the outside of town called "our current version RFC".

-- 
?ukasz Bromirski

From dottedmag at dottedmag.net  Fri Jul 22 16:06:37 2016
From: dottedmag at dottedmag.net (Mikhail Gusarov)
Date: Fri, 22 Jul 2016 18:06:37 +0200
Subject: IPv6 Deployment for Mobile Subscribers
In-Reply-To: <CAE0OVL9f9JEMDWx3-DzH7-nQUbWJFGAE5oWfWN-sX6MXhMtq_A@mail.gmail.com>
References: <CAE0OVL9f9JEMDWx3-DzH7-nQUbWJFGAE5oWfWN-sX6MXhMtq_A@mail.gmail.com>
Message-ID: <D40E7B29-6965-41F0-BFC8-D8C2C1298333@dottedmag.net>

Good day,

On 22 Jul 2016, at 10:54, Ricardo Ferreira wrote:

> Is there anyone here working in an ISP where IPv6 is deployed?

I am not, but I can answer from the consumer's point of view:

> Basically a sole device will be connecting to the internet so I am
> wondering if this rule is follwed.

Tethering.

With best regards,
Mikhail.

From jg at freedesktop.org  Fri Jul 22 19:23:00 2016
From: jg at freedesktop.org (Jim Gettys)
Date: Fri, 22 Jul 2016 15:23:00 -0400
Subject: I recommend dslreports.com/speedtest these days (was
 Speedtest.net not accessible in Chrome due to deceptive ads)
In-Reply-To: <414BCE73-08E8-4D0B-9056-C629CA8F2C03@truenet.com>
References: <CAA6dEZNy64iWvJcdkEzmMOoaC81EwGH6F4FQOejhkM=DQWeYQw@mail.gmail.com>
 <994213489.26076.1469135945049.JavaMail.zimbra@baylink.com>
 <113466DC-5310-4A75-A2C4-C4D7CC8AE4C5@f5.com>
 <414BCE73-08E8-4D0B-9056-C629CA8F2C03@truenet.com>
Message-ID: <CAGhGL2Bm1WuCWVZzqxhBS7jWFn1ws_x=Wz2sZoEf1Kd9+9pH7A@mail.gmail.com>

I don't read this list continually, but do archive it; your note was
flagged for me to comment on.

On Thu, Jul 21, 2016 at 8:11 PM, Eric Tykwinski <eric-list at truenet.com>
wrote:

> This is probably for Jim Gettys directly, but I?m sure most others have
> input.  I could of sworn that that there was some test made to detect it
> directly on switches and routers?  Sort of like iperf, but to test
> bufferbloat specifically given the OS stack which is going to have issues
> as well, as shown on bufferbloat.net <http://bufferbloat.net/>.
>
>
?We recommend Toke H?iland-J?rgensen's
?
 "flent" ?

?https://flent.org/ for testing connections/devices/gear. It uses "netperf"
transfers to load the link (by default with 4 simultaneous TCP connections
in both directions, IIRC), and then runs another test (by default "ping")
at the same time to test the connection under load.
Turning on a netperf server is just as easy as turning on an iperf server
(and the results are better, and netperf's maintainer responsive).?

See the documentation/paper on Toke's web site.  The "RRUL" test
("Real-Time Response Under Load") is the one we use most/is best shaken
down.   I'm sure Toke would love help with other tests.
?

Gives you lots of useful graphs, will do diffserv marking, etc...?
?

> > On Jul 21, 2016, at 6:36 PM, Donn Lasher via NANOG <nanog at nanog.org>
> wrote:
> >
> > On 7/21/16, 2:19 PM, "NANOG on behalf of Jay R. Ashworth" <
> nanog-bounces at nanog.org on behalf of jra at baylink.com> wrote:
> >
> >
> >
> >> ----- Original Message -----
> >>> From: "Janusz Jezowicz" <janusz at speedchecker.xyz>
> >>
> >>> Since this morning Speedtest.net is not accessible in Chrome
> >>> Reason:
> >>>
> https://www.google.com/transparencyreport/safebrowsing/diagnostic/#url=c.speedtest.net
> >>>
> >>> For any ISPs/content providers linking to speedtest.net you may want
> to
> >>> swap links to a different website or host your own speed test.
> >>
> >> So far, I am very pleased with how it works, though I think it's letter
> >> grades on speed are a bit pessimistic (65Mbps is a "C").
>

?
Most applications are as sensitive/more sensitive to latency than to
bandwidth
?; see the research in the field, for example, for web browsing.  For web
browsing, you are at the point of diminishing returns on bandwidth after a
few megabits/second, for most use?
.
?  For telephony, the metric is always the lower the better, and not more
than 100ms or so (continental delay).?

So it is entirely appropriate in my view to give even "high speed"
connections low grades; it's telling you that they suck under load
?, like when your kid is downloading a video (or uploading one for their
friends); your performance (e.g. web surfing) can go to hell in a
hand-basket despite having a lot of bandwidth on the
connection. For most use, I'll take a 20Mbps link without bloat to a
200Mbps one with a half second of bloat any
? ?
day.
? It will work reliably, I'll be able to make my phone calls without
problems, I'll be able to frag my friends with the best of them, etc...
Even video playback gets wonky with bad bufferbloat: the player's control
loop is interacting with the (wildly excessive due to bloat) TCP control
loop and can't find a good playback point; seeking also becomes slow, etc.

Activities such as web browsing can/does cause transient latency on a link,
since most links are not doing decent scheduling; the damage is done
anytime the link gets used by anyone, for anything, including web surfing
as well as background activities such as backup or system update.

So no, I don't think dslreports grades pessimistically: it's just that bad
bufferbloat is so *blinking* common and bad.  And I had nothing to do with
setting the scoring system: that's the opinion of the dslreports test's
author; but I think Justin has done a good job choosing the grades to boil
down the quality of a connection to something mere mortals (your
customer's) will understand.  So my hat is off to Justin for doing a great
job.
?


> >>
> >> Specifically, it measures bufferbloat, with both a realtime graph and a
> >
> >
> > Are you talking about the dslreports speedtest? I like that one, very
> detailed results.
> >
> > http://speedtest.dslreports.com/
> >
> >
> > I?d agree with the pessimistic scoring.. 160Mbit was given a ?B? grade.
> >
> >
> >
> >
>
>

From eric-list at truenet.com  Fri Jul 22 19:42:49 2016
From: eric-list at truenet.com (Eric Tykwinski)
Date: Fri, 22 Jul 2016 15:42:49 -0400
Subject: I recommend dslreports.com/speedtest these days (was
 Speedtest.net not accessible in Chrome due to deceptive ads)
In-Reply-To: <CAGhGL2Bm1WuCWVZzqxhBS7jWFn1ws_x=Wz2sZoEf1Kd9+9pH7A@mail.gmail.com>
References: <CAA6dEZNy64iWvJcdkEzmMOoaC81EwGH6F4FQOejhkM=DQWeYQw@mail.gmail.com>
 <994213489.26076.1469135945049.JavaMail.zimbra@baylink.com>
 <113466DC-5310-4A75-A2C4-C4D7CC8AE4C5@f5.com>
 <414BCE73-08E8-4D0B-9056-C629CA8F2C03@truenet.com>
 <CAGhGL2Bm1WuCWVZzqxhBS7jWFn1ws_x=Wz2sZoEf1Kd9+9pH7A@mail.gmail.com>
Message-ID: <015301d1e451$3a9da970$afd8fc50$@truenet.com>

Jim,

No problems, I just knew you were one of the project founders.  I found it on the website shortly after posting.
My google-fu wasn?t up to par.
https://www.bufferbloat.net/projects/cerowrt/wiki/Tests_for_Bufferbloat/

I?m assuming I used the script last time for netperf, but have downloaded Flent to give it a shot.

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300
__________________________________________________________________________________________
From: gettysjim at gmail.com [mailto:gettysjim at gmail.com] On Behalf Of Jim Gettys
Sent: Friday, July 22, 2016 3:23 PM
To: Eric Tykwinski
Cc: nanog list; jb; Toke H?iland-J?rgensen; Dave Taht
Subject: Re: I recommend dslreports.com/speedtest these days (was Speedtest.net not accessible in Chrome due to deceptive ads)

I don't read this list continually, but do archive it; your note was flagged for me to comment on.

On Thu, Jul 21, 2016 at 8:11 PM, Eric Tykwinski <eric-list at truenet.com> wrote:
This is probably for Jim Gettys directly, but I?m sure most others have input.  I could of sworn that that there was some test made to detect it directly on switches and routers?  Sort of like iperf, but to test bufferbloat specifically given the OS stack which is going to have issues as well, as shown on bufferbloat.net <http://bufferbloat.net/>.

?We recommend Toke H?iland-J?rgensen's
?
 "flent" ?
 
?https://flent.org/ for testing connections/devices/gear. It uses "netperf" transfers to load the link (by default with 4 simultaneous TCP connections in both directions, IIRC), and then runs another test (by default "ping") at the same time to test the connection under load. 
Turning on a netperf server is just as easy as turning on an iperf server (and the results are better, and netperf's maintainer responsive).?

See the documentation/paper on Toke's web site.  The "RRUL" test 
("Real-Time Response Under Load") is the one we use most/is best shaken down.   I'm sure Toke would love help with other tests.
?

Gives you lots of useful graphs, will do diffserv marking, etc...?



From Grzegorz at Janoszka.pl  Fri Jul 22 20:10:05 2016
From: Grzegorz at Janoszka.pl (Grzegorz Janoszka)
Date: Fri, 22 Jul 2016 22:10:05 +0200
Subject: MTU
In-Reply-To: <C1414C7D-285D-420E-BD99-5027F5A2EC48@isprime.com>
References: <CAPkb-7CRMNUK6Av-BBzUgMLh2YW0XfxDs4x4P4rJg6ookVNP=A@mail.gmail.com>
 <CAPkb-7B3geM2iydgmidq+gFh4oJvzbCj_eznQSvLRhi3LGgvCA@mail.gmail.com>
 <CAPkb-7C78wAAYrdfgZB65W=tJRumUb3qbVGVE1u28V7DTP82Ww@mail.gmail.com>
 <CAPkb-7A1RsiN=tv6YuggARbUx2u8EDOUyHc__BJ6iB=UFWxs4Q@mail.gmail.com>
 <CAPkb-7AQTQnuv9baaO=yEG0e+s0O1ppopafsCNoP8bSuCMysxg@mail.gmail.com>
 <CAPkb-7AXhoCrVnWv+pzbJGPW86mvzGmGuitqscqQ7AJFrriDRg@mail.gmail.com>
 <CAPkb-7BaGqybRDLRd01E65bmzoc-1ebnuYsEtYsSU8VLu5dp3A@mail.gmail.com>
 <CAPkb-7BAjMO2sdY=87J6S6yd8oecyr1gyJa_jqaQUy7=XU0oAw@mail.gmail.com>
 <CAPkb-7A5TgL+dL8D48sccHSCVcHWEah9sv3hZT-7j=kN4aKnYQ@mail.gmail.com>
 <CAPkb-7DtxSt=9vgBviZBSaxN57q=wkDJw+6m=RBmf01s9GtVXw@mail.gmail.com>
 <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>
 <CAP-guGUcE_wrbZdZX7rO2nN1GGREuqVrWfJ37CqY7MRLBZTTSw@mail.gmail.com>
 <520e997e-9c83-3d1c-b99b-b818e3ea3b16@Janoszka.pl>
 <C1414C7D-285D-420E-BD99-5027F5A2EC48@isprime.com>
Message-ID: <282ffd5b-3762-c83f-e876-c100f2587fd3@Janoszka.pl>

On 2016-07-22 20:20, Phil Rosenthal wrote:
>> On Jul 22, 2016, at 1:37 PM, Grzegorz Janoszka <Grzegorz at Janoszka.pl> wrote:
>> What I noticed a few years ago was that BGP convergence time was faster with higher MTU.
>> Full BGP table load took twice less time on MTU 9192 than on 1500.
>> Of course BGP has to be allowed to use higher MTU.
>>
>> Anyone else observed something similar?
>
> I have read about others experiencing this, and did some testing a few months back -- my experience was that for low latency links, there was a measurable but not huge difference. For high latency links, with Juniper anyway, there was a very negligible difference, because the TCP Window size is hard-coded at something small (16384?), so that ends up being the limit more than the tcp slow-start issues that MTU helps with.

I tested Cisco CRS-1 (or maybe already upgraded to CRS-3) to Juniper 
MX480 or MX960 on about 10 ms latency link. It was iBGP carrying 
internal routes plus full BGP table (both ways).
I think the bottleneck was CPU on the CRS side and maxing MSS helped a 
lot. I recall doing later on tests Juniper to Juniper and indeed the 
gain was not that big, but it was still visible.

Juniper command 'show system connections' showed MSS around 9kB. I 
haven't checked TCP Window size.

-- 
Grzegorz Janoszka

From baldur.norddahl at gmail.com  Fri Jul 22 20:10:41 2016
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Fri, 22 Jul 2016 22:10:41 +0200
Subject: IPv6 Deployment for Mobile Subscribers
In-Reply-To: <CAD6AjGRoUs1p5z6N8kZxVd6vtwDsy8G=HUX7znFEH5av2TL8sA@mail.gmail.com>
References: <CAE0OVL9f9JEMDWx3-DzH7-nQUbWJFGAE5oWfWN-sX6MXhMtq_A@mail.gmail.com>
 <CAD6AjGRoUs1p5z6N8kZxVd6vtwDsy8G=HUX7znFEH5av2TL8sA@mail.gmail.com>
Message-ID: <CAPkb-7DHztaYwgV6BkSAJFUKH8=6iivDFwhzLZem+kJ89y+N8w@mail.gmail.com>

Den 22. jul. 2016 20.25 skrev "Ca By" <cb.list6 at gmail.com>:

> Phones, as in 3gpp? If so, each phone alway gets a /64, there is no
choice.
>
> https://tools.ietf.org/html/rfc6459

Here the cell companies are marketing their 4G LTE as an alternative to
DSL, Coax and fiber for internet access in your home with a 4G wifi router.
If they can not do prefix delegation it is no alternative!

I would love to test it, but it will be no surprise that none of the four
carriers enabled IPv6.

Regards

Baldur

From sryan at arbor.net  Fri Jul 22 20:14:55 2016
From: sryan at arbor.net (Ryan, Spencer)
Date: Fri, 22 Jul 2016 20:14:55 +0000
Subject: IPv6 Deployment for Mobile Subscribers
In-Reply-To: <CAPkb-7DHztaYwgV6BkSAJFUKH8=6iivDFwhzLZem+kJ89y+N8w@mail.gmail.com>
References: <CAE0OVL9f9JEMDWx3-DzH7-nQUbWJFGAE5oWfWN-sX6MXhMtq_A@mail.gmail.com>
 <CAD6AjGRoUs1p5z6N8kZxVd6vtwDsy8G=HUX7znFEH5av2TL8sA@mail.gmail.com>,
 <CAPkb-7DHztaYwgV6BkSAJFUKH8=6iivDFwhzLZem+kJ89y+N8w@mail.gmail.com>
Message-ID: <DM2PR0101MB121611324815C7B0CE1FE681B00A0@DM2PR0101MB1216.prod.exchangelabs.com>

> I would love to test it, but it will be no surprise that none of the four
carriers enabled IPv6.


Verizon Wireless has been dual stack for many years, before they ran out of public IPv4 addresses and switched handsets to RFC1918 space for v4.

________________________________
From: NANOG <nanog-bounces at nanog.org> on behalf of Baldur Norddahl <baldur.norddahl at gmail.com>
Sent: Friday, July 22, 2016 4:10:41 PM
To: nanog at nanog.org
Subject: Re: IPv6 Deployment for Mobile Subscribers

Den 22. jul. 2016 20.25 skrev "Ca By" <cb.list6 at gmail.com>:

> Phones, as in 3gpp? If so, each phone alway gets a /64, there is no
choice.
>
> https://tools.ietf.org/html/rfc6459

Here the cell companies are marketing their 4G LTE as an alternative to
DSL, Coax and fiber for internet access in your home with a 4G wifi router.
If they can not do prefix delegation it is no alternative!

I would love to test it, but it will be no surprise that none of the four
carriers enabled IPv6.

Regards

Baldur

From baldur.norddahl at gmail.com  Fri Jul 22 20:18:12 2016
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Fri, 22 Jul 2016 22:18:12 +0200
Subject: I recommend dslreports.com/speedtest these days (was
 Speedtest.net not accessible in Chrome due to deceptive ads)
In-Reply-To: <CAGhGL2Bm1WuCWVZzqxhBS7jWFn1ws_x=Wz2sZoEf1Kd9+9pH7A@mail.gmail.com>
References: <CAA6dEZNy64iWvJcdkEzmMOoaC81EwGH6F4FQOejhkM=DQWeYQw@mail.gmail.com>
 <994213489.26076.1469135945049.JavaMail.zimbra@baylink.com>
 <113466DC-5310-4A75-A2C4-C4D7CC8AE4C5@f5.com>
 <414BCE73-08E8-4D0B-9056-C629CA8F2C03@truenet.com>
 <CAGhGL2Bm1WuCWVZzqxhBS7jWFn1ws_x=Wz2sZoEf1Kd9+9pH7A@mail.gmail.com>
Message-ID: <CAPkb-7CeQLZsfVhnLjHGCZ+eyV0=1nGcY1NdCqZxokSaoioxaA@mail.gmail.com>

Den 22. jul. 2016 21.34 skrev "Jim Gettys" <jg at freedesktop.org>:
>
>
> So it is entirely appropriate in my view to give even "high speed"
> connections low grades; it's telling you that they suck under load
> ?, like when your kid is downloading a video (or uploading one for their
> friends); your performance (e.g. web surfing) can go to hell in a
> hand-basket despite having a lot of bandwidth on the
> connection. For most use, I'll take a 20Mbps link without bloat to a
> 200Mbps one with a half second of bloat any
> ? ?
> day.
> ?

I will expect that high speed links will have little bloat simply because
even large buffers empty quite fast.

Regards

Baldur

From jg at freedesktop.org  Fri Jul 22 20:31:28 2016
From: jg at freedesktop.org (Jim Gettys)
Date: Fri, 22 Jul 2016 16:31:28 -0400
Subject: I recommend dslreports.com/speedtest these days (was
 Speedtest.net not accessible in Chrome due to deceptive ads)
In-Reply-To: <CAPkb-7CeQLZsfVhnLjHGCZ+eyV0=1nGcY1NdCqZxokSaoioxaA@mail.gmail.com>
References: <CAA6dEZNy64iWvJcdkEzmMOoaC81EwGH6F4FQOejhkM=DQWeYQw@mail.gmail.com>
 <994213489.26076.1469135945049.JavaMail.zimbra@baylink.com>
 <113466DC-5310-4A75-A2C4-C4D7CC8AE4C5@f5.com>
 <414BCE73-08E8-4D0B-9056-C629CA8F2C03@truenet.com>
 <CAGhGL2Bm1WuCWVZzqxhBS7jWFn1ws_x=Wz2sZoEf1Kd9+9pH7A@mail.gmail.com>
 <CAPkb-7CeQLZsfVhnLjHGCZ+eyV0=1nGcY1NdCqZxokSaoioxaA@mail.gmail.com>
Message-ID: <CAGhGL2A-ystx24apm-fM6YuJLER4dye=G8dg4j=WLNR43WtO2w@mail.gmail.com>

On Fri, Jul 22, 2016 at 4:18 PM, Baldur Norddahl <baldur.norddahl at gmail.com>
wrote:

> Den 22. jul. 2016 21.34 skrev "Jim Gettys" <jg at freedesktop.org>:
> >
> >
> > So it is entirely appropriate in my view to give even "high speed"
> > connections low grades; it's telling you that they suck under load
> > ?, like when your kid is downloading a video (or uploading one for their
> > friends); your performance (e.g. web surfing) can go to hell in a
> > hand-basket despite having a lot of bandwidth on the
> > connection. For most use, I'll take a 20Mbps link without bloat to a
> > 200Mbps one with a half second of bloat any
> > ? ?
> > day.
> > ?
>
> I will expect that high speed links will have little bloat simply because
> even large buffers empty quite fast.
>

?Unfortunately, that is often/usually not the case.?

?  The buffering has typically scaled up as fast/faster than the bandwidth
has, in my observation. You can have as much/more bloat on a higher
bandwidth line as a low bandwidth line.

That's why I always refer to buffering in seconds?, not bytes, unless I'm
trying to understand how the identical equipment will behave at differing
bandwidths.

The worst is usually someone taking modern equipment and then running it at
low speed: e.g. a gigabit switch being used at 100Mbps will generally be
10x worse than the old equipment it replaces (at best).

                     - Jim

From tore at fud.no  Fri Jul 22 20:36:54 2016
From: tore at fud.no (Tore Anderson)
Date: Fri, 22 Jul 2016 22:36:54 +0200
Subject: IPv6 Deployment for Mobile Subscribers
In-Reply-To: <CAPkb-7DHztaYwgV6BkSAJFUKH8=6iivDFwhzLZem+kJ89y+N8w@mail.gmail.com>
References: <CAE0OVL9f9JEMDWx3-DzH7-nQUbWJFGAE5oWfWN-sX6MXhMtq_A@mail.gmail.com>
 <CAD6AjGRoUs1p5z6N8kZxVd6vtwDsy8G=HUX7znFEH5av2TL8sA@mail.gmail.com>
 <CAPkb-7DHztaYwgV6BkSAJFUKH8=6iivDFwhzLZem+kJ89y+N8w@mail.gmail.com>
Message-ID: <20160722223654.71015c7f@envy.e1.y.home>

* Baldur Norddahl

> Den 22. jul. 2016 20.25 skrev "Ca By" <cb.list6 at gmail.com>:
> 
> > Phones, as in 3gpp? If so, each phone alway gets a /64, there is
> > no choice.
> >
> > https://tools.ietf.org/html/rfc6459  
> 
> Here the cell companies are marketing their 4G LTE as an alternative
> to DSL, Coax and fiber for internet access in your home with a 4G
> wifi router. If they can not do prefix delegation it is no
> alternative!

Actually, that /64 prefix is delegated, after a fashion. RFC 7278.

That said, according to RFC 6459 section 5.3, full DHCPv6-PD support
was specified in 3GPP Rel-10. Not sure if there are production
deployments of that yet though, and if not how far off they are. But at
least it looks like it's coming.

Tore

From jra at baylink.com  Fri Jul 22 22:05:18 2016
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 22 Jul 2016 18:05:18 -0400
Subject: I recommend dslreports.com/speedtest these days (was
 Speedtest.net not accessible in Chrome due to deceptive ads)
In-Reply-To: <CAGhGL2Bm1WuCWVZzqxhBS7jWFn1ws_x=Wz2sZoEf1Kd9+9pH7A@mail.gmail.com>
References: <CAA6dEZNy64iWvJcdkEzmMOoaC81EwGH6F4FQOejhkM=DQWeYQw@mail.gmail.com>
 <994213489.26076.1469135945049.JavaMail.zimbra@baylink.com>
 <113466DC-5310-4A75-A2C4-C4D7CC8AE4C5@f5.com>
 <414BCE73-08E8-4D0B-9056-C629CA8F2C03@truenet.com>
 <CAGhGL2Bm1WuCWVZzqxhBS7jWFn1ws_x=Wz2sZoEf1Kd9+9pH7A@mail.gmail.com>
Message-ID: <80522E59-B7DF-4BF8-913C-0F5ED3910051@baylink.com>

Just a quick clarifying reply, I have had DSL test give me an A for bufferbloat and a C for Speed on a 75 Meg line.

On July 22, 2016 3:23:00 PM EDT, Jim Gettys <jg at freedesktop.org> wrote:
>I don't read this list continually, but do archive it; your note was
>flagged for me to comment on.
>
>On Thu, Jul 21, 2016 at 8:11 PM, Eric Tykwinski <eric-list at truenet.com>
>wrote:
>
>> This is probably for Jim Gettys directly, but I?m sure most others
>have
>> input.  I could of sworn that that there was some test made to detect
>it
>> directly on switches and routers?  Sort of like iperf, but to test
>> bufferbloat specifically given the OS stack which is going to have
>issues
>> as well, as shown on bufferbloat.net <http://bufferbloat.net/>.
>>
>>
>?We recommend Toke H?iland-J?rgensen's
>?
> "flent" ?
>
>?https://flent.org/ for testing connections/devices/gear. It uses
>"netperf"
>transfers to load the link (by default with 4 simultaneous TCP
>connections
>in both directions, IIRC), and then runs another test (by default
>"ping")
>at the same time to test the connection under load.
>Turning on a netperf server is just as easy as turning on an iperf
>server
>(and the results are better, and netperf's maintainer responsive).?
>
>See the documentation/paper on Toke's web site.  The "RRUL" test
>("Real-Time Response Under Load") is the one we use most/is best shaken
>down.   I'm sure Toke would love help with other tests.
>?
>
>Gives you lots of useful graphs, will do diffserv marking, etc...?
>?
>
>> > On Jul 21, 2016, at 6:36 PM, Donn Lasher via NANOG
><nanog at nanog.org>
>> wrote:
>> >
>> > On 7/21/16, 2:19 PM, "NANOG on behalf of Jay R. Ashworth" <
>> nanog-bounces at nanog.org on behalf of jra at baylink.com> wrote:
>> >
>> >
>> >
>> >> ----- Original Message -----
>> >>> From: "Janusz Jezowicz" <janusz at speedchecker.xyz>
>> >>
>> >>> Since this morning Speedtest.net is not accessible in Chrome
>> >>> Reason:
>> >>>
>>
>https://www.google.com/transparencyreport/safebrowsing/diagnostic/#url=c.speedtest.net
>> >>>
>> >>> For any ISPs/content providers linking to speedtest.net you may
>want
>> to
>> >>> swap links to a different website or host your own speed test.
>> >>
>> >> So far, I am very pleased with how it works, though I think it's
>letter
>> >> grades on speed are a bit pessimistic (65Mbps is a "C").
>>
>
>?
>Most applications are as sensitive/more sensitive to latency than to
>bandwidth
>?; see the research in the field, for example, for web browsing.  For
>web
>browsing, you are at the point of diminishing returns on bandwidth
>after a
>few megabits/second, for most use?
>.
>?  For telephony, the metric is always the lower the better, and not
>more
>than 100ms or so (continental delay).?
>
>So it is entirely appropriate in my view to give even "high speed"
>connections low grades; it's telling you that they suck under load
>?, like when your kid is downloading a video (or uploading one for
>their
>friends); your performance (e.g. web surfing) can go to hell in a
>hand-basket despite having a lot of bandwidth on the
>connection. For most use, I'll take a 20Mbps link without bloat to a
>200Mbps one with a half second of bloat any
>? ?
>day.
>? It will work reliably, I'll be able to make my phone calls without
>problems, I'll be able to frag my friends with the best of them, etc...
>Even video playback gets wonky with bad bufferbloat: the player's
>control
>loop is interacting with the (wildly excessive due to bloat) TCP
>control
>loop and can't find a good playback point; seeking also becomes slow,
>etc.
>
>Activities such as web browsing can/does cause transient latency on a
>link,
>since most links are not doing decent scheduling; the damage is done
>anytime the link gets used by anyone, for anything, including web
>surfing
>as well as background activities such as backup or system update.
>
>So no, I don't think dslreports grades pessimistically: it's just that
>bad
>bufferbloat is so *blinking* common and bad.  And I had nothing to do
>with
>setting the scoring system: that's the opinion of the dslreports test's
>author; but I think Justin has done a good job choosing the grades to
>boil
>down the quality of a connection to something mere mortals (your
>customer's) will understand.  So my hat is off to Justin for doing a
>great
>job.
>?
>
>
>> >>
>> >> Specifically, it measures bufferbloat, with both a realtime graph
>and a
>> >
>> >
>> > Are you talking about the dslreports speedtest? I like that one,
>very
>> detailed results.
>> >
>> > http://speedtest.dslreports.com/
>> >
>> >
>> > I?d agree with the pessimistic scoring.. 160Mbit was given a ?B?
>grade.
>> >
>> >
>> >
>> >
>>
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From ler762 at gmail.com  Fri Jul 22 22:45:49 2016
From: ler762 at gmail.com (Lee)
Date: Fri, 22 Jul 2016 18:45:49 -0400
Subject: MTU
In-Reply-To: <C1414C7D-285D-420E-BD99-5027F5A2EC48@isprime.com>
References: <CAPkb-7CRMNUK6Av-BBzUgMLh2YW0XfxDs4x4P4rJg6ookVNP=A@mail.gmail.com>
 <CAPkb-7CTi_ekX35OcjdwqfM+W-gdkfkfpLsHXxhH5bVr=nyv3A@mail.gmail.com>
 <CAPkb-7CnxtLuWWA+PDx2ba_xkaE54+Ei4NAbZp7TzvgdGi2Auw@mail.gmail.com>
 <CAPkb-7B3geM2iydgmidq+gFh4oJvzbCj_eznQSvLRhi3LGgvCA@mail.gmail.com>
 <CAPkb-7C78wAAYrdfgZB65W=tJRumUb3qbVGVE1u28V7DTP82Ww@mail.gmail.com>
 <CAPkb-7A1RsiN=tv6YuggARbUx2u8EDOUyHc__BJ6iB=UFWxs4Q@mail.gmail.com>
 <CAPkb-7AQTQnuv9baaO=yEG0e+s0O1ppopafsCNoP8bSuCMysxg@mail.gmail.com>
 <CAPkb-7AXhoCrVnWv+pzbJGPW86mvzGmGuitqscqQ7AJFrriDRg@mail.gmail.com>
 <CAPkb-7BaGqybRDLRd01E65bmzoc-1ebnuYsEtYsSU8VLu5dp3A@mail.gmail.com>
 <CAPkb-7BAjMO2sdY=87J6S6yd8oecyr1gyJa_jqaQUy7=XU0oAw@mail.gmail.com>
 <CAPkb-7A5TgL+dL8D48sccHSCVcHWEah9sv3hZT-7j=kN4aKnYQ@mail.gmail.com>
 <CAPkb-7DtxSt=9vgBviZBSaxN57q=wkDJw+6m=RBmf01s9GtVXw@mail.gmail.com>
 <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>
 <CAP-guGUcE_wrbZdZX7rO2nN1GGREuqVrWfJ37CqY7MRLBZTTSw@mail.gmail.com>
 <520e997e-9c83-3d1c-b99b-b818e3ea3b16@Janoszka.pl>
 <C1414C7D-285D-420E-BD99-5027F5A2EC48@isprime.com>
Message-ID: <CAD8GWsveoB5K7PSbpsNZ483vrecYsug3-pacF9NgkBzK7s_w6A@mail.gmail.com>

On 7/22/16, Phil Rosenthal <pr at isprime.com> wrote:
>
>> On Jul 22, 2016, at 1:37 PM, Grzegorz Janoszka <Grzegorz at Janoszka.pl>
>> wrote:
>> What I noticed a few years ago was that BGP convergence time was faster
>> with higher MTU.
>> Full BGP table load took twice less time on MTU 9192 than on 1500.
>> Of course BGP has to be allowed to use higher MTU.
>>
>> Anyone else observed something similar?
>
> I have read about others experiencing this, and did some testing a few
> months back -- my experience was that for low latency links, there was a
> measurable but not huge difference. For high latency links, with Juniper
> anyway, there was a very negligible difference, because the TCP Window size
> is hard-coded at something small (16384?), so that ends up being the limit
> more than the tcp slow-start issues that MTU helps with.

I think the Cisco default window size is 16KB but you can change it with
ip tcp window-size NNN

Lee

>
> With that said, we run MTU at >9000 on all of our transit links, and all of
> our internal links, with no problems. Make sure to do testing to send pings
> with do-not-fragment at the maximum size configured, and without
> do-not-fragment just slightly larger than the maximum size configured, to
> make sure that there are no mismatches on configuration due to vendor
> differences.
>
> Best Regards,
> -Phil Rosenthal

From Valdis.Kletnieks at vt.edu  Sat Jul 23 03:52:14 2016
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 22 Jul 2016 23:52:14 -0400
Subject: IPv6 Deployment for Mobile Subscribers
In-Reply-To: <CAE0OVL9f9JEMDWx3-DzH7-nQUbWJFGAE5oWfWN-sX6MXhMtq_A@mail.gmail.com>
References: <CAE0OVL9f9JEMDWx3-DzH7-nQUbWJFGAE5oWfWN-sX6MXhMtq_A@mail.gmail.com>
Message-ID: <13948.1469245934@turing-police.cc.vt.edu>

On Fri, 22 Jul 2016 10:54:48 +0200, Ricardo Ferreira said:
> Is there anyone here working in an ISP where IPv6 is deployed?
> We are starting to plan the roll-out IPv6 to mobile subscribers (phones) I
> am interesting in knowing the mask you use for the assignment; whether it
> is /64 or /128.
>
> In RFC 3177, it says:

>       -  /128 when it is absolutely known that one and only one device
>          is connecting.

See this RFC, which is a recently released BCP:

7934 Host Address Availability Recommendations. L. Colitti, V. Cerf, S.
     Cheshire, D. Schinazi. July 2016. (Format: TXT=37124 bytes) (Also
     BCP0204) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7934)

In short - even when you have only one device connecting, you probably need
more than one address.

Also, consider the common practice of tethering....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160722/e0cd725d/attachment.pgp>

From mark.tinka at seacom.mu  Sat Jul 23 05:40:35 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Sat, 23 Jul 2016 07:40:35 +0200
Subject: MTU
In-Reply-To: <520e997e-9c83-3d1c-b99b-b818e3ea3b16@Janoszka.pl>
References: <CAPkb-7CRMNUK6Av-BBzUgMLh2YW0XfxDs4x4P4rJg6ookVNP=A@mail.gmail.com>
 <CAPkb-7CnxtLuWWA+PDx2ba_xkaE54+Ei4NAbZp7TzvgdGi2Auw@mail.gmail.com>
 <CAPkb-7B3geM2iydgmidq+gFh4oJvzbCj_eznQSvLRhi3LGgvCA@mail.gmail.com>
 <CAPkb-7C78wAAYrdfgZB65W=tJRumUb3qbVGVE1u28V7DTP82Ww@mail.gmail.com>
 <CAPkb-7A1RsiN=tv6YuggARbUx2u8EDOUyHc__BJ6iB=UFWxs4Q@mail.gmail.com>
 <CAPkb-7AQTQnuv9baaO=yEG0e+s0O1ppopafsCNoP8bSuCMysxg@mail.gmail.com>
 <CAPkb-7AXhoCrVnWv+pzbJGPW86mvzGmGuitqscqQ7AJFrriDRg@mail.gmail.com>
 <CAPkb-7BaGqybRDLRd01E65bmzoc-1ebnuYsEtYsSU8VLu5dp3A@mail.gmail.com>
 <CAPkb-7BAjMO2sdY=87J6S6yd8oecyr1gyJa_jqaQUy7=XU0oAw@mail.gmail.com>
 <CAPkb-7A5TgL+dL8D48sccHSCVcHWEah9sv3hZT-7j=kN4aKnYQ@mail.gmail.com>
 <CAPkb-7DtxSt=9vgBviZBSaxN57q=wkDJw+6m=RBmf01s9GtVXw@mail.gmail.com>
 <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>
 <CAP-guGUcE_wrbZdZX7rO2nN1GGREuqVrWfJ37CqY7MRLBZTTSw@mail.gmail.com>
 <520e997e-9c83-3d1c-b99b-b818e3ea3b16@Janoszka.pl>
Message-ID: <07a896db-911c-c9b5-8975-470d4dcb4ea4@seacom.mu>



On 22/Jul/16 19:37, Grzegorz Janoszka wrote:

>  
>
> What I noticed a few years ago was that BGP convergence time was
> faster with higher MTU.
> Full BGP table load took twice less time on MTU 9192 than on 1500.
> Of course BGP has to be allowed to use higher MTU.
>
> Anyone else observed something similar?

Yes, of course. Larger MSS for BGP updates means fewer BGP updates
within which convergence can occur.

The problem is eBGP sessions are generally ran between different
networks, where co-ordinating MTU can be an issue.

Mark.


From tore at fud.no  Sat Jul 23 08:28:49 2016
From: tore at fud.no (Tore Anderson)
Date: Sat, 23 Jul 2016 10:28:49 +0200
Subject: MTU
In-Reply-To: <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>
References: <CAPkb-7CRMNUK6Av-BBzUgMLh2YW0XfxDs4x4P4rJg6ookVNP=A@mail.gmail.com>
 <CAPkb-7B6cav2LHgdCE6Ywq4pKgb1MqVjEgKoFZG+JzKf73cA8w@mail.gmail.com>
 <CAPkb-7CTi_ekX35OcjdwqfM+W-gdkfkfpLsHXxhH5bVr=nyv3A@mail.gmail.com>
 <CAPkb-7CnxtLuWWA+PDx2ba_xkaE54+Ei4NAbZp7TzvgdGi2Auw@mail.gmail.com>
 <CAPkb-7B3geM2iydgmidq+gFh4oJvzbCj_eznQSvLRhi3LGgvCA@mail.gmail.com>
 <CAPkb-7C78wAAYrdfgZB65W=tJRumUb3qbVGVE1u28V7DTP82Ww@mail.gmail.com>
 <CAPkb-7A1RsiN=tv6YuggARbUx2u8EDOUyHc__BJ6iB=UFWxs4Q@mail.gmail.com>
 <CAPkb-7AQTQnuv9baaO=yEG0e+s0O1ppopafsCNoP8bSuCMysxg@mail.gmail.com>
 <CAPkb-7AXhoCrVnWv+pzbJGPW86mvzGmGuitqscqQ7AJFrriDRg@mail.gmail.com>
 <CAPkb-7BaGqybRDLRd01E65bmzoc-1ebnuYsEtYsSU8VLu5dp3A@mail.gmail.com>
 <CAPkb-7BAjMO2sdY=87J6S6yd8oecyr1gyJa_jqaQUy7=XU0oAw@mail.gmail.com>
 <CAPkb-7A5TgL+dL8D48sccHSCVcHWEah9sv3hZT-7j=kN4aKnYQ@mail.gmail.com>
 <CAPkb-7DtxSt=9vgBviZBSaxN57q=wkDJw+6m=RBmf01s9GtVXw@mail.gmail.com>
 <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>
Message-ID: <20160723102849.73c7367f@envy.e1.y.home>

* Baldur Norddahl

> What is best practice regarding choosing MTU on transit links?
> 
> Until now we have used the default of 1500 bytes. I now have a
> project were we peer directly with another small ISP. However we need
> a backup so we figured a GRE tunnel on a common IP transit carrier
> would work. We want to avoid the troubles you get by having an
> effective MTU smaller than 1500 inside the tunnel, so the IP transit
> carrier agreed to configure a MTU of 9216.

You use case as described above puzzles me. You should already your
peer's routes being advertised to you via the transit provider and vice
versa. If your direct peering fails, the traffic should start flowing
via the transit provider automatically. So unless there's something
else going on here you're not telling us there should be no need for
the GRE tunnel.

That said, it should work, as long as the MTU is increased in both ends
and the transit network guarantees it will transports the jumbos.

We're doing something similar, actually. We have multiple sites
connected with either dark fibre or DWDM, but not always in a redundant
fashion. So instead we run GRE tunnels through transit (with increased
MTU) between selected sites to achieve full redundancy. This has worked
perfectly so far. It's only used for our intra-AS IP/MPLS traffic
though, not for eBGP like you're considering.

> Obviously I only need to increase my MTU by the size of the GRE
> header. But I am thinking is there any reason not to go all in and
> ask every peer to go to whatever max MTU they can support? My own
> equipment will do MTU of 9600 bytes.

I'd say it's not worth the trouble unless you know you're going to use
it for anything. If I was your peer I'd certainly need you to give me a
good reason why I should deviate from my standard templates first...

> On the other hand, none of my customers will see any actual difference
> because they are end users with CPE equipment that expects a 1500
> byte MTU. Trying to deliver jumbo frames to the end users is probably
> going to end badly.

Depends on the end user, I guess. Residential? Agreed. Business? Who
knows - maybe they would like to run fat GRE tunnels through your
network? In any case: 1500 by default, other values only by request.

Tore


From cabo at tzi.org  Sat Jul 23 09:55:01 2016
From: cabo at tzi.org (Carsten Bormann)
Date: Sat, 23 Jul 2016 11:55:01 +0200
Subject: IPv6 Deployment for Mobile Subscribers
In-Reply-To: <CAE0OVL9f9JEMDWx3-DzH7-nQUbWJFGAE5oWfWN-sX6MXhMtq_A@mail.gmail.com>
References: <CAE0OVL9f9JEMDWx3-DzH7-nQUbWJFGAE5oWfWN-sX6MXhMtq_A@mail.gmail.com>
Message-ID: <57933EF5.7030304@tzi.org>

RFC 6177:

   This document obsoletes RFC 3177, updating its recommendations in the
   following ways:

      1) It is no longer recommended that /128s be given out.  While
         there may be some cases where assigning only a single address
         may be justified, a site, by definition, implies multiple
         subnets and multiple devices.

Generally, when you look at an obsolete document such as

https://tools.ietf.org/html/rfc3177

there is a link to the current version ("Obsoleted by: 6177"):

https://tools.ietf.org/html/rfc6177

Do not use websites showing RFCs that do not show this information;
you'll be stuck with outdated specifications.

Gr??e, Carsten


Ricardo Ferreira wrote:
> Is there anyone here working in an ISP where IPv6 is deployed?
> We are starting to plan the roll-out IPv6 to mobile subscribers (phones) I
> am interesting in knowing the mask you use for the assignment; whether it
> is /64 or /128.
> 
> In RFC 3177, it says:
> 3. Address Delegation Recommendations
> 
>    The IESG and the IAB recommend the allocations for the boundary
>    between the public and the private topology to follow those general
>    rules:
> 
>       -  /48 in the general case, except for very large subscribers.
>       -  /64 when it is known that one and only one subnet is needed by
>          design.
>       -  /128 when it is absolutely known that one and only one device
>          is connecting.
> 
> Basically a sole device will be connecting to the internet so I am
> wondering if this rule is follwed.
> 
> Cheers
> 

From baldur.norddahl at gmail.com  Sat Jul 23 10:17:30 2016
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Sat, 23 Jul 2016 12:17:30 +0200
Subject: MTU
In-Reply-To: <20160723102849.73c7367f@envy.e1.y.home>
References: <CAPkb-7CRMNUK6Av-BBzUgMLh2YW0XfxDs4x4P4rJg6ookVNP=A@mail.gmail.com>
 <CAPkb-7B6cav2LHgdCE6Ywq4pKgb1MqVjEgKoFZG+JzKf73cA8w@mail.gmail.com>
 <CAPkb-7CTi_ekX35OcjdwqfM+W-gdkfkfpLsHXxhH5bVr=nyv3A@mail.gmail.com>
 <CAPkb-7CnxtLuWWA+PDx2ba_xkaE54+Ei4NAbZp7TzvgdGi2Auw@mail.gmail.com>
 <CAPkb-7B3geM2iydgmidq+gFh4oJvzbCj_eznQSvLRhi3LGgvCA@mail.gmail.com>
 <CAPkb-7C78wAAYrdfgZB65W=tJRumUb3qbVGVE1u28V7DTP82Ww@mail.gmail.com>
 <CAPkb-7A1RsiN=tv6YuggARbUx2u8EDOUyHc__BJ6iB=UFWxs4Q@mail.gmail.com>
 <CAPkb-7AQTQnuv9baaO=yEG0e+s0O1ppopafsCNoP8bSuCMysxg@mail.gmail.com>
 <CAPkb-7AXhoCrVnWv+pzbJGPW86mvzGmGuitqscqQ7AJFrriDRg@mail.gmail.com>
 <CAPkb-7BaGqybRDLRd01E65bmzoc-1ebnuYsEtYsSU8VLu5dp3A@mail.gmail.com>
 <CAPkb-7BAjMO2sdY=87J6S6yd8oecyr1gyJa_jqaQUy7=XU0oAw@mail.gmail.com>
 <CAPkb-7A5TgL+dL8D48sccHSCVcHWEah9sv3hZT-7j=kN4aKnYQ@mail.gmail.com>
 <CAPkb-7DtxSt=9vgBviZBSaxN57q=wkDJw+6m=RBmf01s9GtVXw@mail.gmail.com>
 <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>
 <20160723102849.73c7367f@envy.e1.y.home>
Message-ID: <CAPkb-7DdY=0-fupX3V9CMiV6vSK2+LQrs4a7+KgCVFA7XLjpSw@mail.gmail.com>

On 23 July 2016 at 10:28, Tore Anderson <tore at fud.no> wrote:

> * Baldur Norddahl
>
> > What is best practice regarding choosing MTU on transit links?
> >
> > Until now we have used the default of 1500 bytes. I now have a
> > project were we peer directly with another small ISP. However we need
> > a backup so we figured a GRE tunnel on a common IP transit carrier
> > would work. We want to avoid the troubles you get by having an
> > effective MTU smaller than 1500 inside the tunnel, so the IP transit
> > carrier agreed to configure a MTU of 9216.
>
> You use case as described above puzzles me. You should already your
> peer's routes being advertised to you via the transit provider and vice
> versa. If your direct peering fails, the traffic should start flowing
> via the transit provider automatically. So unless there's something
> else going on here you're not telling us there should be no need for
> the GRE tunnel.
>

I did not say we were doing internet peering...

In case you are wondering, we are actually running L2VPN tunnels over MPLS.

Regards,

Baldur

From tore at fud.no  Sat Jul 23 11:32:05 2016
From: tore at fud.no (Tore Anderson)
Date: Sat, 23 Jul 2016 13:32:05 +0200
Subject: MTU
In-Reply-To: <CAPkb-7DdY=0-fupX3V9CMiV6vSK2+LQrs4a7+KgCVFA7XLjpSw@mail.gmail.com>
References: <CAPkb-7CRMNUK6Av-BBzUgMLh2YW0XfxDs4x4P4rJg6ookVNP=A@mail.gmail.com>
 <CAPkb-7CnxtLuWWA+PDx2ba_xkaE54+Ei4NAbZp7TzvgdGi2Auw@mail.gmail.com>
 <CAPkb-7B3geM2iydgmidq+gFh4oJvzbCj_eznQSvLRhi3LGgvCA@mail.gmail.com>
 <CAPkb-7C78wAAYrdfgZB65W=tJRumUb3qbVGVE1u28V7DTP82Ww@mail.gmail.com>
 <CAPkb-7A1RsiN=tv6YuggARbUx2u8EDOUyHc__BJ6iB=UFWxs4Q@mail.gmail.com>
 <CAPkb-7AQTQnuv9baaO=yEG0e+s0O1ppopafsCNoP8bSuCMysxg@mail.gmail.com>
 <CAPkb-7AXhoCrVnWv+pzbJGPW86mvzGmGuitqscqQ7AJFrriDRg@mail.gmail.com>
 <CAPkb-7BaGqybRDLRd01E65bmzoc-1ebnuYsEtYsSU8VLu5dp3A@mail.gmail.com>
 <CAPkb-7BAjMO2sdY=87J6S6yd8oecyr1gyJa_jqaQUy7=XU0oAw@mail.gmail.com>
 <CAPkb-7A5TgL+dL8D48sccHSCVcHWEah9sv3hZT-7j=kN4aKnYQ@mail.gmail.com>
 <CAPkb-7DtxSt=9vgBviZBSaxN57q=wkDJw+6m=RBmf01s9GtVXw@mail.gmail.com>
 <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>
 <20160723102849.73c7367f@envy.e1.y.home>
 <CAPkb-7DdY=0-fupX3V9CMiV6vSK2+LQrs4a7+KgCVFA7XLjpSw@mail.gmail.com>
Message-ID: <20160723133205.4def0919@envy.e1.y.home>

* Baldur Norddahl

> I did not say we were doing internet peering...

Uhm. When you say that you peer with another ISP (and keep in mind what
the "I" in ISP stands for), while giving no further details, then folks
are going to assume that you're talking about a standard eBGP peering
with inet/inet6 unicast NLRIs.

> In case you are wondering, we are actually running L2VPN tunnels over
> MPLS.

Okay. Well, I see no reason why using GRE tunnels for this purpose
shouldn't work, it does for us (using mostly VPLS and Martini tunnels).

That said, I've never tried extending our MPLS backbone outside of
our own administrative domain or autonomous system. That sounds like a
really scary prospect to me, but I'll admit I've never given serious
consideration to such an arrangement before. Hopefully you know what
you're doing.

Tore

From mark.tinka at seacom.mu  Sat Jul 23 11:41:20 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Sat, 23 Jul 2016 13:41:20 +0200
Subject: MTU
In-Reply-To: <20160723133205.4def0919@envy.e1.y.home>
References: <CAPkb-7CRMNUK6Av-BBzUgMLh2YW0XfxDs4x4P4rJg6ookVNP=A@mail.gmail.com>
 <CAPkb-7CnxtLuWWA+PDx2ba_xkaE54+Ei4NAbZp7TzvgdGi2Auw@mail.gmail.com>
 <CAPkb-7B3geM2iydgmidq+gFh4oJvzbCj_eznQSvLRhi3LGgvCA@mail.gmail.com>
 <CAPkb-7C78wAAYrdfgZB65W=tJRumUb3qbVGVE1u28V7DTP82Ww@mail.gmail.com>
 <CAPkb-7A1RsiN=tv6YuggARbUx2u8EDOUyHc__BJ6iB=UFWxs4Q@mail.gmail.com>
 <CAPkb-7AQTQnuv9baaO=yEG0e+s0O1ppopafsCNoP8bSuCMysxg@mail.gmail.com>
 <CAPkb-7AXhoCrVnWv+pzbJGPW86mvzGmGuitqscqQ7AJFrriDRg@mail.gmail.com>
 <CAPkb-7BaGqybRDLRd01E65bmzoc-1ebnuYsEtYsSU8VLu5dp3A@mail.gmail.com>
 <CAPkb-7BAjMO2sdY=87J6S6yd8oecyr1gyJa_jqaQUy7=XU0oAw@mail.gmail.com>
 <CAPkb-7A5TgL+dL8D48sccHSCVcHWEah9sv3hZT-7j=kN4aKnYQ@mail.gmail.com>
 <CAPkb-7DtxSt=9vgBviZBSaxN57q=wkDJw+6m=RBmf01s9GtVXw@mail.gmail.com>
 <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>
 <20160723102849.73c7367f@envy.e1.y.home>
 <CAPkb-7DdY=0-fupX3V9CMiV6vSK2+LQrs4a7+KgCVFA7XLjpSw@mail.gmail.com>
 <20160723133205.4def0919@envy.e1.y.home>
Message-ID: <9eb5a407-0faa-e49c-e360-f8627306e379@seacom.mu>



On 23/Jul/16 13:32, Tore Anderson wrote:

>
> That said, I've never tried extending our MPLS backbone outside of
> our own administrative domain or autonomous system. That sounds like a
> really scary prospect to me, but I'll admit I've never given serious
> consideration to such an arrangement before. Hopefully you know what
> you're doing.

Well, you can extend your MPLS-based services outside your domain
through an NNI. Fair point, you generally won't run MPLS with your NNI
partner, but they will carry your services across their own MPLS network
toward their destination on the B-end.

With such an arrangement, one can co-ordinate that capabilities between
different networks are mirrored even though there isn't end-to-end
control for either NNI partner.

Mark.

From ryan at finnesey.com  Sat Jul 23 12:31:20 2016
From: ryan at finnesey.com (Ryan Finnesey)
Date: Sat, 23 Jul 2016 12:31:20 +0000
Subject: number of characters in a domain?
Message-ID: <BLUPR05MB595288C33C56BE9A7FD8181B40B0@BLUPR05MB595.namprd05.prod.outlook.com>

I was hoping someone can help me confirm my research.  I am correct that domains are now limited to 67 characters in length including the extension?

Cheers
Ryan


From jared at puck.nether.net  Sat Jul 23 12:35:57 2016
From: jared at puck.nether.net (Jared Mauch)
Date: Sat, 23 Jul 2016 08:35:57 -0400
Subject: number of characters in a domain?
In-Reply-To: <BLUPR05MB595288C33C56BE9A7FD8181B40B0@BLUPR05MB595.namprd05.prod.outlook.com>
References: <BLUPR05MB595288C33C56BE9A7FD8181B40B0@BLUPR05MB595.namprd05.prod.outlook.com>
Message-ID: <90A5954E-1F29-40E1-9890-3635521CCF28@puck.nether.net>

I would consult RFC1035 for the label sizes, but the total length can include multiple labels up to 255 in length. Check section 2.3.4

Jared Mauch

> On Jul 23, 2016, at 8:31 AM, Ryan Finnesey <ryan at finnesey.com> wrote:
> 
> I was hoping someone can help me confirm my research.  I am correct that domains are now limited to 67 characters in length including the extension?
> 
> Cheers
> Ryan


From bortzmeyer at nic.fr  Sat Jul 23 14:01:06 2016
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Sat, 23 Jul 2016 16:01:06 +0200
Subject: number of characters in a domain?
In-Reply-To: <90A5954E-1F29-40E1-9890-3635521CCF28@puck.nether.net>
References: <BLUPR05MB595288C33C56BE9A7FD8181B40B0@BLUPR05MB595.namprd05.prod.outlook.com>
 <90A5954E-1F29-40E1-9890-3635521CCF28@puck.nether.net>
Message-ID: <20160723140106.GA6716@nic.fr>

On Sat, Jul 23, 2016 at 08:35:57AM -0400,
 Jared Mauch <jared at puck.nether.net> wrote 
 a message of 12 lines which said:

> I would consult RFC1035 for the label sizes, but the total length
> can include multiple labels up to 255 in length. Check section 2.3.4

On another mailing list, Marc Blanchet noticed the limit in the RFC is
255 octets, not characters, which make a difference if you use IDN :-)

From mysidia at gmail.com  Sat Jul 23 15:07:52 2016
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 23 Jul 2016 10:07:52 -0500
Subject: number of characters in a domain?
In-Reply-To: <BLUPR05MB595288C33C56BE9A7FD8181B40B0@BLUPR05MB595.namprd05.prod.outlook.com>
References: <BLUPR05MB595288C33C56BE9A7FD8181B40B0@BLUPR05MB595.namprd05.prod.outlook.com>
Message-ID: <CAAAwwbVzY3Qam8q9ERVvKJtM8RaksHmVainLwbxQHs6cNUaugQ@mail.gmail.com>

On Sat, Jul 23, 2016 at 7:31 AM, Ryan Finnesey <ryan at finnesey.com> wrote:
> I was hoping someone can help me confirm my research.  I am correct that domains are now limited to 67 characters in length including the extension?
>

RFC1035;  A hostname / FQDN cannot exceed 255 octets in totality.
This includes all the label-length fields,  therefore, the limit
on total human-readable FQDN string is less.

(Subtract 1 Octets initially,  then subtract more octets for every
DNS Path component added,  including the Null label at the End of every FQDN.)

In addition, the string component of each DNS label is limited to 63 octets.

-- 
-JH

From bill at herrin.us  Sat Jul 23 16:36:10 2016
From: bill at herrin.us (William Herrin)
Date: Sat, 23 Jul 2016 12:36:10 -0400
Subject: number of characters in a domain?
In-Reply-To: <CAAAwwbVzY3Qam8q9ERVvKJtM8RaksHmVainLwbxQHs6cNUaugQ@mail.gmail.com>
References: <BLUPR05MB595288C33C56BE9A7FD8181B40B0@BLUPR05MB595.namprd05.prod.outlook.com>
 <CAAAwwbVzY3Qam8q9ERVvKJtM8RaksHmVainLwbxQHs6cNUaugQ@mail.gmail.com>
Message-ID: <CAP-guGWWgYv8WP_usiZWr5r5k3d1q2yBA-inNRkTybstLFk7rQ@mail.gmail.com>

On Sat, Jul 23, 2016 at 11:07 AM, Jimmy Hess <mysidia at gmail.com> wrote:
> In addition, the string component of each DNS label is limited to 63 octets.

This is a hard limit in the DNS packet format. In the packet, the dots
are replaced by either:

1 byte whose high two bits are 0 and whose low six bits are the length
of the next label, 0 to 63. 0 means done, end of the name.

2 bytes, whose high two bits are 1 and whose low 14 bits are the byte
offset within the DNS packet where the name continues


So what happens is: if there are three names in the DNS packet:
www.example.com, ns1.example.com, and ns2.example.com, then the packet
will store www.example.com in full (with the dots replaced with the
next label length) and then it'll store ns1 followed by a pointer to
where "example.com" began in www.example.com and finally it'll store
ns2 followed by a pointer to where "example.com" began in
www.example.com.

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From matt at conundrum.com  Sat Jul 23 14:07:49 2016
From: matt at conundrum.com (Matthew Pounsett)
Date: Sat, 23 Jul 2016 16:07:49 +0200
Subject: number of characters in a domain?
In-Reply-To: <BLUPR05MB595288C33C56BE9A7FD8181B40B0@BLUPR05MB595.namprd05.prod.outlook.com>
References: <BLUPR05MB595288C33C56BE9A7FD8181B40B0@BLUPR05MB595.namprd05.prod.outlook.com>
Message-ID: <CAAiTEH_O6-Qsd5fDzguwuZ6-QGcyXkh=DqDK3kDUHHG3Tp=1qQ@mail.gmail.com>

On 23 July 2016 at 14:31, Ryan Finnesey <ryan at finnesey.com> wrote:

> I was hoping someone can help me confirm my research.  I am correct that
> domains are now limited to 67 characters in length including the extension?
>

63 octets per label (the bits between the period separators) , 255 octets
per domain name. In ascii octets and characters are interchangeable, but as
Stephan noted, it gets slightly more complicated for IDN.

From dougb at dougbarton.us  Sat Jul 23 19:31:39 2016
From: dougb at dougbarton.us (Doug Barton)
Date: Sat, 23 Jul 2016 12:31:39 -0700
Subject: number of characters in a domain?
In-Reply-To: <CAAiTEH_O6-Qsd5fDzguwuZ6-QGcyXkh=DqDK3kDUHHG3Tp=1qQ@mail.gmail.com>
References: <BLUPR05MB595288C33C56BE9A7FD8181B40B0@BLUPR05MB595.namprd05.prod.outlook.com>
 <CAAiTEH_O6-Qsd5fDzguwuZ6-QGcyXkh=DqDK3kDUHHG3Tp=1qQ@mail.gmail.com>
Message-ID: <5793C61B.4080107@dougbarton.us>

On 07/23/2016 07:07 AM, Matthew Pounsett wrote:
> On 23 July 2016 at 14:31, Ryan Finnesey <ryan at finnesey.com> wrote:
>
>> I was hoping someone can help me confirm my research.  I am correct that
>> domains are now limited to 67 characters in length including the extension?
>>
>
> 63 octets per label (the bits between the period separators) , 255 octets
> per domain name. In ascii octets and characters are interchangeable, but as
> Stephan noted, it gets slightly more complicated for IDN.

Not really ... the 1035 limits apply to the A-label


From jared at puck.nether.net  Sat Jul 23 19:46:55 2016
From: jared at puck.nether.net (Jared Mauch)
Date: Sat, 23 Jul 2016 15:46:55 -0400
Subject: BGP &  MTU
In-Reply-To: <520e997e-9c83-3d1c-b99b-b818e3ea3b16@Janoszka.pl>
References: <CAPkb-7CRMNUK6Av-BBzUgMLh2YW0XfxDs4x4P4rJg6ookVNP=A@mail.gmail.com>
 <CAPkb-7CTi_ekX35OcjdwqfM+W-gdkfkfpLsHXxhH5bVr=nyv3A@mail.gmail.com>
 <CAPkb-7CnxtLuWWA+PDx2ba_xkaE54+Ei4NAbZp7TzvgdGi2Auw@mail.gmail.com>
 <CAPkb-7B3geM2iydgmidq+gFh4oJvzbCj_eznQSvLRhi3LGgvCA@mail.gmail.com>
 <CAPkb-7C78wAAYrdfgZB65W=tJRumUb3qbVGVE1u28V7DTP82Ww@mail.gmail.com>
 <CAPkb-7A1RsiN=tv6YuggARbUx2u8EDOUyHc__BJ6iB=UFWxs4Q@mail.gmail.com>
 <CAPkb-7AQTQnuv9baaO=yEG0e+s0O1ppopafsCNoP8bSuCMysxg@mail.gmail.com>
 <CAPkb-7AXhoCrVnWv+pzbJGPW86mvzGmGuitqscqQ7AJFrriDRg@mail.gmail.com>
 <CAPkb-7BaGqybRDLRd01E65bmzoc-1ebnuYsEtYsSU8VLu5dp3A@mail.gmail.com>
 <CAPkb-7BAjMO2sdY=87J6S6yd8oecyr1gyJa_jqaQUy7=XU0oAw@mail.gmail.com>
 <CAPkb-7A5TgL+dL8D48sccHSCVcHWEah9sv3hZT-7j=kN4aKnYQ@mail.gmail.com>
 <CAPkb-7DtxSt=9vgBviZBSaxN57q=wkDJw+6m=RBmf01s9GtVXw@mail.gmail.com>
 <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>
 <CAP-guGUcE_wrbZdZX7rO2nN1GGREuqVrWfJ37CqY7MRLBZTTSw@mail.gmail.com>
 <520e997e-9c83-3d1c- b99b-b818e3ea3b16@Janoszka.pl>
Message-ID: <72ABD4F9-3017-4517-82F6-5DD7506106A7@puck.nether.net>


> On Jul 22, 2016, at 1:37 PM, Grzegorz Janoszka <Grzegorz at Janoszka.pl> wrote:
> 
> On 2016-07-22 15:57, William Herrin wrote:
>> On a link containing only routers, you can safely increase the MTU to
>> any mutually agreed value with these caveats:
> 
> What I noticed a few years ago was that BGP convergence time was faster with higher MTU.
> Full BGP table load took twice less time on MTU 9192 than on 1500.
> Of course BGP has to be allowed to use higher MTU.
> 
> Anyone else observed something similar?

This has been well known for years:

http://morse.colorado.edu/~epperson/courses/routing-protocols/handouts/bgp_scalability_IETF.ppt

You have to adjust the MTU, Input queues and such.  The default TCP stack is very conservative.

- Jared

From marka at isc.org  Sun Jul 24 05:03:20 2016
From: marka at isc.org (Mark Andrews)
Date: Sun, 24 Jul 2016 15:03:20 +1000
Subject: number of characters in a domain?
In-Reply-To: Your message of "Sat, 23 Jul 2016 12:31:39 -0700."
 <5793C61B.4080107@dougbarton.us>
References: <BLUPR05MB595288C33C56BE9A7FD8181B40B0@BLUPR05MB595.namprd05.prod.outlook.com>
 <CAAiTEH_O6-Qsd5fDzguwuZ6-QGcyXkh=DqDK3kDUHHG3Tp=1qQ@mail.gmail.com>
 <5793C61B.4080107@dougbarton.us>
Message-ID: <20160724050320.C9F564F4EBBC@rock.dv.isc.org>


The number of wire octets is <= 255.
The number of presentation characters <= 1008 (63*4*3 + 62*4 + 4)

In message <5793C61B.4080107 at dougbarton.us>, Doug Barton writes:
> On 07/23/2016 07:07 AM, Matthew Pounsett wrote:
> > On 23 July 2016 at 14:31, Ryan Finnesey <ryan at finnesey.com> wrote:
> >
> >> I was hoping someone can help me confirm my research.  I am correct that
> >> domains are now limited to 67 characters in length including the extension?
> >>
> >
> > 63 octets per label (the bits between the period separators) , 255 octets
> > per domain name. In ascii octets and characters are interchangeable, but as
> > Stephan noted, it gets slightly more complicated for IDN.
> 
> Not really ... the 1035 limits apply to the A-label
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

From yang.yu.list at gmail.com  Mon Jul 25 08:35:04 2016
From: yang.yu.list at gmail.com (Yang Yu)
Date: Mon, 25 Jul 2016 03:35:04 -0500
Subject: Akamai IPv6 contact needed
Message-ID: <CAFwKRnTNjU23We6xMvU07XPH+RUwRGoxGTryG2Pptq4cd4T1VA@mail.gmail.com>

Some servers are not serving content over IPv6 HTTPS. It fails in such
a way that most applications can't fall back to IPv4. tcp/443 is open
but RST as soon as client sends TLS 1.2 client hello. It has been this
way for 24+ hours.

>>>
$ telnet 2600:1404:18::17d7:fbc 443
Trying 2600:1404:18::17d7:fbc...
Connected to 2600:1404:18::17d7:fbc.
Escape character is '^]'.

Connection closed by foreign host

>
ncat -6 --ssl -v 2600:1404:18::17d7:fac 443
Ncat: Version 7.00SVN ( https://nmap.org/ncat )
Ncat: Input/output error.


>>>
www.apple.com.          681     IN      CNAME   www.apple.com.edgekey.net.
www.apple.com.edgekey.net. 11306 IN     CNAME
www.apple.com.edgekey.net.globalredir.akadns.net.
www.apple.com.edgekey.net.globalredir.akadns.net. 1664 IN CNAME
e6858.dscc.akamaiedge.net.
e6858.dscc.akamaiedge.net. 5    IN      AAAA    2600:1404:18::17d7:fac
e6858.dscc.akamaiedge.net. 5    IN      AAAA    2600:1404:18::17d7:fbc

>
2600:1404:18::17d7:0/112 serves www.apple.com, download.microsoft.com etc.


>>> HTTP does work
$ wget http://www.apple.com
--2016-07-25 03:09:17--  http://www.apple.com/
Resolving www.apple.com (www.apple.com)... 2600:1404:18::17d7:fbc,
2600:1404:18::17d7:fac, 23.11.55.206
Connecting to www.apple.com
(www.apple.com)|2600:1404:18::17d7:fbc|:80... connected.
HTTP request sent, awaiting response... 200 OK

>>>
$ dig whoami.akamai.com +short
whoami.akamai.net.
72.183.81.39


Thanks.


Yang

From benno at NLnetLabs.nl  Mon Jul 25 14:15:50 2016
From: benno at NLnetLabs.nl (Benno Overeinder)
Date: Mon, 25 Jul 2016 16:15:50 +0200
Subject: Call for presentations RIPE 73
Message-ID: <c840dc97-0e19-753e-bdd2-967b57c9acb6@NLnetLabs.nl>

Dear colleagues,

Please find the CFP for RIPE 73 below or at
https://ripe73.ripe.net/submit-topic/cfp/.

The deadline for submissions is 28 August 2016.

Please also note that speakers do not receive any extra reduction or
funding towards the meeting fee at the RIPE Meetings.

Kind regards,

Benno Overeinder
RIPE PC Chair
https://www.ripe.net/participate/meetings/ripe-meetings/pc


-------------------->>><<<--------------------

Call for Presentations

A RIPE Meeting is an open event where Internet Service Providers,
network operators and other interested parties get together.  Although
the meeting is mostly technical, it is also a chance for people to meet
and network with others in their field.

RIPE 73 will take place from 24-28 October 2016 in Madrid, Spain.

The RIPE Programme Committee (PC) is now seeking content proposals from
the RIPE community for the plenary sessions, BoFs (Birds of a Feather
sessions), panels, workshops, tutorials and lightning talks at RIPE 73.
See the full descriptions of the different presentation formats,
https://ripe73.ripe.net/submit-topic/presentation-formats/.

Proposals for plenary sessions, BoFs, panels, workshops and tutorials
must be submitted for full consideration no later than 28 August 2016.
Proposals submitted after this date will be considered depending on the
remaining available space in the programme.

The PC is looking for presentations covering topics of network
engineering and operations, including but not limited to:

- IPv6 deployment
- Managing IPv4 scarcity in operations
- Commercial transactions of IPv4 addresses
- Data centre technologies
- Network and DNS operations
- Internet governance and regulatory practices
- Network and routing security
- Content delivery
- Internet peering and mobile data exchange
- Internet of Things (IoT)


Submissions

RIPE Meeting attendees are quite sensitive to keeping presentations
non-commercial, and product marketing talks are strongly discouraged.
Repeated audience feedback shows that the most successful talks focus on
operational experience, research results, or case studies.  For example,
presenters wishing to describe a commercial solution should focus on the
underlying technology and not attempt a product demonstration.

Presenters should indicate how much time they will require.  In general,
the time allocated for the different presentation formats is as follows:

- Plenary presentations: 20-25 minutes presentation with 5-10 minutes
  discussion
- Tutorials: up to two hours (Monday morning)
- Workshops: one hour (during evening sessions) to two hours (Monday
  morning)
- BoFs: approximately one hour
- Lightning talks: 10 minutes

The following general requirements apply:

- Proposals must be submitted using the meeting submission system,
  https://ripe73.ripe.net/submit-topic/submission-form/.

- Lightning talks should also be submitted using the meeting submission
  system (https://ripe73.ripe.net/submit-topic/submission-form/) and can
  be submitted any time up to and including the meeting week. The
  allocation of lightning talks will be announced on short notice---in
  some cases on the same day but often one day prior to the time slot
  allocated.

- Presenters who propose a panel or BoF are encouraged to include
  speakers from several (perhaps even competing) companies and/or a
  neutral facilitator.

- All presentation proposals will only be considered by the PC if they
  contain at least draft presentation slides (slides may be updated
  later on). For panels, proposals must contain a clear description, as
  well as the names of invited panellists, presenters and moderators.

- Due to potential technical issues, presenters/panellists should be
  physically present at the RIPE Meeting.

If you have any questions or requests concerning content submissions,
please email pc [at] ripe [dot] net.

-- 
Benno J. Overeinder
NLnet Labs
http://www.nlnetlabs.nl/


From starwars1070 at gmail.com  Mon Jul 25 16:11:29 2016
From: starwars1070 at gmail.com (sam)
Date: Mon, 25 Jul 2016 09:11:29 -0700
Subject: students questions 
Message-ID: <029301d1e68f$34892510$9d9b6f30$@gmail.com>

Hello if this is not appropriate for this list please excuse me and
disregard this email. I thought of no better place than this place however
if there is a better place for this email please advise and I will direct
the email and the student to the questions.

I received an email form a student this morning asking the following
questions. 
1.      Are there any email providers that market to professional but offer
a student rate or are of good quality but inexpensive etc..

2.      I have looked at the Microsoft exchange server in the cloud while it
looks promising it does not seems to fit my cost ratio 

3.      I would mainly like to be able to have a professional email address
so when I apply for jobs and other business of that sort I can be seen as a
professional and to gather my email from various sources i.e. Gmail, Hotmail
etc. and to present a more professional appearance to my work and school
work etc..

  
  
I responded that he should look at google apps, however his questions got me
thinking and I google around for an answer to give him, however I am not as
well versed as I should be in the cloud besides for backup service and
active directory management. I would like to know if you guys have any
places I own give the student. 

  
Thanks 
Samual 
Office of technology education 
  
Please excuse grammar and spelling errors as this was typed on a smartphone.

  

-----BEGIN PGP MESSAGE----- 
Version: GnuPG v2 

owFdVAtsFEUYbqkQvPQoGgpUHo5FzEHKUcqr2FCoILY8pFCQR1Jlbnf2brndnXVm 
t9fjFSOCFtBUimjBNtJCI5AIFOQhFbSgxAgURQIo8rKIaUTTVBERxH9274rlcpfb 
2fn/b77/+79/yr1JCV0TScLQ81mX05oSv24JJMxZP+ZGPtE0ilQFWSGVI/ga1ELY 
NBk1mYotghTK3D1N5RYyNYI5QaRUsuFPJwgbMpJVzkgQM9kNJDpWNT8qgBW1gyEL 
UQVQUYBYFmGAgCUCW9hwo911iEZICew6RAgjggnumNJOxMGPM8FyicpdGgUoomoa 
sGFEsgRMLFLsiRW3bJkYsEOd5cs24ZZKDe73egoQ5BC1hMgQHUuD83Tg0J4ljtYp 
M1QjiDAPiz8Bo1AQMCJW9wGR1zPMj5xPHiOxirARjVNntESVCeNCBgvpmIWJQws2 
FMI5YGANBWyhnAL13yfBREdABwx4oGqQUhmOxZpqRZ141SClJjE4VIKIJfmvvlLn 
9WTFqBSgEIb3GqVhUacr0TRVYpRTxRI9haYEQSfCnFYYToCkUVtGkZCqQVMsJ5sL 
orrKRdHwSqbEtQ0nROeiDgXe6lEkUe5QVikIMrydRYTamgxVq4YWBVeFiUgJgEAB 
zXl0WOKOYsQ6KcsMXiFOgRAxAAucCiDCGgtpgDutpkJuUAPoiViquCpzyixIkKC/ 
AVEjpGP+4DGOVSgKYgdDjzdMgXJRCWYqtcXhNpOgYtVP/Og5sZ+B8qnlBArN4yAm 
UBU9w8I15IFzTJNghg3JKRjOiVAWdhK5FKJUc9cCDcyJkPsTJuUmNWQiuyUJT4cc 
MUVXREfBEEEQEeB5RvtMCeO2exNCLDG3Vuizo6rhuNidnXgqozashaKgFDZ4BBCE 
JMJSIVW/Dwvi6+5twVEEbhEEL7kwFoetGC9QuoONAoSD8bkDH8BS2DYdt6mSO8FY 
ssQx7gRTFgWTGDhIdJDR326cuGPCBo2I+yJKbRS0ozzmG5gy574QLGjEcIn/b/z9 
MTVngdnByV5PEdZhguBhuqIIIsIwRAoZVKNBMIBsS8LBRiytsMMFGGRYh/F1O2eC 
CEJPwhiF2cbcvTMi4iFqgjIAAqMM8ZYZogZxmJR16vtQQmLXhC6dO4nrOMHzcPf4 
HX1lZMrtpMXDM+ftvL7Oc7V7y5oF/sNjKk+l7Mr9nQQWdvlW2pmknlp+7vGc5rsZ 
plKfdP3MrDtZ4S8b7/0yUL634+OKtwu9F36aNzmw+c3GwP59Y+f6sof+NWtagnW6 
fvvKaxNHlc2+lH/+yfU/D/lg8Onvvqqvz1g9s7ri2dTK6ak1ZxsSq349M6P12PSj 
Ff7RV7In59+yW58YtfiN6hHW9/4iVsX63t1mp51U01O+aPCkKgPeinqtCbt6k9oP 
UZ8B/RXfp59sKn5q0I4Zrd0KG7VFM7f3qBh7zB52ee+2C1OSD2x5/XgZe/Usa/ot 
reGdjNGh4p2Dt/zQduxE9b8NzX2Ti1bU7Njwnpl2boRP2tP0uS/vwv6LgTGD0s+Y 
f+fW6X/glpu9D437qLJ1LV7X3OtmwchFvjvrtFUvZC1flpgdJs3+rav6VfXvZmS3 
bFx6Ut2aeevA8dZ/LvqkouKNNT2u8aljlz82aUVb79bnB/65enxyy5L9RnmS52DO 
o20r26bOn1t46GDpKPvI3vpb41bMTrd6NY+P1r2WenjRxEsvLqC1czOz5uyaXz0n 
r8f5JRs2bV3ax/dS3chlJ2xf9e5Ma3TnnH63NynXOl2sThzx7pArFXTg7mGD/Pt6 
BtdWPpNXUj6pLP3p67Wh9xP31BypOlc8M6u0TfXmTkuxa298M6E0+Ui/NRWb0xt7 
7mnKrWPlRWkHShf/+EjOlP8A 
=cNlY 
-----END PGP MESSAGE----- 


From paras at protrafsolutions.com  Mon Jul 25 16:30:58 2016
From: paras at protrafsolutions.com (Paras Jha)
Date: Mon, 25 Jul 2016 12:30:58 -0400
Subject: students questions
In-Reply-To: <029301d1e68f$34892510$9d9b6f30$@gmail.com>
References: <029301d1e68f$34892510$9d9b6f30$@gmail.com>
Message-ID: <CAJayEpE5uHmbo0OWBi5p66nbNy4PFLBa2S6GAWJ=0gPoa2kKMA@mail.gmail.com>

Hi,

Try taking a look at Zoho, they offer what you're looking for for free.

Regards

On Mon, Jul 25, 2016 at 12:11 PM, sam <starwars1070 at gmail.com> wrote:

> Hello if this is not appropriate for this list please excuse me and
> disregard this email. I thought of no better place than this place however
> if there is a better place for this email please advise and I will direct
> the email and the student to the questions.
>
> I received an email form a student this morning asking the following
> questions.
> 1.      Are there any email providers that market to professional but offer
> a student rate or are of good quality but inexpensive etc..
>
> 2.      I have looked at the Microsoft exchange server in the cloud while
> it
> looks promising it does not seems to fit my cost ratio
>
> 3.      I would mainly like to be able to have a professional email address
> so when I apply for jobs and other business of that sort I can be seen as a
> professional and to gather my email from various sources i.e. Gmail,
> Hotmail
> etc. and to present a more professional appearance to my work and school
> work etc..
>
>
>
> I responded that he should look at google apps, however his questions got
> me
> thinking and I google around for an answer to give him, however I am not as
> well versed as I should be in the cloud besides for backup service and
> active directory management. I would like to know if you guys have any
> places I own give the student.
>
>
> Thanks
> Samual
> Office of technology education
>
> Please excuse grammar and spelling errors as this was typed on a
> smartphone.
>
>
>
> -----BEGIN PGP MESSAGE-----
> Version: GnuPG v2
>
> owFdVAtsFEUYbqkQvPQoGgpUHo5FzEHKUcqr2FCoILY8pFCQR1Jlbnf2brndnXVm
> t9fjFSOCFtBUimjBNtJCI5AIFOQhFbSgxAgURQIo8rKIaUTTVBERxH9274rlcpfb
> 2fn/b77/+79/yr1JCV0TScLQ81mX05oSv24JJMxZP+ZGPtE0ilQFWSGVI/ga1ELY
> NBk1mYotghTK3D1N5RYyNYI5QaRUsuFPJwgbMpJVzkgQM9kNJDpWNT8qgBW1gyEL
> UQVQUYBYFmGAgCUCW9hwo911iEZICew6RAgjggnumNJOxMGPM8FyicpdGgUoomoa
> sGFEsgRMLFLsiRW3bJkYsEOd5cs24ZZKDe73egoQ5BC1hMgQHUuD83Tg0J4ljtYp
> M1QjiDAPiz8Bo1AQMCJW9wGR1zPMj5xPHiOxirARjVNntESVCeNCBgvpmIWJQws2
> FMI5YGANBWyhnAL13yfBREdABwx4oGqQUhmOxZpqRZ141SClJjE4VIKIJfmvvlLn
> 9WTFqBSgEIb3GqVhUacr0TRVYpRTxRI9haYEQSfCnFYYToCkUVtGkZCqQVMsJ5sL
> orrKRdHwSqbEtQ0nROeiDgXe6lEkUe5QVikIMrydRYTamgxVq4YWBVeFiUgJgEAB
> zXl0WOKOYsQ6KcsMXiFOgRAxAAucCiDCGgtpgDutpkJuUAPoiViquCpzyixIkKC/
> AVEjpGP+4DGOVSgKYgdDjzdMgXJRCWYqtcXhNpOgYtVP/Og5sZ+B8qnlBArN4yAm
> UBU9w8I15IFzTJNghg3JKRjOiVAWdhK5FKJUc9cCDcyJkPsTJuUmNWQiuyUJT4cc
> MUVXREfBEEEQEeB5RvtMCeO2exNCLDG3Vuizo6rhuNidnXgqozashaKgFDZ4BBCE
> JMJSIVW/Dwvi6+5twVEEbhEEL7kwFoetGC9QuoONAoSD8bkDH8BS2DYdt6mSO8FY
> ssQx7gRTFgWTGDhIdJDR326cuGPCBo2I+yJKbRS0ozzmG5gy574QLGjEcIn/b/z9
> MTVngdnByV5PEdZhguBhuqIIIsIwRAoZVKNBMIBsS8LBRiytsMMFGGRYh/F1O2eC
> CEJPwhiF2cbcvTMi4iFqgjIAAqMM8ZYZogZxmJR16vtQQmLXhC6dO4nrOMHzcPf4
> HX1lZMrtpMXDM+ftvL7Oc7V7y5oF/sNjKk+l7Mr9nQQWdvlW2pmknlp+7vGc5rsZ
> plKfdP3MrDtZ4S8b7/0yUL634+OKtwu9F36aNzmw+c3GwP59Y+f6sof+NWtagnW6
> fvvKaxNHlc2+lH/+yfU/D/lg8Onvvqqvz1g9s7ri2dTK6ak1ZxsSq349M6P12PSj
> Ff7RV7In59+yW58YtfiN6hHW9/4iVsX63t1mp51U01O+aPCkKgPeinqtCbt6k9oP
> UZ8B/RXfp59sKn5q0I4Zrd0KG7VFM7f3qBh7zB52ee+2C1OSD2x5/XgZe/Usa/ot
> reGdjNGh4p2Dt/zQduxE9b8NzX2Ti1bU7Njwnpl2boRP2tP0uS/vwv6LgTGD0s+Y
> f+fW6X/glpu9D437qLJ1LV7X3OtmwchFvjvrtFUvZC1flpgdJs3+rav6VfXvZmS3
> bFx6Ut2aeevA8dZ/LvqkouKNNT2u8aljlz82aUVb79bnB/65enxyy5L9RnmS52DO
> o20r26bOn1t46GDpKPvI3vpb41bMTrd6NY+P1r2WenjRxEsvLqC1czOz5uyaXz0n
> r8f5JRs2bV3ax/dS3chlJ2xf9e5Ma3TnnH63NynXOl2sThzx7pArFXTg7mGD/Pt6
> BtdWPpNXUj6pLP3p67Wh9xP31BypOlc8M6u0TfXmTkuxa298M6E0+Ui/NRWb0xt7
> 7mnKrWPlRWkHShf/+EjOlP8A
> =cNlY
> -----END PGP MESSAGE-----
>
>

From tim.h at bendtel.com  Mon Jul 25 16:31:39 2016
From: tim.h at bendtel.com (Tim Howe)
Date: Mon, 25 Jul 2016 09:31:39 -0700
Subject: students questions
In-Reply-To: <029301d1e68f$34892510$9d9b6f30$@gmail.com>
References: <029301d1e68f$34892510$9d9b6f30$@gmail.com>
Message-ID: <20160725093139.6865e694@cool.bendtel.com>

On Mon, 25 Jul 2016 09:11:29 -0700
"sam" <starwars1070 at gmail.com> wrote:

> [...]
> 1.      Are there any email providers that market to professional but offer
> a student rate or are of good quality but inexpensive etc..
> [...]

	FastMail might fit the bill.  Not free, but pretty inexpensive
with plans start at $10 a year.  High quality, professional, etc...

	https://www.fastmail.com/

--TimH

From bill at herrin.us  Mon Jul 25 16:45:53 2016
From: bill at herrin.us (William Herrin)
Date: Mon, 25 Jul 2016 12:45:53 -0400
Subject: students questions
In-Reply-To: <029301d1e68f$34892510$9d9b6f30$@gmail.com>
References: <029301d1e68f$34892510$9d9b6f30$@gmail.com>
Message-ID: <CAP-guGUzPuFCbmavhviXw6OQ1hZKv1pmgeRW=DQzFDnAXiFFFA@mail.gmail.com>

On Mon, Jul 25, 2016 at 12:11 PM, sam <starwars1070 at gmail.com> wrote:
> Hello if this is not appropriate for this list please excuse me and
> disregard this email.

Hi Sam,

Answering your zeroith question for the sake of others who might have
similar ones: I believe that your question is off topic for the NANOG
list.

https://www.nanog.org/list

Acceptable Use Policy

1. Discussion will focus on Internet operational and technical issues
as described in the charter of NANOG.

https://www.nanog.org/history/charter

1. The North American Network Operators' Group (NANOG) exists to
promote dialog between people concerning the creation, maintenance and
operation of Internet Protocol networks.

Conversation here ranges widely across topics that just barely connect
back (and that's a good thing), but "Who is a good vendor for [super
generic commodity service]?" is a miss even for the normal breadth.

Regards,
Bill Herrin


>I thought of no better place than this place however
> if there is a better place for this email please advise and I will direct
> the email and the student to the questions.
>
> I received an email form a student this morning asking the following
> questions.
> 1.      Are there any email providers that market to professional but offer
> a student rate or are of good quality but inexpensive etc..
>
> 2.      I have looked at the Microsoft exchange server in the cloud while it
> looks promising it does not seems to fit my cost ratio
>
> 3.      I would mainly like to be able to have a professional email address
> so when I apply for jobs and other business of that sort I can be seen as a
> professional and to gather my email from various sources i.e. Gmail, Hotmail
> etc. and to present a more professional appearance to my work and school
> work etc..
>
>
>
> I responded that he should look at google apps, however his questions got me
> thinking and I google around for an answer to give him, however I am not as
> well versed as I should be in the cloud besides for backup service and
> active directory management. I would like to know if you guys have any
> places I own give the student.
>
>
> Thanks
> Samual
> Office of technology education
>
> Please excuse grammar and spelling errors as this was typed on a smartphone.
>
>



-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From nanog-amuse at foofus.com  Mon Jul 25 16:47:08 2016
From: nanog-amuse at foofus.com (amuse)
Date: Mon, 25 Jul 2016 09:47:08 -0700
Subject: students questions
In-Reply-To: <029301d1e68f$34892510$9d9b6f30$@gmail.com>
References: <029301d1e68f$34892510$9d9b6f30$@gmail.com>
Message-ID: <CAH9Hpnxt0r12SykofBuei3idPBm_Nr9XKhrekwJ0kAQfg7RYyg@mail.gmail.com>

You can use Google Domains to register a domain and then use that as your
email within GMail.

https://support.google.com/domains/answer/3251241?hl=en

On Mon, Jul 25, 2016 at 9:11 AM, sam <starwars1070 at gmail.com> wrote:

> Hello if this is not appropriate for this list please excuse me and
> disregard this email. I thought of no better place than this place however
> if there is a better place for this email please advise and I will direct
> the email and the student to the questions.
>
> I received an email form a student this morning asking the following
> questions.
> 1.      Are there any email providers that market to professional but offer
> a student rate or are of good quality but inexpensive etc..
>
> 2.      I have looked at the Microsoft exchange server in the cloud while
> it
> looks promising it does not seems to fit my cost ratio
>
> 3.      I would mainly like to be able to have a professional email address
> so when I apply for jobs and other business of that sort I can be seen as a
> professional and to gather my email from various sources i.e. Gmail,
> Hotmail
> etc. and to present a more professional appearance to my work and school
> work etc..
>
>
>
> I responded that he should look at google apps, however his questions got
> me
> thinking and I google around for an answer to give him, however I am not as
> well versed as I should be in the cloud besides for backup service and
> active directory management. I would like to know if you guys have any
> places I own give the student.
>
>
> Thanks
> Samual
> Office of technology education
>
> Please excuse grammar and spelling errors as this was typed on a
> smartphone.
>
>
>
> -----BEGIN PGP MESSAGE-----
> Version: GnuPG v2
>
> owFdVAtsFEUYbqkQvPQoGgpUHo5FzEHKUcqr2FCoILY8pFCQR1Jlbnf2brndnXVm
> t9fjFSOCFtBUimjBNtJCI5AIFOQhFbSgxAgURQIo8rKIaUTTVBERxH9274rlcpfb
> 2fn/b77/+79/yr1JCV0TScLQ81mX05oSv24JJMxZP+ZGPtE0ilQFWSGVI/ga1ELY
> NBk1mYotghTK3D1N5RYyNYI5QaRUsuFPJwgbMpJVzkgQM9kNJDpWNT8qgBW1gyEL
> UQVQUYBYFmGAgCUCW9hwo911iEZICew6RAgjggnumNJOxMGPM8FyicpdGgUoomoa
> sGFEsgRMLFLsiRW3bJkYsEOd5cs24ZZKDe73egoQ5BC1hMgQHUuD83Tg0J4ljtYp
> M1QjiDAPiz8Bo1AQMCJW9wGR1zPMj5xPHiOxirARjVNntESVCeNCBgvpmIWJQws2
> FMI5YGANBWyhnAL13yfBREdABwx4oGqQUhmOxZpqRZ141SClJjE4VIKIJfmvvlLn
> 9WTFqBSgEIb3GqVhUacr0TRVYpRTxRI9haYEQSfCnFYYToCkUVtGkZCqQVMsJ5sL
> orrKRdHwSqbEtQ0nROeiDgXe6lEkUe5QVikIMrydRYTamgxVq4YWBVeFiUgJgEAB
> zXl0WOKOYsQ6KcsMXiFOgRAxAAucCiDCGgtpgDutpkJuUAPoiViquCpzyixIkKC/
> AVEjpGP+4DGOVSgKYgdDjzdMgXJRCWYqtcXhNpOgYtVP/Og5sZ+B8qnlBArN4yAm
> UBU9w8I15IFzTJNghg3JKRjOiVAWdhK5FKJUc9cCDcyJkPsTJuUmNWQiuyUJT4cc
> MUVXREfBEEEQEeB5RvtMCeO2exNCLDG3Vuizo6rhuNidnXgqozashaKgFDZ4BBCE
> JMJSIVW/Dwvi6+5twVEEbhEEL7kwFoetGC9QuoONAoSD8bkDH8BS2DYdt6mSO8FY
> ssQx7gRTFgWTGDhIdJDR326cuGPCBo2I+yJKbRS0ozzmG5gy574QLGjEcIn/b/z9
> MTVngdnByV5PEdZhguBhuqIIIsIwRAoZVKNBMIBsS8LBRiytsMMFGGRYh/F1O2eC
> CEJPwhiF2cbcvTMi4iFqgjIAAqMM8ZYZogZxmJR16vtQQmLXhC6dO4nrOMHzcPf4
> HX1lZMrtpMXDM+ftvL7Oc7V7y5oF/sNjKk+l7Mr9nQQWdvlW2pmknlp+7vGc5rsZ
> plKfdP3MrDtZ4S8b7/0yUL634+OKtwu9F36aNzmw+c3GwP59Y+f6sof+NWtagnW6
> fvvKaxNHlc2+lH/+yfU/D/lg8Onvvqqvz1g9s7ri2dTK6ak1ZxsSq349M6P12PSj
> Ff7RV7In59+yW58YtfiN6hHW9/4iVsX63t1mp51U01O+aPCkKgPeinqtCbt6k9oP
> UZ8B/RXfp59sKn5q0I4Zrd0KG7VFM7f3qBh7zB52ee+2C1OSD2x5/XgZe/Usa/ot
> reGdjNGh4p2Dt/zQduxE9b8NzX2Ti1bU7Njwnpl2boRP2tP0uS/vwv6LgTGD0s+Y
> f+fW6X/glpu9D437qLJ1LV7X3OtmwchFvjvrtFUvZC1flpgdJs3+rav6VfXvZmS3
> bFx6Ut2aeevA8dZ/LvqkouKNNT2u8aljlz82aUVb79bnB/65enxyy5L9RnmS52DO
> o20r26bOn1t46GDpKPvI3vpb41bMTrd6NY+P1r2WenjRxEsvLqC1czOz5uyaXz0n
> r8f5JRs2bV3ax/dS3chlJ2xf9e5Ma3TnnH63NynXOl2sThzx7pArFXTg7mGD/Pt6
> BtdWPpNXUj6pLP3p67Wh9xP31BypOlc8M6u0TfXmTkuxa298M6E0+Ui/NRWb0xt7
> 7mnKrWPlRWkHShf/+EjOlP8A
> =cNlY
> -----END PGP MESSAGE-----
>
>

From jbaino at gmail.com  Sun Jul 24 16:32:27 2016
From: jbaino at gmail.com (Jeremy)
Date: Sun, 24 Jul 2016 09:32:27 -0700
Subject: Nexus 9k, packet loss through switch on vlan without SVI
Message-ID: <CAJCOWet7FJZF5bnbds0UmPvCfQYPKG8+ZFN1HjOkrK2T8vB2JA@mail.gmail.com>

Running into some weird issues with a Cisco Nexus9k.

We have a Cisco 3750X pair stacked, port channel (2x 1G) to a two different
blades on a Nexus9k. Isolating the links of the port channel , on one link
we can consistently get 800mbps (using iperf), or the other link we
consistently get ~34mbps.

we have seen this across multiple 3750X stacks.

The vlan we were on is just layer2 through the n9k, there are no IP
addresses. We were able to (apparently) resolve this issue by creating an
SVI on the n9k, with an empty config.

Now, even isolating links we can get ~800mbps across the n9k, through the
various 3750X stacks.

I am confused why creating the SVI would have an impact on this, and why it
wouldn't be consistent across both links. If the lack of SVI were at fault,
I would be less surprised if it just flat out didn't work, but this partial
working state feels very odd.

Anyone else seen this? Thoughts? Could traffic be hitting the CPU while
going across modules? This feels like quirky n9k internals...

Thanks!
Jeremy

PS: no CRC errors found on interfaces, all looked clean

From abuse.anmaxx at yahoo.com  Mon Jul 25 10:01:08 2016
From: abuse.anmaxx at yahoo.com (abuse.anmaxx at yahoo.com)
Date: Mon, 25 Jul 2016 10:01:08 +0000 (UTC)
Subject: Google captcha problem on newly rented subnet
References: <1674245727.3305071.1469440868463.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <1674245727.3305071.1469440868463.JavaMail.yahoo@mail.yahoo.com>

We'rehaving some problems with a newly rented /24 subnet in context with Google.Google always asksfor entering a captcha code three times in a row.The reason for thatcan't be a misconfiguration of the server, because we have more than 40different servers all around the world configured exactly the same way where this problem doesn't appear. It could be due to the history of the subnet.
?Can any representativeof Google please contact us via E-Mail, in order to tell him/her which subnetis affected by the problems and solve the issue by removing those permanent queries?

Anders Philip Temsv?g

From robert.stefanovic at gmail.com  Mon Jul 25 16:26:55 2016
From: robert.stefanovic at gmail.com (Robert Stefanovic)
Date: Mon, 25 Jul 2016 12:26:55 -0400
Subject: students questions
In-Reply-To: <029301d1e68f$34892510$9d9b6f30$@gmail.com>
References: <029301d1e68f$34892510$9d9b6f30$@gmail.com>
Message-ID: <CAPta7+gbUQeuuvSzEdTRet=p27awYr2YxMLhmkBvFyCSvsndtQ@mail.gmail.com>

Sure Google apps allows you to have your own domain for around $5/month.

https://apps.google.com/pricing.html

On Jul 25, 2016 12:13 PM, "sam" <starwars1070 at gmail.com> wrote:

> Hello if this is not appropriate for this list please excuse me and
> disregard this email. I thought of no better place than this place however
> if there is a better place for this email please advise and I will direct
> the email and the student to the questions.
>
> I received an email form a student this morning asking the following
> questions.
> 1.      Are there any email providers that market to professional but offer
> a student rate or are of good quality but inexpensive etc..
>
> 2.      I have looked at the Microsoft exchange server in the cloud while
> it
> looks promising it does not seems to fit my cost ratio
>
> 3.      I would mainly like to be able to have a professional email address
> so when I apply for jobs and other business of that sort I can be seen as a
> professional and to gather my email from various sources i.e. Gmail,
> Hotmail
> etc. and to present a more professional appearance to my work and school
> work etc..
>
>
>
> I responded that he should look at google apps, however his questions got
> me
> thinking and I google around for an answer to give him, however I am not as
> well versed as I should be in the cloud besides for backup service and
> active directory management. I would like to know if you guys have any
> places I own give the student.
>
>
> Thanks
> Samual
> Office of technology education
>
> Please excuse grammar and spelling errors as this was typed on a
> smartphone.
>
>
>
> -----BEGIN PGP MESSAGE-----
> Version: GnuPG v2
>
> owFdVAtsFEUYbqkQvPQoGgpUHo5FzEHKUcqr2FCoILY8pFCQR1Jlbnf2brndnXVm
> t9fjFSOCFtBUimjBNtJCI5AIFOQhFbSgxAgURQIo8rKIaUTTVBERxH9274rlcpfb
> 2fn/b77/+79/yr1JCV0TScLQ81mX05oSv24JJMxZP+ZGPtE0ilQFWSGVI/ga1ELY
> NBk1mYotghTK3D1N5RYyNYI5QaRUsuFPJwgbMpJVzkgQM9kNJDpWNT8qgBW1gyEL
> UQVQUYBYFmGAgCUCW9hwo911iEZICew6RAgjggnumNJOxMGPM8FyicpdGgUoomoa
> sGFEsgRMLFLsiRW3bJkYsEOd5cs24ZZKDe73egoQ5BC1hMgQHUuD83Tg0J4ljtYp
> M1QjiDAPiz8Bo1AQMCJW9wGR1zPMj5xPHiOxirARjVNntESVCeNCBgvpmIWJQws2
> FMI5YGANBWyhnAL13yfBREdABwx4oGqQUhmOxZpqRZ141SClJjE4VIKIJfmvvlLn
> 9WTFqBSgEIb3GqVhUacr0TRVYpRTxRI9haYEQSfCnFYYToCkUVtGkZCqQVMsJ5sL
> orrKRdHwSqbEtQ0nROeiDgXe6lEkUe5QVikIMrydRYTamgxVq4YWBVeFiUgJgEAB
> zXl0WOKOYsQ6KcsMXiFOgRAxAAucCiDCGgtpgDutpkJuUAPoiViquCpzyixIkKC/
> AVEjpGP+4DGOVSgKYgdDjzdMgXJRCWYqtcXhNpOgYtVP/Og5sZ+B8qnlBArN4yAm
> UBU9w8I15IFzTJNghg3JKRjOiVAWdhK5FKJUc9cCDcyJkPsTJuUmNWQiuyUJT4cc
> MUVXREfBEEEQEeB5RvtMCeO2exNCLDG3Vuizo6rhuNidnXgqozashaKgFDZ4BBCE
> JMJSIVW/Dwvi6+5twVEEbhEEL7kwFoetGC9QuoONAoSD8bkDH8BS2DYdt6mSO8FY
> ssQx7gRTFgWTGDhIdJDR326cuGPCBo2I+yJKbRS0ozzmG5gy574QLGjEcIn/b/z9
> MTVngdnByV5PEdZhguBhuqIIIsIwRAoZVKNBMIBsS8LBRiytsMMFGGRYh/F1O2eC
> CEJPwhiF2cbcvTMi4iFqgjIAAqMM8ZYZogZxmJR16vtQQmLXhC6dO4nrOMHzcPf4
> HX1lZMrtpMXDM+ftvL7Oc7V7y5oF/sNjKk+l7Mr9nQQWdvlW2pmknlp+7vGc5rsZ
> plKfdP3MrDtZ4S8b7/0yUL634+OKtwu9F36aNzmw+c3GwP59Y+f6sof+NWtagnW6
> fvvKaxNHlc2+lH/+yfU/D/lg8Onvvqqvz1g9s7ri2dTK6ak1ZxsSq349M6P12PSj
> Ff7RV7In59+yW58YtfiN6hHW9/4iVsX63t1mp51U01O+aPCkKgPeinqtCbt6k9oP
> UZ8B/RXfp59sKn5q0I4Zrd0KG7VFM7f3qBh7zB52ee+2C1OSD2x5/XgZe/Usa/ot
> reGdjNGh4p2Dt/zQduxE9b8NzX2Ti1bU7Njwnpl2boRP2tP0uS/vwv6LgTGD0s+Y
> f+fW6X/glpu9D437qLJ1LV7X3OtmwchFvjvrtFUvZC1flpgdJs3+rav6VfXvZmS3
> bFx6Ut2aeevA8dZ/LvqkouKNNT2u8aljlz82aUVb79bnB/65enxyy5L9RnmS52DO
> o20r26bOn1t46GDpKPvI3vpb41bMTrd6NY+P1r2WenjRxEsvLqC1czOz5uyaXz0n
> r8f5JRs2bV3ax/dS3chlJ2xf9e5Ma3TnnH63NynXOl2sThzx7pArFXTg7mGD/Pt6
> BtdWPpNXUj6pLP3p67Wh9xP31BypOlc8M6u0TfXmTkuxa298M6E0+Ui/NRWb0xt7
> 7mnKrWPlRWkHShf/+EjOlP8A
> =cNlY
> -----END PGP MESSAGE-----
>
>

From zvernhout at gmail.com  Mon Jul 25 16:30:39 2016
From: zvernhout at gmail.com (Matthew Vernhout)
Date: Mon, 25 Jul 2016 12:30:39 -0400
Subject: students questions
In-Reply-To: <029301d1e68f$34892510$9d9b6f30$@gmail.com>
References: <029301d1e68f$34892510$9d9b6f30$@gmail.com>
Message-ID: <f6f63b03-8dd0-d751-7901-8f93d5b63f98@gmail.com>

Sam,

Godaddy has $10 domains and offers a small number of free email accounts 
(1-2 address?) hosted on their network... Zoho.com also offers limited 
free hosting of a domain if you already own it, They may sell them too. 
GoogleApps charges now and no longer offers free email hosting unless 
you were grandfathered into it.

That should fit most student budgets.

~ Matt

On 25/07/2016 12:11 PM, sam wrote:
> Hello if this is not appropriate for this list please excuse me and
> disregard this email. I thought of no better place than this place however
> if there is a better place for this email please advise and I will direct
> the email and the student to the questions.
>
> I received an email form a student this morning asking the following
> questions.
> 1.      Are there any email providers that market to professional but offer
> a student rate or are of good quality but inexpensive etc..
>
> 2.      I have looked at the Microsoft exchange server in the cloud while it
> looks promising it does not seems to fit my cost ratio
>
> 3.      I would mainly like to be able to have a professional email address
> so when I apply for jobs and other business of that sort I can be seen as a
> professional and to gather my email from various sources i.e. Gmail, Hotmail
> etc. and to present a more professional appearance to my work and school
> work etc..
>
>    
>    
> I responded that he should look at google apps, however his questions got me
> thinking and I google around for an answer to give him, however I am not as
> well versed as I should be in the cloud besides for backup service and
> active directory management. I would like to know if you guys have any
> places I own give the student.
>
>    
> Thanks
> Samual
> Office of technology education
>    
> Please excuse grammar and spelling errors as this was typed on a smartphone.
>
>    
>
> -----BEGIN PGP MESSAGE-----
> Version: GnuPG v2
>
> owFdVAtsFEUYbqkQvPQoGgpUHo5FzEHKUcqr2FCoILY8pFCQR1Jlbnf2brndnXVm
> t9fjFSOCFtBUimjBNtJCI5AIFOQhFbSgxAgURQIo8rKIaUTTVBERxH9274rlcpfb
> 2fn/b77/+79/yr1JCV0TScLQ81mX05oSv24JJMxZP+ZGPtE0ilQFWSGVI/ga1ELY
> NBk1mYotghTK3D1N5RYyNYI5QaRUsuFPJwgbMpJVzkgQM9kNJDpWNT8qgBW1gyEL
> UQVQUYBYFmGAgCUCW9hwo911iEZICew6RAgjggnumNJOxMGPM8FyicpdGgUoomoa
> sGFEsgRMLFLsiRW3bJkYsEOd5cs24ZZKDe73egoQ5BC1hMgQHUuD83Tg0J4ljtYp
> M1QjiDAPiz8Bo1AQMCJW9wGR1zPMj5xPHiOxirARjVNntESVCeNCBgvpmIWJQws2
> FMI5YGANBWyhnAL13yfBREdABwx4oGqQUhmOxZpqRZ141SClJjE4VIKIJfmvvlLn
> 9WTFqBSgEIb3GqVhUacr0TRVYpRTxRI9haYEQSfCnFYYToCkUVtGkZCqQVMsJ5sL
> orrKRdHwSqbEtQ0nROeiDgXe6lEkUe5QVikIMrydRYTamgxVq4YWBVeFiUgJgEAB
> zXl0WOKOYsQ6KcsMXiFOgRAxAAucCiDCGgtpgDutpkJuUAPoiViquCpzyixIkKC/
> AVEjpGP+4DGOVSgKYgdDjzdMgXJRCWYqtcXhNpOgYtVP/Og5sZ+B8qnlBArN4yAm
> UBU9w8I15IFzTJNghg3JKRjOiVAWdhK5FKJUc9cCDcyJkPsTJuUmNWQiuyUJT4cc
> MUVXREfBEEEQEeB5RvtMCeO2exNCLDG3Vuizo6rhuNidnXgqozashaKgFDZ4BBCE
> JMJSIVW/Dwvi6+5twVEEbhEEL7kwFoetGC9QuoONAoSD8bkDH8BS2DYdt6mSO8FY
> ssQx7gRTFgWTGDhIdJDR326cuGPCBo2I+yJKbRS0ozzmG5gy574QLGjEcIn/b/z9
> MTVngdnByV5PEdZhguBhuqIIIsIwRAoZVKNBMIBsS8LBRiytsMMFGGRYh/F1O2eC
> CEJPwhiF2cbcvTMi4iFqgjIAAqMM8ZYZogZxmJR16vtQQmLXhC6dO4nrOMHzcPf4
> HX1lZMrtpMXDM+ftvL7Oc7V7y5oF/sNjKk+l7Mr9nQQWdvlW2pmknlp+7vGc5rsZ
> plKfdP3MrDtZ4S8b7/0yUL634+OKtwu9F36aNzmw+c3GwP59Y+f6sof+NWtagnW6
> fvvKaxNHlc2+lH/+yfU/D/lg8Onvvqqvz1g9s7ri2dTK6ak1ZxsSq349M6P12PSj
> Ff7RV7In59+yW58YtfiN6hHW9/4iVsX63t1mp51U01O+aPCkKgPeinqtCbt6k9oP
> UZ8B/RXfp59sKn5q0I4Zrd0KG7VFM7f3qBh7zB52ee+2C1OSD2x5/XgZe/Usa/ot
> reGdjNGh4p2Dt/zQduxE9b8NzX2Ti1bU7Njwnpl2boRP2tP0uS/vwv6LgTGD0s+Y
> f+fW6X/glpu9D437qLJ1LV7X3OtmwchFvjvrtFUvZC1flpgdJs3+rav6VfXvZmS3
> bFx6Ut2aeevA8dZ/LvqkouKNNT2u8aljlz82aUVb79bnB/65enxyy5L9RnmS52DO
> o20r26bOn1t46GDpKPvI3vpb41bMTrd6NY+P1r2WenjRxEsvLqC1czOz5uyaXz0n
> r8f5JRs2bV3ax/dS3chlJ2xf9e5Ma3TnnH63NynXOl2sThzx7pArFXTg7mGD/Pt6
> BtdWPpNXUj6pLP3p67Wh9xP31BypOlc8M6u0TfXmTkuxa298M6E0+Ui/NRWb0xt7
> 7mnKrWPlRWkHShf/+EjOlP8A
> =cNlY
> -----END PGP MESSAGE-----
>


From josh at imaginenetworksllc.com  Mon Jul 25 17:11:48 2016
From: josh at imaginenetworksllc.com (Josh Luthman)
Date: Mon, 25 Jul 2016 13:11:48 -0400
Subject: students questions
In-Reply-To: <CAPta7+gbUQeuuvSzEdTRet=p27awYr2YxMLhmkBvFyCSvsndtQ@mail.gmail.com>
References: <029301d1e68f$34892510$9d9b6f30$@gmail.com>
 <CAPta7+gbUQeuuvSzEdTRet=p27awYr2YxMLhmkBvFyCSvsndtQ@mail.gmail.com>
Message-ID: <CAN9qwJ8LMwkQ=Q=h4gX3gbPPMUBu-ogJ-bYqmR_ctqnjbPKGGA@mail.gmail.com>

You're talking about the commercial offering which is $5/user/month.

Google Apps for Education is free -
https://support.google.com/a/answer/139019?hl=en


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Mon, Jul 25, 2016 at 12:26 PM, Robert Stefanovic <
robert.stefanovic at gmail.com> wrote:

> Sure Google apps allows you to have your own domain for around $5/month.
>
> https://apps.google.com/pricing.html
>
> On Jul 25, 2016 12:13 PM, "sam" <starwars1070 at gmail.com> wrote:
>
> > Hello if this is not appropriate for this list please excuse me and
> > disregard this email. I thought of no better place than this place
> however
> > if there is a better place for this email please advise and I will direct
> > the email and the student to the questions.
> >
> > I received an email form a student this morning asking the following
> > questions.
> > 1.      Are there any email providers that market to professional but
> offer
> > a student rate or are of good quality but inexpensive etc..
> >
> > 2.      I have looked at the Microsoft exchange server in the cloud while
> > it
> > looks promising it does not seems to fit my cost ratio
> >
> > 3.      I would mainly like to be able to have a professional email
> address
> > so when I apply for jobs and other business of that sort I can be seen
> as a
> > professional and to gather my email from various sources i.e. Gmail,
> > Hotmail
> > etc. and to present a more professional appearance to my work and school
> > work etc..
> >
> >
> >
> > I responded that he should look at google apps, however his questions got
> > me
> > thinking and I google around for an answer to give him, however I am not
> as
> > well versed as I should be in the cloud besides for backup service and
> > active directory management. I would like to know if you guys have any
> > places I own give the student.
> >
> >
> > Thanks
> > Samual
> > Office of technology education
> >
> > Please excuse grammar and spelling errors as this was typed on a
> > smartphone.
> >
> >
> >
> > -----BEGIN PGP MESSAGE-----
> > Version: GnuPG v2
> >
> > owFdVAtsFEUYbqkQvPQoGgpUHo5FzEHKUcqr2FCoILY8pFCQR1Jlbnf2brndnXVm
> > t9fjFSOCFtBUimjBNtJCI5AIFOQhFbSgxAgURQIo8rKIaUTTVBERxH9274rlcpfb
> > 2fn/b77/+79/yr1JCV0TScLQ81mX05oSv24JJMxZP+ZGPtE0ilQFWSGVI/ga1ELY
> > NBk1mYotghTK3D1N5RYyNYI5QaRUsuFPJwgbMpJVzkgQM9kNJDpWNT8qgBW1gyEL
> > UQVQUYBYFmGAgCUCW9hwo911iEZICew6RAgjggnumNJOxMGPM8FyicpdGgUoomoa
> > sGFEsgRMLFLsiRW3bJkYsEOd5cs24ZZKDe73egoQ5BC1hMgQHUuD83Tg0J4ljtYp
> > M1QjiDAPiz8Bo1AQMCJW9wGR1zPMj5xPHiOxirARjVNntESVCeNCBgvpmIWJQws2
> > FMI5YGANBWyhnAL13yfBREdABwx4oGqQUhmOxZpqRZ141SClJjE4VIKIJfmvvlLn
> > 9WTFqBSgEIb3GqVhUacr0TRVYpRTxRI9haYEQSfCnFYYToCkUVtGkZCqQVMsJ5sL
> > orrKRdHwSqbEtQ0nROeiDgXe6lEkUe5QVikIMrydRYTamgxVq4YWBVeFiUgJgEAB
> > zXl0WOKOYsQ6KcsMXiFOgRAxAAucCiDCGgtpgDutpkJuUAPoiViquCpzyixIkKC/
> > AVEjpGP+4DGOVSgKYgdDjzdMgXJRCWYqtcXhNpOgYtVP/Og5sZ+B8qnlBArN4yAm
> > UBU9w8I15IFzTJNghg3JKRjOiVAWdhK5FKJUc9cCDcyJkPsTJuUmNWQiuyUJT4cc
> > MUVXREfBEEEQEeB5RvtMCeO2exNCLDG3Vuizo6rhuNidnXgqozashaKgFDZ4BBCE
> > JMJSIVW/Dwvi6+5twVEEbhEEL7kwFoetGC9QuoONAoSD8bkDH8BS2DYdt6mSO8FY
> > ssQx7gRTFgWTGDhIdJDR326cuGPCBo2I+yJKbRS0ozzmG5gy574QLGjEcIn/b/z9
> > MTVngdnByV5PEdZhguBhuqIIIsIwRAoZVKNBMIBsS8LBRiytsMMFGGRYh/F1O2eC
> > CEJPwhiF2cbcvTMi4iFqgjIAAqMM8ZYZogZxmJR16vtQQmLXhC6dO4nrOMHzcPf4
> > HX1lZMrtpMXDM+ftvL7Oc7V7y5oF/sNjKk+l7Mr9nQQWdvlW2pmknlp+7vGc5rsZ
> > plKfdP3MrDtZ4S8b7/0yUL634+OKtwu9F36aNzmw+c3GwP59Y+f6sof+NWtagnW6
> > fvvKaxNHlc2+lH/+yfU/D/lg8Onvvqqvz1g9s7ri2dTK6ak1ZxsSq349M6P12PSj
> > Ff7RV7In59+yW58YtfiN6hHW9/4iVsX63t1mp51U01O+aPCkKgPeinqtCbt6k9oP
> > UZ8B/RXfp59sKn5q0I4Zrd0KG7VFM7f3qBh7zB52ee+2C1OSD2x5/XgZe/Usa/ot
> > reGdjNGh4p2Dt/zQduxE9b8NzX2Ti1bU7Njwnpl2boRP2tP0uS/vwv6LgTGD0s+Y
> > f+fW6X/glpu9D437qLJ1LV7X3OtmwchFvjvrtFUvZC1flpgdJs3+rav6VfXvZmS3
> > bFx6Ut2aeevA8dZ/LvqkouKNNT2u8aljlz82aUVb79bnB/65enxyy5L9RnmS52DO
> > o20r26bOn1t46GDpKPvI3vpb41bMTrd6NY+P1r2WenjRxEsvLqC1czOz5uyaXz0n
> > r8f5JRs2bV3ax/dS3chlJ2xf9e5Ma3TnnH63NynXOl2sThzx7pArFXTg7mGD/Pt6
> > BtdWPpNXUj6pLP3p67Wh9xP31BypOlc8M6u0TfXmTkuxa298M6E0+Ui/NRWb0xt7
> > 7mnKrWPlRWkHShf/+EjOlP8A
> > =cNlY
> > -----END PGP MESSAGE-----
> >
> >
>

From hannigan at gmail.com  Mon Jul 25 20:03:10 2016
From: hannigan at gmail.com (Martin Hannigan)
Date: Mon, 25 Jul 2016 16:03:10 -0400
Subject: Akamai IPv6 contact needed
In-Reply-To: <CAFwKRnTNjU23We6xMvU07XPH+RUwRGoxGTryG2Pptq4cd4T1VA@mail.gmail.com>
References: <CAFwKRnTNjU23We6xMvU07XPH+RUwRGoxGTryG2Pptq4cd4T1VA@mail.gmail.com>
Message-ID: <CAMDXq5PMTtELu62PmG49RNb6x33+A-ZMdYfjhRMoxwse02_t-A@mail.gmail.com>

Thanks! We'll reach out to you offline shortly. You can also always
reach us for peering, v6, or AS specific issues at nocc at akamai.com

Best Regards,

Martin Hannigan AS 209040 / AS 32787


On Mon, Jul 25, 2016 at 4:35 AM, Yang Yu <yang.yu.list at gmail.com> wrote:
> Some servers are not serving content over IPv6 HTTPS. It fails in such
> a way that most applications can't fall back to IPv4. tcp/443 is open
> but RST as soon as client sends TLS 1.2 client hello. It has been this
> way for 24+ hours.
>
>>>>
> $ telnet 2600:1404:18::17d7:fbc 443
> Trying 2600:1404:18::17d7:fbc...
> Connected to 2600:1404:18::17d7:fbc.
> Escape character is '^]'.
>
> Connection closed by foreign host
>
>>
> ncat -6 --ssl -v 2600:1404:18::17d7:fac 443
> Ncat: Version 7.00SVN ( https://nmap.org/ncat )
> Ncat: Input/output error.
>
>
>>>>
> www.apple.com.          681     IN      CNAME   www.apple.com.edgekey.net.
> www.apple.com.edgekey.net. 11306 IN     CNAME
> www.apple.com.edgekey.net.globalredir.akadns.net.
> www.apple.com.edgekey.net.globalredir.akadns.net. 1664 IN CNAME
> e6858.dscc.akamaiedge.net.
> e6858.dscc.akamaiedge.net. 5    IN      AAAA    2600:1404:18::17d7:fac
> e6858.dscc.akamaiedge.net. 5    IN      AAAA    2600:1404:18::17d7:fbc
>
>>
> 2600:1404:18::17d7:0/112 serves www.apple.com, download.microsoft.com etc.
>
>
>>>> HTTP does work
> $ wget http://www.apple.com
> --2016-07-25 03:09:17--  http://www.apple.com/
> Resolving www.apple.com (www.apple.com)... 2600:1404:18::17d7:fbc,
> 2600:1404:18::17d7:fac, 23.11.55.206
> Connecting to www.apple.com
> (www.apple.com)|2600:1404:18::17d7:fbc|:80... connected.
> HTTP request sent, awaiting response... 200 OK
>
>>>>
> $ dig whoami.akamai.com +short
> whoami.akamai.net.
> 72.183.81.39
>
>
> Thanks.
>
>
> Yang

From damian at google.com  Mon Jul 25 21:12:55 2016
From: damian at google.com (Damian Menscher)
Date: Mon, 25 Jul 2016 14:12:55 -0700
Subject: Google captcha problem on newly rented subnet
In-Reply-To: <1674245727.3305071.1469440868463.JavaMail.yahoo@mail.yahoo.com>
References: <1674245727.3305071.1469440868463.JavaMail.yahoo.ref@mail.yahoo.com>
 <1674245727.3305071.1469440868463.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <CABSP1Of8BYNkst+ysY5m+dO+Z+x5S+Giu7pBdPk4wv2FdmuK6g@mail.gmail.com>

If you send details off-list I can take a quick look for you.  Using a
hosting provider that ignores abuse complaints is a likely cause, but I'm
curious about the '3 captchas' thing as one should be sufficient.  Please
also explain what you're using the machine for.

Damian

On Mon, Jul 25, 2016 at 3:01 AM, <"Anders Philip Temsv?g via NANOG
<nanog at nanog.org"@mail.nanog.org> wrote:

> We'rehaving some problems with a newly rented /24 subnet in context with
> Google.Google always asksfor entering a captcha code three times in a
> row.The reason for thatcan't be a misconfiguration of the server, because
> we have more than 40different servers all around the world configured
> exactly the same way where this problem doesn't appear. It could be due to
> the history of the subnet.
>  Can any representativeof Google please contact us via E-Mail, in order to
> tell him/her which subnetis affected by the problems and solve the issue by
> removing those permanent queries?
>
> Anders Philip Temsv?g
>

From swm at emanon.com  Tue Jul 26 03:41:14 2016
From: swm at emanon.com (Scott Morris)
Date: Mon, 25 Jul 2016 23:41:14 -0400
Subject: Clueful BGP from TW-Telecom/L3
Message-ID: <3774E17C-980B-43A2-B919-CD304E2FB2BA@emanon.com>

Is there per chance anyone hanging on here who is clueful about BGP working with TW-Telecom and the recent integration with Level3????

 

I have a client that I consult with whose route is not getting sent from TW to L3 and the techs on the case are convinced we need to put different BGP communities in (both to TW link and other provider link) which of course we are putting in to satisfy them, but magically it is not working.? This SHOULD be an easy thing to figure out using the Looking Glass servers within both TW and Level3, but this concept is lost on techs we are dealing with.

 

Anyone internal there who can contact me off-list would be greatly appreciated!

 

Scott

swm at emanon.com


From swm at emanon.com  Tue Jul 26 03:51:32 2016
From: swm at emanon.com (Scott Morris)
Date: Mon, 25 Jul 2016 23:51:32 -0400
Subject: Clueful BGP from TW-Telecom/L3
Message-ID: <FE678EE2-2A57-4DF0-9BBE-FECDAB99C7B6@emanon.com>

Is there per chance anyone hanging on here who is clueful about BGP working with TW-Telecom and the recent integration with Level3????

I have a client that I consult with whose route is not getting sent from TW to L3 and the techs on the case are convinced we need to put different BGP communities in (both to TW link and other provider link) which of course we are putting in to satisfy them, but magically it is not working.? This SHOULD be an easy thing to figure out using the Looking Glass servers within both TW and Level3, but this concept is lost on techs we are dealing with.

Anyone internal there who can contact me off-list would be greatly appreciated!

Scott
swm at emanon.com




From colebusby92 at gmail.com  Mon Jul 25 17:19:16 2016
From: colebusby92 at gmail.com (Cole Busby)
Date: Mon, 25 Jul 2016 10:19:16 -0700
Subject: students questions
In-Reply-To: <f6f63b03-8dd0-d751-7901-8f93d5b63f98@gmail.com>
References: <029301d1e68f$34892510$9d9b6f30$@gmail.com>
 <f6f63b03-8dd0-d751-7901-8f93d5b63f98@gmail.com>
Message-ID: <CAL4opVO7-FDFCQ5YzQj+2ZerfPdCA=u-aoVYJhrxpZV9jk13eg@mail.gmail.com>

Sam & list,

As a student, I found the github student pack a valuable resource. you can
visit it here: https://education.github.com/pack.

Most importantly, it gives your student a free ".me" domain through
namecheap for 1 year and an SSL certificate. They also allow you to play
with your DNS records to setup MX records.

Hope that would help!

- Cole

On Mon, Jul 25, 2016 at 9:30 AM, Matthew Vernhout <zvernhout at gmail.com>
wrote:

> Sam,
>
> Godaddy has $10 domains and offers a small number of free email accounts
> (1-2 address?) hosted on their network... Zoho.com also offers limited free
> hosting of a domain if you already own it, They may sell them too.
> GoogleApps charges now and no longer offers free email hosting unless you
> were grandfathered into it.
>
> That should fit most student budgets.
>
> ~ Matt
>
>
> On 25/07/2016 12:11 PM, sam wrote:
>
>> Hello if this is not appropriate for this list please excuse me and
>> disregard this email. I thought of no better place than this place however
>> if there is a better place for this email please advise and I will direct
>> the email and the student to the questions.
>>
>> I received an email form a student this morning asking the following
>> questions.
>> 1.      Are there any email providers that market to professional but
>> offer
>> a student rate or are of good quality but inexpensive etc..
>>
>> 2.      I have looked at the Microsoft exchange server in the cloud while
>> it
>> looks promising it does not seems to fit my cost ratio
>>
>> 3.      I would mainly like to be able to have a professional email
>> address
>> so when I apply for jobs and other business of that sort I can be seen as
>> a
>> professional and to gather my email from various sources i.e. Gmail,
>> Hotmail
>> etc. and to present a more professional appearance to my work and school
>> work etc..
>>
>>       I responded that he should look at google apps, however his
>> questions got me
>> thinking and I google around for an answer to give him, however I am not
>> as
>> well versed as I should be in the cloud besides for backup service and
>> active directory management. I would like to know if you guys have any
>> places I own give the student.
>>
>>    Thanks
>> Samual
>> Office of technology education
>>    Please excuse grammar and spelling errors as this was typed on a
>> smartphone.
>>
>>
>> -----BEGIN PGP MESSAGE-----
>> Version: GnuPG v2
>>
>> owFdVAtsFEUYbqkQvPQoGgpUHo5FzEHKUcqr2FCoILY8pFCQR1Jlbnf2brndnXVm
>> t9fjFSOCFtBUimjBNtJCI5AIFOQhFbSgxAgURQIo8rKIaUTTVBERxH9274rlcpfb
>> 2fn/b77/+79/yr1JCV0TScLQ81mX05oSv24JJMxZP+ZGPtE0ilQFWSGVI/ga1ELY
>> NBk1mYotghTK3D1N5RYyNYI5QaRUsuFPJwgbMpJVzkgQM9kNJDpWNT8qgBW1gyEL
>> UQVQUYBYFmGAgCUCW9hwo911iEZICew6RAgjggnumNJOxMGPM8FyicpdGgUoomoa
>> sGFEsgRMLFLsiRW3bJkYsEOd5cs24ZZKDe73egoQ5BC1hMgQHUuD83Tg0J4ljtYp
>> M1QjiDAPiz8Bo1AQMCJW9wGR1zPMj5xPHiOxirARjVNntESVCeNCBgvpmIWJQws2
>> FMI5YGANBWyhnAL13yfBREdABwx4oGqQUhmOxZpqRZ141SClJjE4VIKIJfmvvlLn
>> 9WTFqBSgEIb3GqVhUacr0TRVYpRTxRI9haYEQSfCnFYYToCkUVtGkZCqQVMsJ5sL
>> orrKRdHwSqbEtQ0nROeiDgXe6lEkUe5QVikIMrydRYTamgxVq4YWBVeFiUgJgEAB
>> zXl0WOKOYsQ6KcsMXiFOgRAxAAucCiDCGgtpgDutpkJuUAPoiViquCpzyixIkKC/
>> AVEjpGP+4DGOVSgKYgdDjzdMgXJRCWYqtcXhNpOgYtVP/Og5sZ+B8qnlBArN4yAm
>> UBU9w8I15IFzTJNghg3JKRjOiVAWdhK5FKJUc9cCDcyJkPsTJuUmNWQiuyUJT4cc
>> MUVXREfBEEEQEeB5RvtMCeO2exNCLDG3Vuizo6rhuNidnXgqozashaKgFDZ4BBCE
>> JMJSIVW/Dwvi6+5twVEEbhEEL7kwFoetGC9QuoONAoSD8bkDH8BS2DYdt6mSO8FY
>> ssQx7gRTFgWTGDhIdJDR326cuGPCBo2I+yJKbRS0ozzmG5gy574QLGjEcIn/b/z9
>> MTVngdnByV5PEdZhguBhuqIIIsIwRAoZVKNBMIBsS8LBRiytsMMFGGRYh/F1O2eC
>> CEJPwhiF2cbcvTMi4iFqgjIAAqMM8ZYZogZxmJR16vtQQmLXhC6dO4nrOMHzcPf4
>> HX1lZMrtpMXDM+ftvL7Oc7V7y5oF/sNjKk+l7Mr9nQQWdvlW2pmknlp+7vGc5rsZ
>> plKfdP3MrDtZ4S8b7/0yUL634+OKtwu9F36aNzmw+c3GwP59Y+f6sof+NWtagnW6
>> fvvKaxNHlc2+lH/+yfU/D/lg8Onvvqqvz1g9s7ri2dTK6ak1ZxsSq349M6P12PSj
>> Ff7RV7In59+yW58YtfiN6hHW9/4iVsX63t1mp51U01O+aPCkKgPeinqtCbt6k9oP
>> UZ8B/RXfp59sKn5q0I4Zrd0KG7VFM7f3qBh7zB52ee+2C1OSD2x5/XgZe/Usa/ot
>> reGdjNGh4p2Dt/zQduxE9b8NzX2Ti1bU7Njwnpl2boRP2tP0uS/vwv6LgTGD0s+Y
>> f+fW6X/glpu9D437qLJ1LV7X3OtmwchFvjvrtFUvZC1flpgdJs3+rav6VfXvZmS3
>> bFx6Ut2aeevA8dZ/LvqkouKNNT2u8aljlz82aUVb79bnB/65enxyy5L9RnmS52DO
>> o20r26bOn1t46GDpKPvI3vpb41bMTrd6NY+P1r2WenjRxEsvLqC1czOz5uyaXz0n
>> r8f5JRs2bV3ax/dS3chlJ2xf9e5Ma3TnnH63NynXOl2sThzx7pArFXTg7mGD/Pt6
>> BtdWPpNXUj6pLP3p67Wh9xP31BypOlc8M6u0TfXmTkuxa298M6E0+Ui/NRWb0xt7
>> 7mnKrWPlRWkHShf/+EjOlP8A
>> =cNlY
>> -----END PGP MESSAGE-----
>>
>>
>

From micahcroff at gmail.com  Tue Jul 26 22:21:20 2016
From: micahcroff at gmail.com (Micah Croff)
Date: Tue, 26 Jul 2016 15:21:20 -0700
Subject: Clueful BGP from TW-Telecom/L3
In-Reply-To: <FE678EE2-2A57-4DF0-9BBE-FECDAB99C7B6@emanon.com>
References: <FE678EE2-2A57-4DF0-9BBE-FECDAB99C7B6@emanon.com>
Message-ID: <CADy9NBDoBanQMpxGJo3qSRBdVxHMkMygjmsxSWg9pLQZKjUpcg@mail.gmail.com>

Last I dealt with TW Telecom and BGP we had to explain to them that putting
in a static route on both routers on top of BGP was not desired.  Then they
reconfigured a circuit 30 miles away when trying to turn it up again
causing an outage in our data center.

Sorry, not super hopeful when it comes to TW Telecom.

Micah

On Mon, Jul 25, 2016 at 8:51 PM, Scott Morris <swm at emanon.com> wrote:

> Is there per chance anyone hanging on here who is clueful about BGP
> working with TW-Telecom and the recent integration with Level3????
>
> I have a client that I consult with whose route is not getting sent from
> TW to L3 and the techs on the case are convinced we need to put different
> BGP communities in (both to TW link and other provider link) which of
> course we are putting in to satisfy them, but magically it is not working.
> This SHOULD be an easy thing to figure out using the Looking Glass servers
> within both TW and Level3, but this concept is lost on techs we are dealing
> with.
>
> Anyone internal there who can contact me off-list would be greatly
> appreciated!
>
> Scott
> swm at emanon.com
>
>
>
>

From jg at freedesktop.org  Wed Jul 27 00:26:04 2016
From: jg at freedesktop.org (Jim Gettys)
Date: Tue, 26 Jul 2016 20:26:04 -0400
Subject: I recommend dslreports.com/speedtest these days (was
 Speedtest.net not accessible in Chrome due to deceptive ads)
In-Reply-To: <CAGhGL2A-ystx24apm-fM6YuJLER4dye=G8dg4j=WLNR43WtO2w@mail.gmail.com>
References: <CAA6dEZNy64iWvJcdkEzmMOoaC81EwGH6F4FQOejhkM=DQWeYQw@mail.gmail.com>
 <994213489.26076.1469135945049.JavaMail.zimbra@baylink.com>
 <113466DC-5310-4A75-A2C4-C4D7CC8AE4C5@f5.com>
 <414BCE73-08E8-4D0B-9056-C629CA8F2C03@truenet.com>
 <CAGhGL2Bm1WuCWVZzqxhBS7jWFn1ws_x=Wz2sZoEf1Kd9+9pH7A@mail.gmail.com>
 <CAPkb-7CeQLZsfVhnLjHGCZ+eyV0=1nGcY1NdCqZxokSaoioxaA@mail.gmail.com>
 <CAGhGL2A-ystx24apm-fM6YuJLER4dye=G8dg4j=WLNR43WtO2w@mail.gmail.com>
Message-ID: <CAGhGL2Daii_gMCn_SOUiq=rjF5=-En7T1x97ckm1KMt6ooyO_g@mail.gmail.com>

Some additional comments from Dave Taht, who does not subscribe to the
nanog list.  Also note the early WiFi results, which are spectacular.  Your
customers will have bufferbloat both due to the ISP, and due to the WiFi
hop that is usually between them and their home router.  Unfortunately,
it's going to take years for the WiFi fixes to percolate through the
ecosystem, which is very dysfunctional (it's taken about 4 years to see
Docsis 3.1 modems, which are only now appearing).
                                                        - Jim

If you would like to see a plot of all the millions of samples
dslreports collected to date on the endemic bufferbloat along the edge
of the internet, as well as breakdowns by ISPs, see:

uploads: http://www.dslreports.com/speedtest/results/bufferbloat?up=1

downloads: http://www.dslreports.com/speedtest/results/bufferbloat

And look at the sea of stuff with latencies measured in the hundreds of
ms...
and get up off your ass and do something about it on your networks.

It's easy now.

The algorithms we've developed to fix it (fq_codel, pie) are in bsd,
and linux now; the ietf drafts are complete. These algorithms can move
induced latencies to well below 30ms in most cases, on ethernet, dsl,
cable, and fiber. fq_codel has been out there since 2012. A goodly
percentage of linux distros now defaults to fq_codel, but doing up the
chokepoints right involves replacing old shapers and policers with
these algorithms, additionally. See the "sqm-scripts" for how.

... side note ...


Fixing wifi with similar stuff has proven *very* difficult, but we've
made quite a bit of progress lately in the ath10k and ath9k chipsets,
that is not quite ready for prime time: pretty exciting summary, here:

https://blog.tohojo.dk/2016/06/fixing-the-wifi-performance-anomaly-on-ath9k.html



On Fri, Jul 22, 2016 at 4:31 PM, Jim Gettys <jg at freedesktop.org> wrote:

>
>
> On Fri, Jul 22, 2016 at 4:18 PM, Baldur Norddahl <
> baldur.norddahl at gmail.com> wrote:
>
>> Den 22. jul. 2016 21.34 skrev "Jim Gettys" <jg at freedesktop.org>:
>> >
>> >
>> > So it is entirely appropriate in my view to give even "high speed"
>> > connections low grades; it's telling you that they suck under load
>> > ?, like when your kid is downloading a video (or uploading one for their
>> > friends); your performance (e.g. web surfing) can go to hell in a
>> > hand-basket despite having a lot of bandwidth on the
>> > connection. For most use, I'll take a 20Mbps link without bloat to a
>> > 200Mbps one with a half second of bloat any
>> > ? ?
>> > day.
>> > ?
>>
>> I will expect that high speed links will have little bloat simply because
>> even large buffers empty quite fast.
>>
>
> ?Unfortunately, that is often/usually not the case.?
>
> ?  The buffering has typically scaled up as fast/faster than the bandwidth
> has, in my observation. You can have as much/more bloat on a higher
> bandwidth line as a low bandwidth line.
>
> That's why I always refer to buffering in seconds?, not bytes, unless I'm
> trying to understand how the identical equipment will behave at differing
> bandwidths.
>
> The worst is usually someone taking modern equipment and then running it
> at low speed: e.g. a gigabit switch being used at 100Mbps will generally be
> 10x worse than the old equipment it replaces (at best).
>
>                      - Jim
>
>

From mike-nanog at tiedyenetworks.com  Wed Jul 27 01:49:58 2016
From: mike-nanog at tiedyenetworks.com (Mike)
Date: Tue, 26 Jul 2016 18:49:58 -0700
Subject: cloudflare hosting a ddos service?
Message-ID: <57981346.9090403@tiedyenetworks.com>

Hi,

     So vbooter.org's dns and web is hosted by cloudflare?

"Using vBooter you can take down home internet connections, websites and 
game servers such us Minecraft, XBOX Live, PSN and many more."

     dig -t ns vbooter.org

; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t ns vbooter.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62177
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;vbooter.org.            IN    NS

;; ANSWER SECTION:
vbooter.org.        21599    IN    NS    rick.ns.cloudflare.com.
vbooter.org.        21599    IN    NS    amy.ns.cloudflare.com.

  dig -t a www.vbooter.org

; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t a www.vbooter.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34920
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.vbooter.org.        IN    A

;; ANSWER SECTION:
www.vbooter.org.    299    IN    CNAME    vbooter.org.
vbooter.org.        299    IN    A    104.28.13.7
vbooter.org.        299    IN    A    104.28.12.7


     Can anyone from cloudflare answer me why this fits with your 
business model?

Mike-


From patrick at ianai.net  Wed Jul 27 01:55:39 2016
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Tue, 26 Jul 2016 21:55:39 -0400
Subject: cloudflare hosting a ddos service?
In-Reply-To: <57981346.9090403@tiedyenetworks.com>
References: <57981346.9090403@tiedyenetworks.com>
Message-ID: <51419800-274B-4B6E-874A-13B48E5FAC85@ianai.net>

CloudFlare will claim they are not hosting the problem. They are just hosting the web page that lets you pay for or points at or otherwise directs you to the problem.

The actual source of packets is some other IP address. Therefore, they can keep hosting the web page. It is not sending the actual [spam|DDoS|hack|etc.], right? So stop asking them to do something about it!

Whether you think that is the proper way to provide service on the Internet is left as an exercise to the reader.

-- 
TTFN,
patrick

> On Jul 26, 2016, at 9:49 PM, Mike <mike-nanog at tiedyenetworks.com> wrote:
> 
> Hi,
> 
>    So vbooter.org's dns and web is hosted by cloudflare?
> 
> "Using vBooter you can take down home internet connections, websites and game servers such us Minecraft, XBOX Live, PSN and many more."
> 
>    dig -t ns vbooter.org
> 
> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t ns vbooter.org
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62177
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;vbooter.org.            IN    NS
> 
> ;; ANSWER SECTION:
> vbooter.org.        21599    IN    NS    rick.ns.cloudflare.com.
> vbooter.org.        21599    IN    NS    amy.ns.cloudflare.com.
> 
> dig -t a www.vbooter.org
> 
> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t a www.vbooter.org
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34920
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;www.vbooter.org.        IN    A
> 
> ;; ANSWER SECTION:
> www.vbooter.org.    299    IN    CNAME    vbooter.org.
> vbooter.org.        299    IN    A    104.28.13.7
> vbooter.org.        299    IN    A    104.28.12.7
> 
> 
>    Can anyone from cloudflare answer me why this fits with your business model?
> 
> Mike-


From deleskie at gmail.com  Wed Jul 27 02:14:50 2016
From: deleskie at gmail.com (jim deleskie)
Date: Tue, 26 Jul 2016 23:14:50 -0300
Subject: cloudflare hosting a ddos service?
In-Reply-To: <51419800-274B-4B6E-874A-13B48E5FAC85@ianai.net>
References: <57981346.9090403@tiedyenetworks.com>
 <51419800-274B-4B6E-874A-13B48E5FAC85@ianai.net>
Message-ID: <CAJL_ZMMkwSfJTEwOzJ0OFLQ0GouEN2c2UxMfgUyJDxJMABCe+w@mail.gmail.com>

sigh...

On Tue, Jul 26, 2016 at 10:55 PM, Patrick W. Gilmore <patrick at ianai.net>
wrote:

> CloudFlare will claim they are not hosting the problem. They are just
> hosting the web page that lets you pay for or points at or otherwise
> directs you to the problem.
>
> The actual source of packets is some other IP address. Therefore, they can
> keep hosting the web page. It is not sending the actual
> [spam|DDoS|hack|etc.], right? So stop asking them to do something about it!
>
> Whether you think that is the proper way to provide service on the
> Internet is left as an exercise to the reader.
>
> --
> TTFN,
> patrick
>
> > On Jul 26, 2016, at 9:49 PM, Mike <mike-nanog at tiedyenetworks.com> wrote:
> >
> > Hi,
> >
> >    So vbooter.org's dns and web is hosted by cloudflare?
> >
> > "Using vBooter you can take down home internet connections, websites and
> game servers such us Minecraft, XBOX Live, PSN and many more."
> >
> >    dig -t ns vbooter.org
> >
> > ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t ns vbooter.org
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62177
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 512
> > ;; QUESTION SECTION:
> > ;vbooter.org.            IN    NS
> >
> > ;; ANSWER SECTION:
> > vbooter.org.        21599    IN    NS    rick.ns.cloudflare.com.
> > vbooter.org.        21599    IN    NS    amy.ns.cloudflare.com.
> >
> > dig -t a www.vbooter.org
> >
> > ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t a www.vbooter.org
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34920
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 512
> > ;; QUESTION SECTION:
> > ;www.vbooter.org.        IN    A
> >
> > ;; ANSWER SECTION:
> > www.vbooter.org.    299    IN    CNAME    vbooter.org.
> > vbooter.org.        299    IN    A    104.28.13.7
> > vbooter.org.        299    IN    A    104.28.12.7
> >
> >
> >    Can anyone from cloudflare answer me why this fits with your business
> model?
> >
> > Mike-
>
>

From mehmet at akcin.net  Wed Jul 27 02:15:09 2016
From: mehmet at akcin.net (Mehmet Akcin)
Date: Tue, 26 Jul 2016 19:15:09 -0700
Subject: cloudflare hosting a ddos service?
In-Reply-To: <57981346.9090403@tiedyenetworks.com>
References: <57981346.9090403@tiedyenetworks.com>
Message-ID: <CA+LTh5X-Fv0GWGzK5Uhri7zEATLXMOfP5yaWf97xhUH2LFCEwg@mail.gmail.com>

Have you tried to contact their Abuse?.

mehmet

On Tue, Jul 26, 2016 at 6:49 PM, Mike <mike-nanog at tiedyenetworks.com> wrote:

> Hi,
>
>     So vbooter.org's dns and web is hosted by cloudflare?
>
> "Using vBooter you can take down home internet connections, websites and
> game servers such us Minecraft, XBOX Live, PSN and many more."
>
>     dig -t ns vbooter.org
>
> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t ns vbooter.org
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62177
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;vbooter.org.            IN    NS
>
> ;; ANSWER SECTION:
> vbooter.org.        21599    IN    NS    rick.ns.cloudflare.com.
> vbooter.org.        21599    IN    NS    amy.ns.cloudflare.com.
>
>  dig -t a www.vbooter.org
>
> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t a www.vbooter.org
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34920
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;www.vbooter.org.        IN    A
>
> ;; ANSWER SECTION:
> www.vbooter.org.    299    IN    CNAME    vbooter.org.
> vbooter.org.        299    IN    A    104.28.13.7
> vbooter.org.        299    IN    A    104.28.12.7
>
>
>     Can anyone from cloudflare answer me why this fits with your business
> model?
>
> Mike-
>
>

From pr at isprime.com  Wed Jul 27 02:17:53 2016
From: pr at isprime.com (Phil Rosenthal)
Date: Tue, 26 Jul 2016 22:17:53 -0400
Subject: cloudflare hosting a ddos service?
In-Reply-To: <CAJL_ZMMkwSfJTEwOzJ0OFLQ0GouEN2c2UxMfgUyJDxJMABCe+w@mail.gmail.com>
References: <57981346.9090403@tiedyenetworks.com>
 <51419800-274B-4B6E-874A-13B48E5FAC85@ianai.net>
 <CAJL_ZMMkwSfJTEwOzJ0OFLQ0GouEN2c2UxMfgUyJDxJMABCe+w@mail.gmail.com>
Message-ID: <6A7C9E2E-9D39-4D14-8671-FB13BA33F39B@isprime.com>

Plus, it?s good for business!

-Phil

> On Jul 26, 2016, at 10:14 PM, jim deleskie <deleskie at gmail.com> wrote:
> 
> sigh...
> 
> On Tue, Jul 26, 2016 at 10:55 PM, Patrick W. Gilmore <patrick at ianai.net>
> wrote:
> 
>> CloudFlare will claim they are not hosting the problem. They are just
>> hosting the web page that lets you pay for or points at or otherwise
>> directs you to the problem.
>> 
>> The actual source of packets is some other IP address. Therefore, they can
>> keep hosting the web page. It is not sending the actual
>> [spam|DDoS|hack|etc.], right? So stop asking them to do something about it!
>> 
>> Whether you think that is the proper way to provide service on the
>> Internet is left as an exercise to the reader.
>> 
>> --
>> TTFN,
>> patrick
>> 
>>> On Jul 26, 2016, at 9:49 PM, Mike <mike-nanog at tiedyenetworks.com> wrote:
>>> 
>>> Hi,
>>> 
>>>   So vbooter.org's dns and web is hosted by cloudflare?
>>> 
>>> "Using vBooter you can take down home internet connections, websites and
>> game servers such us Minecraft, XBOX Live, PSN and many more."
>>> 
>>>   dig -t ns vbooter.org
>>> 
>>> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t ns vbooter.org
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62177
>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>>> 
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 512
>>> ;; QUESTION SECTION:
>>> ;vbooter.org.            IN    NS
>>> 
>>> ;; ANSWER SECTION:
>>> vbooter.org.        21599    IN    NS    rick.ns.cloudflare.com.
>>> vbooter.org.        21599    IN    NS    amy.ns.cloudflare.com.
>>> 
>>> dig -t a www.vbooter.org
>>> 
>>> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t a www.vbooter.org
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34920
>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
>>> 
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 512
>>> ;; QUESTION SECTION:
>>> ;www.vbooter.org.        IN    A
>>> 
>>> ;; ANSWER SECTION:
>>> www.vbooter.org.    299    IN    CNAME    vbooter.org.
>>> vbooter.org.        299    IN    A    104.28.13.7
>>> vbooter.org.        299    IN    A    104.28.12.7
>>> 
>>> 
>>>   Can anyone from cloudflare answer me why this fits with your business
>> model?
>>> 
>>> Mike-
>> 
>> 


From deleskie at gmail.com  Wed Jul 27 02:19:37 2016
From: deleskie at gmail.com (jim deleskie)
Date: Tue, 26 Jul 2016 23:19:37 -0300
Subject: cloudflare hosting a ddos service?
In-Reply-To: <6A7C9E2E-9D39-4D14-8671-FB13BA33F39B@isprime.com>
References: <57981346.9090403@tiedyenetworks.com>
 <51419800-274B-4B6E-874A-13B48E5FAC85@ianai.net>
 <CAJL_ZMMkwSfJTEwOzJ0OFLQ0GouEN2c2UxMfgUyJDxJMABCe+w@mail.gmail.com>
 <6A7C9E2E-9D39-4D14-8671-FB13BA33F39B@isprime.com>
Message-ID: <CAJL_ZMNLDvOnCMguC9ExU4ruX1mjaxZQ3eNL60mTW38VoqHRgw@mail.gmail.com>

Back in the day didn't we refer to such hosting as bulletproof hosting?

On Tue, Jul 26, 2016 at 11:17 PM, Phil Rosenthal <pr at isprime.com> wrote:

> Plus, it?s good for business!
>
> -Phil
>
> > On Jul 26, 2016, at 10:14 PM, jim deleskie <deleskie at gmail.com> wrote:
> >
> > sigh...
> >
> > On Tue, Jul 26, 2016 at 10:55 PM, Patrick W. Gilmore <patrick at ianai.net>
> > wrote:
> >
> >> CloudFlare will claim they are not hosting the problem. They are just
> >> hosting the web page that lets you pay for or points at or otherwise
> >> directs you to the problem.
> >>
> >> The actual source of packets is some other IP address. Therefore, they
> can
> >> keep hosting the web page. It is not sending the actual
> >> [spam|DDoS|hack|etc.], right? So stop asking them to do something about
> it!
> >>
> >> Whether you think that is the proper way to provide service on the
> >> Internet is left as an exercise to the reader.
> >>
> >> --
> >> TTFN,
> >> patrick
> >>
> >>> On Jul 26, 2016, at 9:49 PM, Mike <mike-nanog at tiedyenetworks.com>
> wrote:
> >>>
> >>> Hi,
> >>>
> >>>   So vbooter.org's dns and web is hosted by cloudflare?
> >>>
> >>> "Using vBooter you can take down home internet connections, websites
> and
> >> game servers such us Minecraft, XBOX Live, PSN and many more."
> >>>
> >>>   dig -t ns vbooter.org
> >>>
> >>> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t ns vbooter.org
> >>> ;; global options: +cmd
> >>> ;; Got answer:
> >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62177
> >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
> >>>
> >>> ;; OPT PSEUDOSECTION:
> >>> ; EDNS: version: 0, flags:; udp: 512
> >>> ;; QUESTION SECTION:
> >>> ;vbooter.org.            IN    NS
> >>>
> >>> ;; ANSWER SECTION:
> >>> vbooter.org.        21599    IN    NS    rick.ns.cloudflare.com.
> >>> vbooter.org.        21599    IN    NS    amy.ns.cloudflare.com.
> >>>
> >>> dig -t a www.vbooter.org
> >>>
> >>> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t a www.vbooter.org
> >>> ;; global options: +cmd
> >>> ;; Got answer:
> >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34920
> >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
> >>>
> >>> ;; OPT PSEUDOSECTION:
> >>> ; EDNS: version: 0, flags:; udp: 512
> >>> ;; QUESTION SECTION:
> >>> ;www.vbooter.org.        IN    A
> >>>
> >>> ;; ANSWER SECTION:
> >>> www.vbooter.org.    299    IN    CNAME    vbooter.org.
> >>> vbooter.org.        299    IN    A    104.28.13.7
> >>> vbooter.org.        299    IN    A    104.28.12.7
> >>>
> >>>
> >>>   Can anyone from cloudflare answer me why this fits with your business
> >> model?
> >>>
> >>> Mike-
> >>
> >>
>
>

From dovid at telecurve.com  Wed Jul 27 02:24:37 2016
From: dovid at telecurve.com (Dovid Bender)
Date: Wed, 27 Jul 2016 02:24:37 +0000
Subject: cloudflare hosting a ddos service?
In-Reply-To: <6A7C9E2E-9D39-4D14-8671-FB13BA33F39B@isprime.com>
References: <57981346.9090403@tiedyenetworks.com>
 <51419800-274B-4B6E-874A-13B48E5FAC85@ianai.net>
 <CAJL_ZMMkwSfJTEwOzJ0OFLQ0GouEN2c2UxMfgUyJDxJMABCe+w@mail.gmail.com>
 <6A7C9E2E-9D39-4D14-8671-FB13BA33F39B@isprime.com>
Message-ID: <950531107-1469586277-cardhu_decombobulator_blackberry.rim.net-1930209990-@b16.c1.bise6.blackberry>

I used to have a boss that was convinced that MCafee was writing viruses to stay in business....
 
Regards,

Dovid

-----Original Message-----
From: Phil Rosenthal <pr at isprime.com>
Sender: "NANOG" <nanog-bounces at nanog.org>Date: Tue, 26 Jul 2016 22:17:53 
To: jim deleskie<deleskie at gmail.com>
Cc: NANOG list<nanog at nanog.org>
Subject: Re: cloudflare hosting a ddos service?

Plus, it?s good for business!

-Phil

> On Jul 26, 2016, at 10:14 PM, jim deleskie <deleskie at gmail.com> wrote:
> 
> sigh...
> 
> On Tue, Jul 26, 2016 at 10:55 PM, Patrick W. Gilmore <patrick at ianai.net>
> wrote:
> 
>> CloudFlare will claim they are not hosting the problem. They are just
>> hosting the web page that lets you pay for or points at or otherwise
>> directs you to the problem.
>> 
>> The actual source of packets is some other IP address. Therefore, they can
>> keep hosting the web page. It is not sending the actual
>> [spam|DDoS|hack|etc.], right? So stop asking them to do something about it!
>> 
>> Whether you think that is the proper way to provide service on the
>> Internet is left as an exercise to the reader.
>> 
>> --
>> TTFN,
>> patrick
>> 
>>> On Jul 26, 2016, at 9:49 PM, Mike <mike-nanog at tiedyenetworks.com> wrote:
>>> 
>>> Hi,
>>> 
>>>   So vbooter.org's dns and web is hosted by cloudflare?
>>> 
>>> "Using vBooter you can take down home internet connections, websites and
>> game servers such us Minecraft, XBOX Live, PSN and many more."
>>> 
>>>   dig -t ns vbooter.org
>>> 
>>> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t ns vbooter.org
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62177
>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>>> 
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 512
>>> ;; QUESTION SECTION:
>>> ;vbooter.org.            IN    NS
>>> 
>>> ;; ANSWER SECTION:
>>> vbooter.org.        21599    IN    NS    rick.ns.cloudflare.com.
>>> vbooter.org.        21599    IN    NS    amy.ns.cloudflare.com.
>>> 
>>> dig -t a www.vbooter.org
>>> 
>>> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t a www.vbooter.org
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34920
>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
>>> 
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 512
>>> ;; QUESTION SECTION:
>>> ;www.vbooter.org.        IN    A
>>> 
>>> ;; ANSWER SECTION:
>>> www.vbooter.org.    299    IN    CNAME    vbooter.org.
>>> vbooter.org.        299    IN    A    104.28.13.7
>>> vbooter.org.        299    IN    A    104.28.12.7
>>> 
>>> 
>>>   Can anyone from cloudflare answer me why this fits with your business
>> model?
>>> 
>>> Mike-
>> 
>> 


From paras at protrafsolutions.com  Wed Jul 27 02:33:09 2016
From: paras at protrafsolutions.com (Paras Jha)
Date: Tue, 26 Jul 2016 22:33:09 -0400
Subject: cloudflare hosting a ddos service?
In-Reply-To: <950531107-1469586277-cardhu_decombobulator_blackberry.rim.net-1930209990-@b16.c1.bise6.blackberry>
References: <57981346.9090403@tiedyenetworks.com>
 <51419800-274B-4B6E-874A-13B48E5FAC85@ianai.net>
 <CAJL_ZMMkwSfJTEwOzJ0OFLQ0GouEN2c2UxMfgUyJDxJMABCe+w@mail.gmail.com>
 <6A7C9E2E-9D39-4D14-8671-FB13BA33F39B@isprime.com>
 <950531107-1469586277-cardhu_decombobulator_blackberry.rim.net-1930209990-@b16.c1.bise6.blackberry>
Message-ID: <CAJayEpFwpUrmRKCsw2uVb78QvF65-=FQ6ZC0G76g9JgaZvjZ6A@mail.gmail.com>

This is quite common, almost all of the DDoS-for-hire services are hosted
behind CloudFlare, and a great majority of them take PayPal. Another one
had even managed to secure an EV SSL cert.

On Tue, Jul 26, 2016 at 10:24 PM, Dovid Bender <dovid at telecurve.com> wrote:

> I used to have a boss that was convinced that MCafee was writing viruses
> to stay in business....
>
> Regards,
>
> Dovid
>
> -----Original Message-----
> From: Phil Rosenthal <pr at isprime.com>
> Sender: "NANOG" <nanog-bounces at nanog.org>Date: Tue, 26 Jul 2016 22:17:53
> To: jim deleskie<deleskie at gmail.com>
> Cc: NANOG list<nanog at nanog.org>
> Subject: Re: cloudflare hosting a ddos service?
>
> Plus, it?s good for business!
>
> -Phil
>
> > On Jul 26, 2016, at 10:14 PM, jim deleskie <deleskie at gmail.com> wrote:
> >
> > sigh...
> >
> > On Tue, Jul 26, 2016 at 10:55 PM, Patrick W. Gilmore <patrick at ianai.net>
> > wrote:
> >
> >> CloudFlare will claim they are not hosting the problem. They are just
> >> hosting the web page that lets you pay for or points at or otherwise
> >> directs you to the problem.
> >>
> >> The actual source of packets is some other IP address. Therefore, they
> can
> >> keep hosting the web page. It is not sending the actual
> >> [spam|DDoS|hack|etc.], right? So stop asking them to do something about
> it!
> >>
> >> Whether you think that is the proper way to provide service on the
> >> Internet is left as an exercise to the reader.
> >>
> >> --
> >> TTFN,
> >> patrick
> >>
> >>> On Jul 26, 2016, at 9:49 PM, Mike <mike-nanog at tiedyenetworks.com>
> wrote:
> >>>
> >>> Hi,
> >>>
> >>>   So vbooter.org's dns and web is hosted by cloudflare?
> >>>
> >>> "Using vBooter you can take down home internet connections, websites
> and
> >> game servers such us Minecraft, XBOX Live, PSN and many more."
> >>>
> >>>   dig -t ns vbooter.org
> >>>
> >>> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t ns vbooter.org
> >>> ;; global options: +cmd
> >>> ;; Got answer:
> >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62177
> >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
> >>>
> >>> ;; OPT PSEUDOSECTION:
> >>> ; EDNS: version: 0, flags:; udp: 512
> >>> ;; QUESTION SECTION:
> >>> ;vbooter.org.            IN    NS
> >>>
> >>> ;; ANSWER SECTION:
> >>> vbooter.org.        21599    IN    NS    rick.ns.cloudflare.com.
> >>> vbooter.org.        21599    IN    NS    amy.ns.cloudflare.com.
> >>>
> >>> dig -t a www.vbooter.org
> >>>
> >>> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t a www.vbooter.org
> >>> ;; global options: +cmd
> >>> ;; Got answer:
> >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34920
> >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
> >>>
> >>> ;; OPT PSEUDOSECTION:
> >>> ; EDNS: version: 0, flags:; udp: 512
> >>> ;; QUESTION SECTION:
> >>> ;www.vbooter.org.        IN    A
> >>>
> >>> ;; ANSWER SECTION:
> >>> www.vbooter.org.    299    IN    CNAME    vbooter.org.
> >>> vbooter.org.        299    IN    A    104.28.13.7
> >>> vbooter.org.        299    IN    A    104.28.12.7
> >>>
> >>>
> >>>   Can anyone from cloudflare answer me why this fits with your business
> >> model?
> >>>
> >>> Mike-
> >>
> >>
>
>


-- 
Regards,
Paras

President
ProTraf Solutions, LLC
Enterprise DDoS Mitigation

From telmnstr at 757.org  Wed Jul 27 02:34:25 2016
From: telmnstr at 757.org (Ethan)
Date: Tue, 26 Jul 2016 22:34:25 -0400 (EDT)
Subject: cloudflare hosting a ddos service?
In-Reply-To: <57981346.9090403@tiedyenetworks.com>
References: <57981346.9090403@tiedyenetworks.com>
Message-ID: <Pine.LNX.4.64.1607262233240.753@users.757.org>

>    So vbooter.org's dns and web is hosted by cloudflare?
> "Using vBooter you can take down home internet connections, websites and game 
> servers such us Minecraft, XBOX Live, PSN and many more."

Buy some time on it to DDoS cloudflare sites.


From steve at blighty.com  Wed Jul 27 02:35:59 2016
From: steve at blighty.com (Steve Atkins)
Date: Tue, 26 Jul 2016 19:35:59 -0700
Subject: cloudflare hosting a ddos service?
In-Reply-To: <CA+LTh5X-Fv0GWGzK5Uhri7zEATLXMOfP5yaWf97xhUH2LFCEwg@mail.gmail.com>
References: <57981346.9090403@tiedyenetworks.com>
 <CA+LTh5X-Fv0GWGzK5Uhri7zEATLXMOfP5yaWf97xhUH2LFCEwg@mail.gmail.com>
Message-ID: <388A5776-1E6E-4F3D-B8DE-701F8DD24290@blighty.com>


> On Jul 26, 2016, at 7:15 PM, Mehmet Akcin <mehmet at akcin.net> wrote:
> 
> Have you tried to contact their Abuse?.

For a long time their abuse@ alias was (literally) routed to /dev/null. I'm not
sure whether that's still the case or whether they now ignore reports manually.

Cheers,
  Steve

> 
> mehmet
> 
> On Tue, Jul 26, 2016 at 6:49 PM, Mike <mike-nanog at tiedyenetworks.com> wrote:
> 
>> Hi,
>> 
>>    So vbooter.org's dns and web is hosted by cloudflare?
>> 
>> "Using vBooter you can take down home internet connections, websites and
>> game servers such us Minecraft, XBOX Live, PSN and many more."
>> 
>>    dig -t ns vbooter.org
>> 
>> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t ns vbooter.org
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62177
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>> 
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 512
>> ;; QUESTION SECTION:
>> ;vbooter.org.            IN    NS
>> 
>> ;; ANSWER SECTION:
>> vbooter.org.        21599    IN    NS    rick.ns.cloudflare.com.
>> vbooter.org.        21599    IN    NS    amy.ns.cloudflare.com.
>> 
>> dig -t a www.vbooter.org
>> 
>> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t a www.vbooter.org
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34920
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
>> 
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 512
>> ;; QUESTION SECTION:
>> ;www.vbooter.org.        IN    A
>> 
>> ;; ANSWER SECTION:
>> www.vbooter.org.    299    IN    CNAME    vbooter.org.
>> vbooter.org.        299    IN    A    104.28.13.7
>> vbooter.org.        299    IN    A    104.28.12.7
>> 
>> 
>>    Can anyone from cloudflare answer me why this fits with your business
>> model?
>> 
>> Mike-
>> 
>> 


From larrysheldon at cox.net  Wed Jul 27 02:39:06 2016
From: larrysheldon at cox.net (Larry Sheldon)
Date: Tue, 26 Jul 2016 21:39:06 -0500
Subject: cloudflare hosting a ddos service?
In-Reply-To: <CAJL_ZMNLDvOnCMguC9ExU4ruX1mjaxZQ3eNL60mTW38VoqHRgw@mail.gmail.com>
References: <57981346.9090403@tiedyenetworks.com>
 <51419800-274B-4B6E-874A-13B48E5FAC85@ianai.net>
 <CAJL_ZMMkwSfJTEwOzJ0OFLQ0GouEN2c2UxMfgUyJDxJMABCe+w@mail.gmail.com>
 <6A7C9E2E-9D39-4D14-8671-FB13BA33F39B@isprime.com>
 <CAJL_ZMNLDvOnCMguC9ExU4ruX1mjaxZQ3eNL60mTW38VoqHRgw@mail.gmail.com>
Message-ID: <ec73ac66-43ae-758b-0bbc-9a6aa703b58e@cox.net>



On 7/26/2016 21:19, jim deleskie wrote:
> Back in the day didn't we refer to such hosting as bulletproof hosting?

Not HERE!

NANA-E, sure.



-- 
"Everybody is a genius.  But if you judge a fish by
its ability to climb a tree, it will live its whole
life believing that it is stupid."

--Albert Einstein

 From Larry's Cox account.

From paras at protrafsolutions.com  Wed Jul 27 02:42:48 2016
From: paras at protrafsolutions.com (Paras Jha)
Date: Tue, 26 Jul 2016 22:42:48 -0400
Subject: cloudflare hosting a ddos service?
In-Reply-To: <CAJayEpFwpUrmRKCsw2uVb78QvF65-=FQ6ZC0G76g9JgaZvjZ6A@mail.gmail.com>
References: <57981346.9090403@tiedyenetworks.com>
 <51419800-274B-4B6E-874A-13B48E5FAC85@ianai.net>
 <CAJL_ZMMkwSfJTEwOzJ0OFLQ0GouEN2c2UxMfgUyJDxJMABCe+w@mail.gmail.com>
 <6A7C9E2E-9D39-4D14-8671-FB13BA33F39B@isprime.com>
 <950531107-1469586277-cardhu_decombobulator_blackberry.rim.net-1930209990-@b16.c1.bise6.blackberry>
 <CAJayEpFwpUrmRKCsw2uVb78QvF65-=FQ6ZC0G76g9JgaZvjZ6A@mail.gmail.com>
Message-ID: <CAJayEpGMvwYTLBMyyUDMbnkkZv+8TuNhkcvHVN923=BHH1n9zA@mail.gmail.com>

A five minute Google search revealed this, which is just the tip of the
iceberg

booter.xyz
exitus.to
zstress.net
critical-boot.com
instress.club
webstresser.co
anonymousstresser.com
rawdos.com
kronosbooter.com
alphastress.com
synergy.so
str3ssed.me
layer7.pw

There are probably hundreds



On Tue, Jul 26, 2016 at 10:33 PM, Paras Jha <paras at protrafsolutions.com>
wrote:

> This is quite common, almost all of the DDoS-for-hire services are hosted
> behind CloudFlare, and a great majority of them take PayPal. Another one
> had even managed to secure an EV SSL cert.
>
> On Tue, Jul 26, 2016 at 10:24 PM, Dovid Bender <dovid at telecurve.com>
> wrote:
>
>> I used to have a boss that was convinced that MCafee was writing viruses
>> to stay in business....
>>
>> Regards,
>>
>> Dovid
>>
>> -----Original Message-----
>> From: Phil Rosenthal <pr at isprime.com>
>> Sender: "NANOG" <nanog-bounces at nanog.org>Date: Tue, 26 Jul 2016 22:17:53
>> To: jim deleskie<deleskie at gmail.com>
>> Cc: NANOG list<nanog at nanog.org>
>> Subject: Re: cloudflare hosting a ddos service?
>>
>> Plus, it?s good for business!
>>
>> -Phil
>>
>> > On Jul 26, 2016, at 10:14 PM, jim deleskie <deleskie at gmail.com> wrote:
>> >
>> > sigh...
>> >
>> > On Tue, Jul 26, 2016 at 10:55 PM, Patrick W. Gilmore <patrick at ianai.net
>> >
>> > wrote:
>> >
>> >> CloudFlare will claim they are not hosting the problem. They are just
>> >> hosting the web page that lets you pay for or points at or otherwise
>> >> directs you to the problem.
>> >>
>> >> The actual source of packets is some other IP address. Therefore, they
>> can
>> >> keep hosting the web page. It is not sending the actual
>> >> [spam|DDoS|hack|etc.], right? So stop asking them to do something
>> about it!
>> >>
>> >> Whether you think that is the proper way to provide service on the
>> >> Internet is left as an exercise to the reader.
>> >>
>> >> --
>> >> TTFN,
>> >> patrick
>> >>
>> >>> On Jul 26, 2016, at 9:49 PM, Mike <mike-nanog at tiedyenetworks.com>
>> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>>   So vbooter.org's dns and web is hosted by cloudflare?
>> >>>
>> >>> "Using vBooter you can take down home internet connections, websites
>> and
>> >> game servers such us Minecraft, XBOX Live, PSN and many more."
>> >>>
>> >>>   dig -t ns vbooter.org
>> >>>
>> >>> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t ns vbooter.org
>> >>> ;; global options: +cmd
>> >>> ;; Got answer:
>> >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62177
>> >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>> >>>
>> >>> ;; OPT PSEUDOSECTION:
>> >>> ; EDNS: version: 0, flags:; udp: 512
>> >>> ;; QUESTION SECTION:
>> >>> ;vbooter.org.            IN    NS
>> >>>
>> >>> ;; ANSWER SECTION:
>> >>> vbooter.org.        21599    IN    NS    rick.ns.cloudflare.com.
>> >>> vbooter.org.        21599    IN    NS    amy.ns.cloudflare.com.
>> >>>
>> >>> dig -t a www.vbooter.org
>> >>>
>> >>> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t a www.vbooter.org
>> >>> ;; global options: +cmd
>> >>> ;; Got answer:
>> >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34920
>> >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
>> >>>
>> >>> ;; OPT PSEUDOSECTION:
>> >>> ; EDNS: version: 0, flags:; udp: 512
>> >>> ;; QUESTION SECTION:
>> >>> ;www.vbooter.org.        IN    A
>> >>>
>> >>> ;; ANSWER SECTION:
>> >>> www.vbooter.org.    299    IN    CNAME    vbooter.org.
>> >>> vbooter.org.        299    IN    A    104.28.13.7
>> >>> vbooter.org.        299    IN    A    104.28.12.7
>> >>>
>> >>>
>> >>>   Can anyone from cloudflare answer me why this fits with your
>> business
>> >> model?
>> >>>
>> >>> Mike-
>> >>
>> >>
>>
>>
>
>
> --
> Regards,
> Paras
>
> President
> ProTraf Solutions, LLC
> Enterprise DDoS Mitigation
>



-- 
Regards,
Paras

President
ProTraf Solutions, LLC
Enterprise DDoS Mitigation

From eric.kuhnke at gmail.com  Wed Jul 27 02:50:41 2016
From: eric.kuhnke at gmail.com (Eric Kuhnke)
Date: Tue, 26 Jul 2016 19:50:41 -0700
Subject: cloudflare hosting a ddos service?
In-Reply-To: <CAJayEpFwpUrmRKCsw2uVb78QvF65-=FQ6ZC0G76g9JgaZvjZ6A@mail.gmail.com>
References: <57981346.9090403@tiedyenetworks.com>
 <51419800-274B-4B6E-874A-13B48E5FAC85@ianai.net>
 <CAJL_ZMMkwSfJTEwOzJ0OFLQ0GouEN2c2UxMfgUyJDxJMABCe+w@mail.gmail.com>
 <6A7C9E2E-9D39-4D14-8671-FB13BA33F39B@isprime.com>
 <950531107-1469586277-cardhu_decombobulator_blackberry.rim.net-1930209990-@b16.c1.bise6.blackberry>
 <CAJayEpFwpUrmRKCsw2uVb78QvF65-=FQ6ZC0G76g9JgaZvjZ6A@mail.gmail.com>
Message-ID: <CAB69EHjaayJGzD68FhTOXms4rNjT2nZvr=tGyEY_NgZhry9M4w@mail.gmail.com>

Looks like barrier to obtaining an EV SSL certificate is not very high
these days.

There's documentation requirements, but root CAs can't be seen to
discriminate against companies in the developing world. I suppose all you
need is a scanned business license/incorporation documents from your local
municipality in Outer Elbonia, and a few scanned copies of fake ID, and
your $99 payment for the first year.



On Tue, Jul 26, 2016 at 7:33 PM, Paras Jha <paras at protrafsolutions.com>
wrote:

> This is quite common, almost all of the DDoS-for-hire services are hosted
> behind CloudFlare, and a great majority of them take PayPal. Another one
> had even managed to secure an EV SSL cert.
>
> On Tue, Jul 26, 2016 at 10:24 PM, Dovid Bender <dovid at telecurve.com>
> wrote:
>
> > I used to have a boss that was convinced that MCafee was writing viruses
> > to stay in business....
> >
> > Regards,
> >
> > Dovid
> >
> > -----Original Message-----
> > From: Phil Rosenthal <pr at isprime.com>
> > Sender: "NANOG" <nanog-bounces at nanog.org>Date: Tue, 26 Jul 2016 22:17:53
> > To: jim deleskie<deleskie at gmail.com>
> > Cc: NANOG list<nanog at nanog.org>
> > Subject: Re: cloudflare hosting a ddos service?
> >
> > Plus, it?s good for business!
> >
> > -Phil
> >
> > > On Jul 26, 2016, at 10:14 PM, jim deleskie <deleskie at gmail.com> wrote:
> > >
> > > sigh...
> > >
> > > On Tue, Jul 26, 2016 at 10:55 PM, Patrick W. Gilmore <
> patrick at ianai.net>
> > > wrote:
> > >
> > >> CloudFlare will claim they are not hosting the problem. They are just
> > >> hosting the web page that lets you pay for or points at or otherwise
> > >> directs you to the problem.
> > >>
> > >> The actual source of packets is some other IP address. Therefore, they
> > can
> > >> keep hosting the web page. It is not sending the actual
> > >> [spam|DDoS|hack|etc.], right? So stop asking them to do something
> about
> > it!
> > >>
> > >> Whether you think that is the proper way to provide service on the
> > >> Internet is left as an exercise to the reader.
> > >>
> > >> --
> > >> TTFN,
> > >> patrick
> > >>
> > >>> On Jul 26, 2016, at 9:49 PM, Mike <mike-nanog at tiedyenetworks.com>
> > wrote:
> > >>>
> > >>> Hi,
> > >>>
> > >>>   So vbooter.org's dns and web is hosted by cloudflare?
> > >>>
> > >>> "Using vBooter you can take down home internet connections, websites
> > and
> > >> game servers such us Minecraft, XBOX Live, PSN and many more."
> > >>>
> > >>>   dig -t ns vbooter.org
> > >>>
> > >>> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t ns vbooter.org
> > >>> ;; global options: +cmd
> > >>> ;; Got answer:
> > >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62177
> > >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
> > >>>
> > >>> ;; OPT PSEUDOSECTION:
> > >>> ; EDNS: version: 0, flags:; udp: 512
> > >>> ;; QUESTION SECTION:
> > >>> ;vbooter.org.            IN    NS
> > >>>
> > >>> ;; ANSWER SECTION:
> > >>> vbooter.org.        21599    IN    NS    rick.ns.cloudflare.com.
> > >>> vbooter.org.        21599    IN    NS    amy.ns.cloudflare.com.
> > >>>
> > >>> dig -t a www.vbooter.org
> > >>>
> > >>> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t a www.vbooter.org
> > >>> ;; global options: +cmd
> > >>> ;; Got answer:
> > >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34920
> > >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
> > >>>
> > >>> ;; OPT PSEUDOSECTION:
> > >>> ; EDNS: version: 0, flags:; udp: 512
> > >>> ;; QUESTION SECTION:
> > >>> ;www.vbooter.org.        IN    A
> > >>>
> > >>> ;; ANSWER SECTION:
> > >>> www.vbooter.org.    299    IN    CNAME    vbooter.org.
> > >>> vbooter.org.        299    IN    A    104.28.13.7
> > >>> vbooter.org.        299    IN    A    104.28.12.7
> > >>>
> > >>>
> > >>>   Can anyone from cloudflare answer me why this fits with your
> business
> > >> model?
> > >>>
> > >>> Mike-
> > >>
> > >>
> >
> >
>
>
> --
> Regards,
> Paras
>
> President
> ProTraf Solutions, LLC
> Enterprise DDoS Mitigation
>

From mike-nanog at tiedyenetworks.com  Wed Jul 27 02:54:52 2016
From: mike-nanog at tiedyenetworks.com (Mike)
Date: Tue, 26 Jul 2016 19:54:52 -0700
Subject: cloudflare hosting a ddos service?
In-Reply-To: <CAJayEpGMvwYTLBMyyUDMbnkkZv+8TuNhkcvHVN923=BHH1n9zA@mail.gmail.com>
References: <57981346.9090403@tiedyenetworks.com>
 <51419800-274B-4B6E-874A-13B48E5FAC85@ianai.net>
 <CAJL_ZMMkwSfJTEwOzJ0OFLQ0GouEN2c2UxMfgUyJDxJMABCe+w@mail.gmail.com>
 <6A7C9E2E-9D39-4D14-8671-FB13BA33F39B@isprime.com>
 <950531107-1469586277-cardhu_decombobulator_blackberry.rim.net-1930209990-@b16.c1.bise6.blackberry>
 <CAJayEpFwpUrmRKCsw2uVb78QvF65-=FQ6ZC0G76g9JgaZvjZ6A@mail.gmail.com>
 <CAJayEpGMvwYTLBMyyUDMbnkkZv+8TuNhkcvHVN923=BHH1n9zA@mail.gmail.com>
Message-ID: <5798227C.1000407@tiedyenetworks.com>

On 07/26/2016 07:42 PM, Paras Jha wrote:
> A five minute Google search revealed this, which is just the tip of the
> iceberg
>
> booter.xyz
> exitus.to
> zstress.net
> critical-boot.com
> instress.club
> webstresser.co
> anonymousstresser.com
> rawdos.com
> kronosbooter.com
> alphastress.com
> synergy.so
> str3ssed.me
> layer7.pw
>
> There are probably hundreds
>
>


I should also point out that the page for www.vbooter.org also had a 
google ad (for me anyways) at the bottom advertising arbor networks!

It seems that cloudflare being an anti-ddos company needs to clean house 
then, and that if they really are conscious of this, that their 'good 
guy!' persona has taken a real beating.

Mike-


From paras at protrafsolutions.com  Wed Jul 27 03:02:02 2016
From: paras at protrafsolutions.com (Paras Jha)
Date: Tue, 26 Jul 2016 23:02:02 -0400
Subject: cloudflare hosting a ddos service?
In-Reply-To: <CABC6K17FFgHno3JJnMy_BngaJ3L7mPg5T7_hwouZp6Er_2UGFQ@mail.gmail.com>
References: <57981346.9090403@tiedyenetworks.com>
 <51419800-274B-4B6E-874A-13B48E5FAC85@ianai.net>
 <CAJL_ZMMkwSfJTEwOzJ0OFLQ0GouEN2c2UxMfgUyJDxJMABCe+w@mail.gmail.com>
 <6A7C9E2E-9D39-4D14-8671-FB13BA33F39B@isprime.com>
 <950531107-1469586277-cardhu_decombobulator_blackberry.rim.net-1930209990-@b16.c1.bise6.blackberry>
 <CAJayEpFwpUrmRKCsw2uVb78QvF65-=FQ6ZC0G76g9JgaZvjZ6A@mail.gmail.com>
 <CAJayEpGMvwYTLBMyyUDMbnkkZv+8TuNhkcvHVN923=BHH1n9zA@mail.gmail.com>
 <CABC6K17FFgHno3JJnMy_BngaJ3L7mPg5T7_hwouZp6Er_2UGFQ@mail.gmail.com>
Message-ID: <CAJayEpH1a_RO+d9SgDrj+5uNw3r=D0PSX9whDPt1F8RREg3O7Q@mail.gmail.com>

Justin,

The only problem with that statement is that it's not true: if you did
terminate service to them, the websites would go away. Maybe not today, but
eventually. "Network stresser" owners are notorious for trying to take out
the competition. Cloudflare provides free protection for these services to
stay online. Most other ISPs wouldn't tolerate such shenanigans, whether it
be for facilitating illegal activities or being on the receiving end of
DDoS attacks, and would kick them off.

On Tue, Jul 26, 2016 at 10:58 PM, Justin Paine <justin at cloudflare.com>
wrote:

> Folks,
>
> "For a long time their abuse@ alias was (literally) routed to /dev/null.
> I'm not
> sure whether that's still the case or whether they now ignore reports
> manually."
>
> @Steve   It (literally) never was. :) The team I manage processes
> reports all day
> long. If you have a report to file certainly do so,
> https://www.cloudflare.com/abuse
>
>
> On the topic of booters:
>
> Short version -- As someone already mentioned, CloudFlare continues
> not to be a hosting provider.
>
> Our CEO has broadly covered this topic several times.
> https://blog.cloudflare.com/thoughts-on-abuse/
>
> Even if we removed our service the website does not go away, it
> doesn't solve the problem if we temporarily stop providing DNS to the
> domain(s). An often overlooked but extremely important note: there are
> some situations where law
> enforcement has required that we *not* terminate service to certain
> websites. In those situations we are of course not allowed to discuss
> specifics.
>
> ____________
> Justin Paine
> Head of Trust & Safety
> CloudFlare Inc.
> PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D
>
>
> On Tue, Jul 26, 2016 at 7:42 PM, Paras Jha <paras at protrafsolutions.com>
> wrote:
> > A five minute Google search revealed this, which is just the tip of the
> > iceberg
> >
> > booter.xyz
> > exitus.to
> > zstress.net
> > critical-boot.com
> > instress.club
> > webstresser.co
> > anonymousstresser.com
> > rawdos.com
> > kronosbooter.com
> > alphastress.com
> > synergy.so
> > str3ssed.me
> > layer7.pw
> >
> > There are probably hundreds
> >
> >
> >
> > On Tue, Jul 26, 2016 at 10:33 PM, Paras Jha <paras at protrafsolutions.com>
> > wrote:
> >
> >> This is quite common, almost all of the DDoS-for-hire services are
> hosted
> >> behind CloudFlare, and a great majority of them take PayPal. Another one
> >> had even managed to secure an EV SSL cert.
> >>
> >> On Tue, Jul 26, 2016 at 10:24 PM, Dovid Bender <dovid at telecurve.com>
> >> wrote:
> >>
> >>> I used to have a boss that was convinced that MCafee was writing
> viruses
> >>> to stay in business....
> >>>
> >>> Regards,
> >>>
> >>> Dovid
> >>>
> >>> -----Original Message-----
> >>> From: Phil Rosenthal <pr at isprime.com>
> >>> Sender: "NANOG" <nanog-bounces at nanog.org>Date: Tue, 26 Jul 2016
> 22:17:53
> >>> To: jim deleskie<deleskie at gmail.com>
> >>> Cc: NANOG list<nanog at nanog.org>
> >>> Subject: Re: cloudflare hosting a ddos service?
> >>>
> >>> Plus, it?s good for business!
> >>>
> >>> -Phil
> >>>
> >>> > On Jul 26, 2016, at 10:14 PM, jim deleskie <deleskie at gmail.com>
> wrote:
> >>> >
> >>> > sigh...
> >>> >
> >>> > On Tue, Jul 26, 2016 at 10:55 PM, Patrick W. Gilmore <
> patrick at ianai.net
> >>> >
> >>> > wrote:
> >>> >
> >>> >> CloudFlare will claim they are not hosting the problem. They are
> just
> >>> >> hosting the web page that lets you pay for or points at or otherwise
> >>> >> directs you to the problem.
> >>> >>
> >>> >> The actual source of packets is some other IP address. Therefore,
> they
> >>> can
> >>> >> keep hosting the web page. It is not sending the actual
> >>> >> [spam|DDoS|hack|etc.], right? So stop asking them to do something
> >>> about it!
> >>> >>
> >>> >> Whether you think that is the proper way to provide service on the
> >>> >> Internet is left as an exercise to the reader.
> >>> >>
> >>> >> --
> >>> >> TTFN,
> >>> >> patrick
> >>> >>
> >>> >>> On Jul 26, 2016, at 9:49 PM, Mike <mike-nanog at tiedyenetworks.com>
> >>> wrote:
> >>> >>>
> >>> >>> Hi,
> >>> >>>
> >>> >>>   So vbooter.org's dns and web is hosted by cloudflare?
> >>> >>>
> >>> >>> "Using vBooter you can take down home internet connections,
> websites
> >>> and
> >>> >> game servers such us Minecraft, XBOX Live, PSN and many more."
> >>> >>>
> >>> >>>   dig -t ns vbooter.org
> >>> >>>
> >>> >>> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t ns vbooter.org
> >>> >>> ;; global options: +cmd
> >>> >>> ;; Got answer:
> >>> >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62177
> >>> >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL:
> 1
> >>> >>>
> >>> >>> ;; OPT PSEUDOSECTION:
> >>> >>> ; EDNS: version: 0, flags:; udp: 512
> >>> >>> ;; QUESTION SECTION:
> >>> >>> ;vbooter.org.            IN    NS
> >>> >>>
> >>> >>> ;; ANSWER SECTION:
> >>> >>> vbooter.org.        21599    IN    NS    rick.ns.cloudflare.com.
> >>> >>> vbooter.org.        21599    IN    NS    amy.ns.cloudflare.com.
> >>> >>>
> >>> >>> dig -t a www.vbooter.org
> >>> >>>
> >>> >>> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t a www.vbooter.org
> >>> >>> ;; global options: +cmd
> >>> >>> ;; Got answer:
> >>> >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34920
> >>> >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL:
> 1
> >>> >>>
> >>> >>> ;; OPT PSEUDOSECTION:
> >>> >>> ; EDNS: version: 0, flags:; udp: 512
> >>> >>> ;; QUESTION SECTION:
> >>> >>> ;www.vbooter.org.        IN    A
> >>> >>>
> >>> >>> ;; ANSWER SECTION:
> >>> >>> www.vbooter.org.    299    IN    CNAME    vbooter.org.
> >>> >>> vbooter.org.        299    IN    A    104.28.13.7
> >>> >>> vbooter.org.        299    IN    A    104.28.12.7
> >>> >>>
> >>> >>>
> >>> >>>   Can anyone from cloudflare answer me why this fits with your
> >>> business
> >>> >> model?
> >>> >>>
> >>> >>> Mike-
> >>> >>
> >>> >>
> >>>
> >>>
> >>
> >>
> >> --
> >> Regards,
> >> Paras
> >>
> >> President
> >> ProTraf Solutions, LLC
> >> Enterprise DDoS Mitigation
> >>
> >
> >
> >
> > --
> > Regards,
> > Paras
> >
> > President
> > ProTraf Solutions, LLC
> > Enterprise DDoS Mitigation
>



-- 
Regards,
Paras

President
ProTraf Solutions, LLC
Enterprise DDoS Mitigation

From paras at protrafsolutions.com  Wed Jul 27 03:21:30 2016
From: paras at protrafsolutions.com (Paras Jha)
Date: Tue, 26 Jul 2016 23:21:30 -0400
Subject: cloudflare hosting a ddos service?
In-Reply-To: <CAJayEpH1a_RO+d9SgDrj+5uNw3r=D0PSX9whDPt1F8RREg3O7Q@mail.gmail.com>
References: <57981346.9090403@tiedyenetworks.com>
 <51419800-274B-4B6E-874A-13B48E5FAC85@ianai.net>
 <CAJL_ZMMkwSfJTEwOzJ0OFLQ0GouEN2c2UxMfgUyJDxJMABCe+w@mail.gmail.com>
 <6A7C9E2E-9D39-4D14-8671-FB13BA33F39B@isprime.com>
 <950531107-1469586277-cardhu_decombobulator_blackberry.rim.net-1930209990-@b16.c1.bise6.blackberry>
 <CAJayEpFwpUrmRKCsw2uVb78QvF65-=FQ6ZC0G76g9JgaZvjZ6A@mail.gmail.com>
 <CAJayEpGMvwYTLBMyyUDMbnkkZv+8TuNhkcvHVN923=BHH1n9zA@mail.gmail.com>
 <CABC6K17FFgHno3JJnMy_BngaJ3L7mPg5T7_hwouZp6Er_2UGFQ@mail.gmail.com>
 <CAJayEpH1a_RO+d9SgDrj+5uNw3r=D0PSX9whDPt1F8RREg3O7Q@mail.gmail.com>
Message-ID: <CAJayEpGyy-G2oqXPTmgJgL++MPRhULO5vEyeH20GzR-RqSjv-w@mail.gmail.com>

I read through the blog post, and it was an interesting window into how
Cloudflare operates. If I could be so bold as to raise this issue, however -

Specifically, this part

*Originally, when we would receive reports of phishing or malware we would
terminate the customers immediately. The challenge was that this didn't
actually solve the problem. Since we're just a proxy, not the host, us
terminating the customer doesn't make the harmful content disappear.
Terminating the site effectively just kicked the problem further down the
road, moving it off our network and onto someone else's.*

>From that paragraph, what I understand it as is that Cloudflare doesn't
want to terminate customers hosting illegal content / facilitating illegal
activities because if they do, that content will just move elsewhere. It
was an interesting parallel to one of the problems plaguing the internet
today - source address spoofing. More and more hosts are implementing
source address verification, but unfortunately there are still those that
still allow source address spoofing (and those hosts are sometimes used to
launch amplified DDoS attacks). However, reputable hosts don't make the
argument "We won't disallow source address spoofing because if we block it,
the customers will just go elsewhere". Reputable providers block it, and
try to get others to block the problem as well. The difference is that
Cloudflare is lax "because other people are lax, so it's pointless for us
to be strict".

That kind of logic is the same flawed logic that goes with "I shouldn't
vote, because no matter which way I vote my vote is insignificant". Sure,
as a single entity that's true - but if everybody thought that, we'd be in
a real pickle. Some problems are larger than what an individual faces, and
must be addressed by not just a single entity, but all the entities to whom
this problem affects - it is your responsibility to vote, a hosts
responsibility to disable source address verification (and help fight crime
on their network), and I'd argue it's Cloudflare's responsibility to help
stop abuse.

Just my 2C

On Tue, Jul 26, 2016 at 11:02 PM, Paras Jha <paras at protrafsolutions.com>
wrote:

> Justin,
>
> The only problem with that statement is that it's not true: if you did
> terminate service to them, the websites would go away. Maybe not today, but
> eventually. "Network stresser" owners are notorious for trying to take out
> the competition. Cloudflare provides free protection for these services to
> stay online. Most other ISPs wouldn't tolerate such shenanigans, whether it
> be for facilitating illegal activities or being on the receiving end of
> DDoS attacks, and would kick them off.
>
> On Tue, Jul 26, 2016 at 10:58 PM, Justin Paine <justin at cloudflare.com>
> wrote:
>
>> Folks,
>>
>> "For a long time their abuse@ alias was (literally) routed to /dev/null.
>> I'm not
>> sure whether that's still the case or whether they now ignore reports
>> manually."
>>
>> @Steve   It (literally) never was. :) The team I manage processes
>> reports all day
>> long. If you have a report to file certainly do so,
>> https://www.cloudflare.com/abuse
>>
>>
>> On the topic of booters:
>>
>> Short version -- As someone already mentioned, CloudFlare continues
>> not to be a hosting provider.
>>
>> Our CEO has broadly covered this topic several times.
>> https://blog.cloudflare.com/thoughts-on-abuse/
>>
>> Even if we removed our service the website does not go away, it
>> doesn't solve the problem if we temporarily stop providing DNS to the
>> domain(s). An often overlooked but extremely important note: there are
>> some situations where law
>> enforcement has required that we *not* terminate service to certain
>> websites. In those situations we are of course not allowed to discuss
>> specifics.
>>
>> ____________
>> Justin Paine
>> Head of Trust & Safety
>> CloudFlare Inc.
>> PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D
>>
>>
>> On Tue, Jul 26, 2016 at 7:42 PM, Paras Jha <paras at protrafsolutions.com>
>> wrote:
>> > A five minute Google search revealed this, which is just the tip of the
>> > iceberg
>> >
>> > booter.xyz
>> > exitus.to
>> > zstress.net
>> > critical-boot.com
>> > instress.club
>> > webstresser.co
>> > anonymousstresser.com
>> > rawdos.com
>> > kronosbooter.com
>> > alphastress.com
>> > synergy.so
>> > str3ssed.me
>> > layer7.pw
>> >
>> > There are probably hundreds
>> >
>> >
>> >
>> > On Tue, Jul 26, 2016 at 10:33 PM, Paras Jha <paras at protrafsolutions.com
>> >
>> > wrote:
>> >
>> >> This is quite common, almost all of the DDoS-for-hire services are
>> hosted
>> >> behind CloudFlare, and a great majority of them take PayPal. Another
>> one
>> >> had even managed to secure an EV SSL cert.
>> >>
>> >> On Tue, Jul 26, 2016 at 10:24 PM, Dovid Bender <dovid at telecurve.com>
>> >> wrote:
>> >>
>> >>> I used to have a boss that was convinced that MCafee was writing
>> viruses
>> >>> to stay in business....
>> >>>
>> >>> Regards,
>> >>>
>> >>> Dovid
>> >>>
>> >>> -----Original Message-----
>> >>> From: Phil Rosenthal <pr at isprime.com>
>> >>> Sender: "NANOG" <nanog-bounces at nanog.org>Date: Tue, 26 Jul 2016
>> 22:17:53
>> >>> To: jim deleskie<deleskie at gmail.com>
>> >>> Cc: NANOG list<nanog at nanog.org>
>> >>> Subject: Re: cloudflare hosting a ddos service?
>> >>>
>> >>> Plus, it?s good for business!
>> >>>
>> >>> -Phil
>> >>>
>> >>> > On Jul 26, 2016, at 10:14 PM, jim deleskie <deleskie at gmail.com>
>> wrote:
>> >>> >
>> >>> > sigh...
>> >>> >
>> >>> > On Tue, Jul 26, 2016 at 10:55 PM, Patrick W. Gilmore <
>> patrick at ianai.net
>> >>> >
>> >>> > wrote:
>> >>> >
>> >>> >> CloudFlare will claim they are not hosting the problem. They are
>> just
>> >>> >> hosting the web page that lets you pay for or points at or
>> otherwise
>> >>> >> directs you to the problem.
>> >>> >>
>> >>> >> The actual source of packets is some other IP address. Therefore,
>> they
>> >>> can
>> >>> >> keep hosting the web page. It is not sending the actual
>> >>> >> [spam|DDoS|hack|etc.], right? So stop asking them to do something
>> >>> about it!
>> >>> >>
>> >>> >> Whether you think that is the proper way to provide service on the
>> >>> >> Internet is left as an exercise to the reader.
>> >>> >>
>> >>> >> --
>> >>> >> TTFN,
>> >>> >> patrick
>> >>> >>
>> >>> >>> On Jul 26, 2016, at 9:49 PM, Mike <mike-nanog at tiedyenetworks.com>
>> >>> wrote:
>> >>> >>>
>> >>> >>> Hi,
>> >>> >>>
>> >>> >>>   So vbooter.org's dns and web is hosted by cloudflare?
>> >>> >>>
>> >>> >>> "Using vBooter you can take down home internet connections,
>> websites
>> >>> and
>> >>> >> game servers such us Minecraft, XBOX Live, PSN and many more."
>> >>> >>>
>> >>> >>>   dig -t ns vbooter.org
>> >>> >>>
>> >>> >>> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t ns vbooter.org
>> >>> >>> ;; global options: +cmd
>> >>> >>> ;; Got answer:
>> >>> >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62177
>> >>> >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0,
>> ADDITIONAL: 1
>> >>> >>>
>> >>> >>> ;; OPT PSEUDOSECTION:
>> >>> >>> ; EDNS: version: 0, flags:; udp: 512
>> >>> >>> ;; QUESTION SECTION:
>> >>> >>> ;vbooter.org.            IN    NS
>> >>> >>>
>> >>> >>> ;; ANSWER SECTION:
>> >>> >>> vbooter.org.        21599    IN    NS    rick.ns.cloudflare.com.
>> >>> >>> vbooter.org.        21599    IN    NS    amy.ns.cloudflare.com.
>> >>> >>>
>> >>> >>> dig -t a www.vbooter.org
>> >>> >>>
>> >>> >>> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t a www.vbooter.org
>> >>> >>> ;; global options: +cmd
>> >>> >>> ;; Got answer:
>> >>> >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34920
>> >>> >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0,
>> ADDITIONAL: 1
>> >>> >>>
>> >>> >>> ;; OPT PSEUDOSECTION:
>> >>> >>> ; EDNS: version: 0, flags:; udp: 512
>> >>> >>> ;; QUESTION SECTION:
>> >>> >>> ;www.vbooter.org.        IN    A
>> >>> >>>
>> >>> >>> ;; ANSWER SECTION:
>> >>> >>> www.vbooter.org.    299    IN    CNAME    vbooter.org.
>> >>> >>> vbooter.org.        299    IN    A    104.28.13.7
>> >>> >>> vbooter.org.        299    IN    A    104.28.12.7
>> >>> >>>
>> >>> >>>
>> >>> >>>   Can anyone from cloudflare answer me why this fits with your
>> >>> business
>> >>> >> model?
>> >>> >>>
>> >>> >>> Mike-
>> >>> >>
>> >>> >>
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Regards,
>> >> Paras
>> >>
>> >> President
>> >> ProTraf Solutions, LLC
>> >> Enterprise DDoS Mitigation
>> >>
>> >
>> >
>> >
>> > --
>> > Regards,
>> > Paras
>> >
>> > President
>> > ProTraf Solutions, LLC
>> > Enterprise DDoS Mitigation
>>
>
>
>
> --
> Regards,
> Paras
>
> President
> ProTraf Solutions, LLC
> Enterprise DDoS Mitigation
>



-- 
Regards,
Paras

President
ProTraf Solutions, LLC
Enterprise DDoS Mitigation

From steve at blighty.com  Wed Jul 27 03:22:36 2016
From: steve at blighty.com (Steve Atkins)
Date: Tue, 26 Jul 2016 20:22:36 -0700
Subject: cloudflare hosting a ddos service?
In-Reply-To: <CABC6K17FFgHno3JJnMy_BngaJ3L7mPg5T7_hwouZp6Er_2UGFQ@mail.gmail.com>
References: <57981346.9090403@tiedyenetworks.com>
 <51419800-274B-4B6E-874A-13B48E5FAC85@ianai.net>
 <CAJL_ZMMkwSfJTEwOzJ0OFLQ0GouEN2c2UxMfgUyJDxJMABCe+w@mail.gmail.com>
 <6A7C9E2E-9D39-4D14-8671-FB13BA33F39B@isprime.com>
 <950531107-1469586277-cardhu_decombobulator_blackberry.rim.net-1930209990-@b16.c1.bise6.blackberry>
 <CAJayEpFwpUrmRKCsw2uVb78QvF65-=FQ6ZC0G76g9JgaZvjZ6A@mail.gmail.com>
 <CAJayEpGMvwYTLBMyyUDMbnkkZv+8TuNhkcvHVN923=BHH1n9zA@mail.gmail.com>
 <CABC6K17FFgHno3JJnMy_BngaJ3L7mPg5T7_hwouZp6Er_2UGFQ@mail.gmail.com>
Message-ID: <0CFAD133-E391-413C-833A-1AB2170B4AD7@blighty.com>


> On Jul 26, 2016, at 7:58 PM, Justin Paine <justin at cloudflare.com> wrote:
> 
> Folks,
> 
> "For a long time their abuse@ alias was (literally) routed to /dev/null. I'm not
> sure whether that's still the case or whether they now ignore reports manually."
> 
> @Steve   It (literally) never was. :)

Yes, it was. The smiley doesn't make your statement true.

> The team I manage processes
> reports all day
> long. If you have a report to file certainly do so,
> https://www.cloudflare.com/abuse

I gave up on doing that in late 2014 after reporting thousands of pieces of spam
advertising websites hosted by Cloudflare, with no action taken, no reply received,
no ticket created, *nothing*. Not in response to mail sent to abuse at cloudflare,
not in response to backchannel reports, not in response to mentions in person to
staff at conferences. (This was mostly people selling lists of credit card numbers
rather than booters, but it's the same sort of issue).

Just to see what had changed, I went back to look at the sites I reported to
Cloudflare in 2014. The couple I spot-checked are still hosted by Cloudflare.

Given that you (Cloudflare, rather than you personally) haven't changed
your policy of never terminating abusive websites you host then continuing to
report them to you seems fairly pointless.

> 
> 
> On the topic of booters:
> 
> Short version -- As someone already mentioned, CloudFlare continues
> not to be a hosting provider.

That's untrue, of course. You terminate the http connection; you're
hosting the website; you're hiding the identity of any other operators
involved; you continue to serve the website even when the backing
server has been terminated. Adding an interstitial for sites hosting
malware is nice and all, but the problematic customers are the ones
that are selling access to those malware compromised machines.

You are taking sole responsibility by your actions, while denying all
responsibility in your public statements.

> 
> Our CEO has broadly covered this topic several times.
> https://blog.cloudflare.com/thoughts-on-abuse/
> 
> Even if we removed our service the website does not go away,it
> doesn't solve the problem if we temporarily stop providing DNS to the
> domain(s). An often overlooked but extremely important note: there are
> some situations where law
> enforcement has required that we *not* terminate service to certain
> websites. In those situations we are of course not allowed to discuss
> specifics.

Cheers,
  Steve



From manager at monmouth.com  Wed Jul 27 12:28:39 2016
From: manager at monmouth.com (Mark Stevens)
Date: Wed, 27 Jul 2016 08:28:39 -0400
Subject: Yahoo Postmaster or Email Admin
Message-ID: <f424f693-e87e-6077-d794-51027aa2b2a2@monmouth.com>

Good Morning,

If there is a Yahoo postmaster or email Admin that could contact me 
offline concerning a deferred IP address it would be great.


Thanks

Mark

From matt at kahlerlarson.org  Tue Jul 26 13:15:20 2016
From: matt at kahlerlarson.org (Matt Larson)
Date: Tue, 26 Jul 2016 09:15:20 -0400
Subject: Notice about project to roll the root zone KSK
References: <F92293F4-EFD6-410B-B1DC-1C47CBEF2DB3@icann.org>
Message-ID: <F0AED577-E4AC-44A7-B082-70903B8679D9@kahlerlarson.org>

I realize DNS operational content isn't the usual NANOG fare, but rolling the root zone KSK for the first time is a significant-enough event that I wanted to send to this list anyway.

TL;DR: The root zone KSK is changing on October 11, 2017 (yes, over a year away).  If you're doing DNSSEC validation, you should care.  If you're not the DNS person in your organization, please pass this notice on to that person.  If the topic interests you, more information is below.

Matt
--
Matt Larson
VP of Research
Office of the CTO, ICANN


> Begin forwarded message:
> 
> From: Matt Larson <matt.larson at icann.org>
> Subject: Plan documents for root KSK roll project now available
> Date: July 26, 2016 at 8:59:45 AM EDT
> To: <ksk-rollover at icann.org>
> 
> On Friday, July 22, in the interests of transparency and to notify the DNS operational community, ICANN posted plans <https://www.icann.org/resources/pages/ksk-rollover#operational-plans> to roll the root zone key signing key (KSK).  These plans were developed by the Root Zone Management Partners: ICANN in its role as the IANA Functions Operator, Verisign acting as the Root Zone Maintainer, and the U.S. Department of Commerce's National Telecommunications and Information Administration (NTIA) as the Root Zone Administrator.  The plans incorporate the March 2016 recommendations <https://www.iana.org/reports/2016/root-ksk-rollover-design-20160307.pdf> of the Root Zone KSK Rollover Design Team, after it sought and considered public comment <https://www.icann.org/news/announcement-2013-03-08-en> on a proposed rollover process.
> 
> The process of creating a new key, using it to sign the root DNSKEY RRset and securely destroying the old key will start in Q4 2016 and last until Q3 2016, though the portions resulting in visible changes in DNS occur between Q3 2016 and Q1 2017.  The important milestones in the project are:
> 
> - October 26, 2016: The new KSK is generated in ICANN's U.S. East Coast key management facility (KMF).
> - February, 2017: The new KSK is copied to ICANN's U.S. West Coast KMF and is considered operationally ready, and ICANN publishes the new key at https://data.iana.org/root-anchors/root-anchors.xml <https://data.iana.org/root-anchors/root-anchors.xml>.  (The exact date is dependent on the timing of the Q1 2017 key ceremony, which has not yet been scheduled.)
> - July 11, 2017: The new KSK appears in the root DNSKEY RRset for the first time.
> - October 11, 2017: The new KSK signs the root DNSKEY RRset (and the old KSK no longer signs).  This date is the actual KSK rollover.
> - January 11, 2018: The old KSK is published as revoked (per RFC 5011, "Automated Updates of DNS Security").
> 
> What you need to do
> 
> If you operate any software performing DNSSEC validation (such as a security-aware recursive name server) that implements the RFC 5011 automated trust anchor update protocol and this functionality is enabled, you have no action: your software will notice the new KSK (authenticated by the old KSK) and update its trust anchor store accordingly.
> 
> If you operate any software performing DNSSEC validation that does not implement RFC 5011 or if you don't use the RFC 5011 protocol, you will need to update your software's trust anchor configuration manually to add the new KSK before October 11, 2017.  You can obtain the new KSK in February, 2017, using one of the methods described in the "Trust Anchor Publication" section of 2017 KSK Rollover Operational Implementation Plan <https://www.icann.org/en/system/files/files/ksk-rollover-operational-implementation-plan-22jul16-en.pdf> (one of the aforementioned recently published plans).
> 
> If you write, package or distribute software that performs DNSSEC validation and you hard code the root KSK (e.g., in code or configuration files), you should update your software with the new KSK when it becomes available in February, 2017.
> 
> Staying informed
> 
> ICANN will post occasional notices to various operational forums to keep the community informed of this project's progress, but we strongly suggest that anyone with an interest subscribe to the root KSK rollover mailing list <https://mm.icann.org/mailman/listinfo/ksk-rollover> operated by ICANN (ksk-rollover at icann.org <mailto:ksk-rollover at icann.org>).  The list is extremely low volume.
> 
> The ICANN staff supporting and implementing the root KSK rollover project welcome your questions and comments: please direct them to the ksk-rollover at icann.org <mailto:ksk-rollover at icann.org> list.
> 
> Matt
> --
> Matt Larson
> VP of Research
> Office of the CTO, ICANN
> 


From j.j.santanna at utwente.nl  Wed Jul 27 13:49:50 2016
From: j.j.santanna at utwente.nl (Jair Santanna)
Date: Wed, 27 Jul 2016 15:49:50 +0200
Subject: EVERYTHING about Booters (and CloudFlare)
Message-ID: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>

Hi folks,

A friend forward me your topic about Booters and CloudFlare. Then I 
decided to join the NANOG list. The *answer* for the first question 
about CloudFlare and Booters is at: 
https://www.youtube.com/watch?v=wW5vJyI_HcU (minute 45:55) given by the 
_CloudFlare CEO_ in the blackhat2013.

I investigate Booters since 2013 and I know many (if not all) the 
possible aspects about this DDoS-as-a-Service phenomenon. A summary of 
my entire research (or large part of that) can be watched at 
https://tnc16.geant.org/web/media/archive/3A (from minute 22:53). On top 
of that, I developed an algorithm to find Booters and publicly share 
such list (http://booterblacklist.com/). My main goal with this 
initiative is to convince people to blacklist and keep on track the 
users that access Booters (that potentially perform attacks)

If you have any question about any aspect of the entire phenomenon don't 
hesitate to contact me. By the way, I want to help deploy the booters 
blacklist worldwide and help prosecutors to shutdown this bastards. I 
have many evidences!

Cheers,

Jair Santanna
jairsantanna.com




From paras at protrafsolutions.com  Wed Jul 27 14:37:21 2016
From: paras at protrafsolutions.com (Paras Jha)
Date: Wed, 27 Jul 2016 10:37:21 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
Message-ID: <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>

Hi Jair,

This list is really interesting.

>From just a preliminary test, more than half of these domains are hiding
behind Cloudflare, and OVH has a sizable fraction too. I suppose it's
inevitable, given that both are known for having non-existent abuse
departments.

Regards

On Wed, Jul 27, 2016 at 9:49 AM, Jair Santanna <j.j.santanna at utwente.nl>
wrote:

> Hi folks,
>
> A friend forward me your topic about Booters and CloudFlare. Then I
> decided to join the NANOG list. The *answer* for the first question about
> CloudFlare and Booters is at: https://www.youtube.com/watch?v=wW5vJyI_HcU
> (minute 45:55) given by the _CloudFlare CEO_ in the blackhat2013.
>
> I investigate Booters since 2013 and I know many (if not all) the possible
> aspects about this DDoS-as-a-Service phenomenon. A summary of my entire
> research (or large part of that) can be watched at
> https://tnc16.geant.org/web/media/archive/3A (from minute 22:53). On top
> of that, I developed an algorithm to find Booters and publicly share such
> list (http://booterblacklist.com/). My main goal with this initiative is
> to convince people to blacklist and keep on track the users that access
> Booters (that potentially perform attacks)
>
> If you have any question about any aspect of the entire phenomenon don't
> hesitate to contact me. By the way, I want to help deploy the booters
> blacklist worldwide and help prosecutors to shutdown this bastards. I have
> many evidences!
>
> Cheers,
>
> Jair Santanna
> jairsantanna.com
>
>
>
>


-- 
Regards,
Paras

President
ProTraf Solutions, LLC
Enterprise DDoS Mitigation

From randy at psg.com  Wed Jul 27 14:56:04 2016
From: randy at psg.com (Randy Bush)
Date: Wed, 27 Jul 2016 23:56:04 +0900
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
Message-ID: <m2popz2kqj.wl%randy@psg.com>

> From just a preliminary test, more than half of these domains are
> hiding behind Cloudflare, and OVH has a sizable fraction too.

you mean are using cloudflare and ovh services.

> I suppose it's inevitable, given that both are known for having
> non-existent abuse departments.

as the OP made pretty clear, it's not a matter of an abuse contact.
it is the service not acting as a law enforcement agency and asking
for a court order.  most large service providers operate in that way.

randy

From paras at protrafsolutions.com  Wed Jul 27 14:58:49 2016
From: paras at protrafsolutions.com (Paras Jha)
Date: Wed, 27 Jul 2016 10:58:49 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <CABC6K15-1Vb7C9g_JDfsgGT0QSU7vtEhWfb9Bv3cMyhR8iURmA@mail.gmail.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <CABC6K15-1Vb7C9g_JDfsgGT0QSU7vtEhWfb9Bv3cMyhR8iURmA@mail.gmail.com>
Message-ID: <CAJayEpFyP5NVsST4y5qSep-uJK7eXjaLXGWzVotVwX1pQ1cZ+Q@mail.gmail.com>

Hi Justin,

I have submitted abuse reports in the past, maybe from 2014 - 2015, but I
gave up after I consistently did not even get replies and saw no action
being taken. It is the same behavior with other providers who host malware
knowingly. I appreciate you coming out onto the list though, it's nice to
see that CF does maintain a presence here.

Regards
Paras

From paras at protrafsolutions.com  Wed Jul 27 15:00:40 2016
From: paras at protrafsolutions.com (Paras Jha)
Date: Wed, 27 Jul 2016 11:00:40 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <m2popz2kqj.wl%randy@psg.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
Message-ID: <CAJayEpEnNZJKBeXp7FjJOP5hQKOMrfweZzarv543Dijbv_ujZg@mail.gmail.com>

Hi Randy,

I've found the vast majority of large service providers to be very
receptive to abuse reports when they contain evidence and valid information.

Regards
Paras

From joquendo at e-fensive.net  Wed Jul 27 15:02:40 2016
From: joquendo at e-fensive.net (J. Oquendo)
Date: Wed, 27 Jul 2016 10:02:40 -0500
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <CAJayEpFyP5NVsST4y5qSep-uJK7eXjaLXGWzVotVwX1pQ1cZ+Q@mail.gmail.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <CABC6K15-1Vb7C9g_JDfsgGT0QSU7vtEhWfb9Bv3cMyhR8iURmA@mail.gmail.com>
 <CAJayEpFyP5NVsST4y5qSep-uJK7eXjaLXGWzVotVwX1pQ1cZ+Q@mail.gmail.com>
Message-ID: <20160727150240.GB11638@e-fensive.net>

On Wed, 27 Jul 2016, Paras Jha wrote:

> Hi Justin,
> 
> I have submitted abuse reports in the past, maybe from 2014 - 2015, but I
> gave up after I consistently did not even get replies and saw no action
> being taken. It is the same behavior with other providers who host malware
> knowingly. I appreciate you coming out onto the list though, it's nice to
> see that CF does maintain a presence here.
> 

I for one am glad providers are on the case tackling DoS,
never ignoring abuse, and doing the best they can to
prevent these things:

https://www.linkedin.com/pulse/why-do-networking-providers-like-cybercriminals-so-much-j-oquendo

-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM

"Where ignorance is our master, there is no possibility of
real peace" - Dalai Lama

0B23 595C F07C 6092 8AEB  074B FC83 7AF5 9D8A 4463
https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463

From Steve.Mikulasik at civeo.com  Wed Jul 27 15:09:51 2016
From: Steve.Mikulasik at civeo.com (Steve Mikulasik)
Date: Wed, 27 Jul 2016 15:09:51 +0000
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <m2popz2kqj.wl%randy@psg.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
Message-ID: <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>

I am sure a lawyer would see it very differently, I could see someone looking at this like racketeering. They get paid to provide a service to defend against DDoS, well knowingly hosting people who conduct DDoS attacks. Cloudflare profits from both the victims and the criminals. If Cloudflare isn't acting in good faith to shut down these sites when they receive evidence they are bad actors, they could find themselves in a bit of trouble. 

At this point Cloudflare would know that these bad actors are hosted on their service since we know many Cloudflare employees subscribe to the NANOG list, and the list of bad actors would now show up in their email server, ready for legal discovery.

Disclaimer: I have a ton of respect for Clouldflare and what they do on the internet. 

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy Bush
Sent: Wednesday, July 27, 2016 8:56 AM
To: Paras Jha <paras at protrafsolutions.com>
Cc: NANOG list <nanog at nanog.org>
Subject: Re: EVERYTHING about Booters (and CloudFlare)

> I suppose it's inevitable, given that both are known for having 
> non-existent abuse departments.

as the OP made pretty clear, it's not a matter of an abuse contact.
it is the service not acting as a law enforcement agency and asking for a court order.  most large service providers operate in that way.

randy


From dovid at telecurve.com  Wed Jul 27 15:44:54 2016
From: dovid at telecurve.com (Dovid Bender)
Date: Wed, 27 Jul 2016 11:44:54 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
Message-ID: <CAM3TTh1yiWQ1j6x0wdROnUrEnVz63AtCtkUw+EU7Rspj4pU=Bg@mail.gmail.com>

As was mentioned in the BlackHat video the DDOS providers don't like
competition and they try to take each other out which is they they nee to
be on clouadfare. If they were all kicked off of Cloudfare then they would
all take each other out leaving no need for clouydfare's DDOS sevices. So
by hosting these companies they are ensuring that they will have business.

(I have no evidence to this. Just a theory..............)



On Wed, Jul 27, 2016 at 11:09 AM, Steve Mikulasik <Steve.Mikulasik at civeo.com
> wrote:

> I am sure a lawyer would see it very differently, I could see someone
> looking at this like racketeering. They get paid to provide a service to
> defend against DDoS, well knowingly hosting people who conduct DDoS
> attacks. Cloudflare profits from both the victims and the criminals. If
> Cloudflare isn't acting in good faith to shut down these sites when they
> receive evidence they are bad actors, they could find themselves in a bit
> of trouble.
>
> At this point Cloudflare would know that these bad actors are hosted on
> their service since we know many Cloudflare employees subscribe to the
> NANOG list, and the list of bad actors would now show up in their email
> server, ready for legal discovery.
>
> Disclaimer: I have a ton of respect for Clouldflare and what they do on
> the internet.
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy Bush
> Sent: Wednesday, July 27, 2016 8:56 AM
> To: Paras Jha <paras at protrafsolutions.com>
> Cc: NANOG list <nanog at nanog.org>
> Subject: Re: EVERYTHING about Booters (and CloudFlare)
>
> > I suppose it's inevitable, given that both are known for having
> > non-existent abuse departments.
>
> as the OP made pretty clear, it's not a matter of an abuse contact.
> it is the service not acting as a law enforcement agency and asking for a
> court order.  most large service providers operate in that way.
>
> randy
>
>

From baldur.norddahl at gmail.com  Wed Jul 27 16:17:50 2016
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Wed, 27 Jul 2016 18:17:50 +0200
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
Message-ID: <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>

Den 27. jul. 2016 17.12 skrev "Steve Mikulasik" <Steve.Mikulasik at civeo.com>:
>
> Disclaimer: I have a ton of respect for Clouldflare and what they do on
the internet.

They just lost all respect from here. Would someone from USA please report
these guys to the feds? What they are doing is outright criminal.

Regards

Baldur

From manager at monmouth.com  Wed Jul 27 16:18:19 2016
From: manager at monmouth.com (Mark Stevens)
Date: Wed, 27 Jul 2016 12:18:19 -0400
Subject: Yahoo Postmaster or Email Admin
In-Reply-To: <f424f693-e87e-6077-d794-51027aa2b2a2@monmouth.com>
References: <f424f693-e87e-6077-d794-51027aa2b2a2@monmouth.com>
Message-ID: <209a8966-0232-197e-7515-4ec70d4964d9@monmouth.com>

Good afternoon,

Does anyone have a contact at Yahoo that could help with getting an IP 
de-listed from Yahoo email blacklist?

Thanks

Mark

On 7/27/2016 8:28 AM, Mark Stevens wrote:
> Good Morning,
>
> If there is a Yahoo postmaster or email Admin that could contact me 
> offline concerning a deferred IP address it would be great.
>
>
> Thanks
>
> Mark
>


From dot at dotat.at  Wed Jul 27 16:30:32 2016
From: dot at dotat.at (Tony Finch)
Date: Wed, 27 Jul 2016 17:30:32 +0100
Subject: Yahoo Postmaster or Email Admin
In-Reply-To: <209a8966-0232-197e-7515-4ec70d4964d9@monmouth.com>
References: <f424f693-e87e-6077-d794-51027aa2b2a2@monmouth.com>
 <209a8966-0232-197e-7515-4ec70d4964d9@monmouth.com>
Message-ID: <alpine.DEB.2.11.1607271729520.14894@grey.csi.cam.ac.uk>

For this kind of question you might hav emore luck on the mailop list,
https://chilli.nosignal.org/mailman/listinfo/mailop

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
North Fitzroy, Sole, Lundy, Fastnet: Westerly 5 or 6. Moderate, occasionally
rough later. Rain or drizzle. Moderate or poor, occasionally good.

From steve at blighty.com  Wed Jul 27 16:32:40 2016
From: steve at blighty.com (Steve Atkins)
Date: Wed, 27 Jul 2016 09:32:40 -0700
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
Message-ID: <317C533A-2373-4B06-8A98-6BA10547E8C2@blighty.com>


> On Jul 27, 2016, at 9:17 AM, Baldur Norddahl <baldur.norddahl at gmail.com> wrote:
> 
> Den 27. jul. 2016 17.12 skrev "Steve Mikulasik" <Steve.Mikulasik at civeo.com>:
>> 
>> Disclaimer: I have a ton of respect for Clouldflare and what they do on
> the internet.
> 
> They just lost all respect from here. Would someone from USA please report
> these guys to the feds? What they are doing is outright criminal.

They can monitor (passively or actively) all access to the sites they host, even
the ones that use SSL, and they often use their close working relationship with
law enforcement to explain why they don't terminate bad actors on their network.

You can probably assume that "the feds" are intimately aware of what they're doing.

Cheers,
  Steve


From beecher at beecher.cc  Wed Jul 27 16:37:50 2016
From: beecher at beecher.cc (Tom Beecher)
Date: Wed, 27 Jul 2016 12:37:50 -0400
Subject: Yahoo Postmaster or Email Admin
In-Reply-To: <alpine.DEB.2.11.1607271729520.14894@grey.csi.cam.ac.uk>
References: <f424f693-e87e-6077-d794-51027aa2b2a2@monmouth.com>
 <209a8966-0232-197e-7515-4ec70d4964d9@monmouth.com>
 <alpine.DEB.2.11.1607271729520.14894@grey.csi.cam.ac.uk>
Message-ID: <CAL9Qcx6EOFKyazsMV59O0tc+UfM=f3LJ+NzOhrqN+rdnvfpL7w@mail.gmail.com>

*https://postmaster.yahoo.com <https://postmaster.yahoo.com>*

*https://help.yahoo.com/kb/postmaster/postmaster-sending-issues-sln22608.html
<https://help.yahoo.com/kb/postmaster/postmaster-sending-issues-sln22608.html>*


On Wed, Jul 27, 2016 at 12:30 PM, Tony Finch <dot at dotat.at> wrote:

> For this kind of question you might hav emore luck on the mailop list,
> https://chilli.nosignal.org/mailman/listinfo/mailop
>
> Tony.
> --
> f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h
> punycode
> North Fitzroy, Sole, Lundy, Fastnet: Westerly 5 or 6. Moderate,
> occasionally
> rough later. Rain or drizzle. Moderate or poor, occasionally good.
>

From zwicky at yahoo-inc.com  Wed Jul 27 16:39:33 2016
From: zwicky at yahoo-inc.com (Elizabeth Zwicky)
Date: Wed, 27 Jul 2016 16:39:33 +0000 (UTC)
Subject: Yahoo Postmaster or Email Admin
In-Reply-To: <f424f693-e87e-6077-d794-51027aa2b2a2@monmouth.com>
References: <f424f693-e87e-6077-d794-51027aa2b2a2@monmouth.com>
Message-ID: <519292135.209299.1469637573871.JavaMail.yahoo@mail.yahoo.com>

We encourage people to start at https://postmaster.yaho.com?but I can help people who have filed tickets there and not had any luck can contact me, specifying a) what IP addresses and From: line they're talking about and b) exactly what error message they are getting when they try to send us mail.
Elizabeth
On Wednesday, July 27, 2016, 5:31:55 AM PDT, Mark Stevens <manager at monmouth.com> wrote:Good Morning,

If there is a Yahoo postmaster or email Admin that could contact me 
offline concerning a deferred IP address it would be great.


Thanks

Mark

From josh at imaginenetworksllc.com  Wed Jul 27 16:43:43 2016
From: josh at imaginenetworksllc.com (Josh Luthman)
Date: Wed, 27 Jul 2016 12:43:43 -0400
Subject: Yahoo Postmaster or Email Admin
In-Reply-To: <519292135.209299.1469637573871.JavaMail.yahoo@mail.yahoo.com>
References: <f424f693-e87e-6077-d794-51027aa2b2a2@monmouth.com>
 <519292135.209299.1469637573871.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <CAN9qwJ-01U=9EmTLHP1A7aLgm2O=y1XPKPab_Ryt102wJHzuig@mail.gmail.com>

Do you mean https://postmaster.yahoo.com/ ?


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Wed, Jul 27, 2016 at 12:39 PM, Elizabeth Zwicky via NANOG <
nanog at nanog.org> wrote:

> We encourage people to start at https://postmaster.yaho.com but I can
> help people who have filed tickets there and not had any luck can contact
> me, specifying a) what IP addresses and From: line they're talking about
> and b) exactly what error message they are getting when they try to send us
> mail.
> Elizabeth
> On Wednesday, July 27, 2016, 5:31:55 AM PDT, Mark Stevens <
> manager at monmouth.com> wrote:Good Morning,
>
> If there is a Yahoo postmaster or email Admin that could contact me
> offline concerning a deferred IP address it would be great.
>
>
> Thanks
>
> Mark
>

From zwicky at yahoo-inc.com  Wed Jul 27 16:49:59 2016
From: zwicky at yahoo-inc.com (Elizabeth Zwicky)
Date: Wed, 27 Jul 2016 16:49:59 +0000 (UTC)
Subject: Yahoo Postmaster or Email Admin
In-Reply-To: <CAN9qwJ-01U=9EmTLHP1A7aLgm2O=y1XPKPab_Ryt102wJHzuig@mail.gmail.com>
References: <f424f693-e87e-6077-d794-51027aa2b2a2@monmouth.com>
 <519292135.209299.1469637573871.JavaMail.yahoo@mail.yahoo.com>
 <CAN9qwJ-01U=9EmTLHP1A7aLgm2O=y1XPKPab_Ryt102wJHzuig@mail.gmail.com>
Message-ID: <78239981.209347.1469638199379.JavaMail.yahoo@mail.yahoo.com>


Yes, yes I do. 

    On Wednesday, July 27, 2016 9:44 AM, Josh Luthman <josh at imaginenetworksllc.com> wrote:
 

 Do you mean?https://postmaster.yahoo.com/ ?

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
On Wed, Jul 27, 2016 at 12:39 PM, Elizabeth Zwicky via NANOG <nanog at nanog.org> wrote:

We encourage people to start at https://postmaster.yaho.com?but I can help people who have filed tickets there and not had any luck can contact me, specifying a) what IP addresses and From: line they're talking about and b) exactly what error message they are getting when they try to send us mail.
Elizabeth
On Wednesday, July 27, 2016, 5:31:55 AM PDT, Mark Stevens <manager at monmouth.com> wrote:Good Morning,

If there is a Yahoo postmaster or email Admin that could contact me
offline concerning a deferred IP address it would be great.


Thanks

Mark




  

From bkain1 at ford.com  Wed Jul 27 16:53:19 2016
From: bkain1 at ford.com (Kain, Rebecca (.))
Date: Wed, 27 Jul 2016 16:53:19 +0000
Subject: Yahoo Postmaster or Email Admin
In-Reply-To: <78239981.209347.1469638199379.JavaMail.yahoo@mail.yahoo.com>
References: <f424f693-e87e-6077-d794-51027aa2b2a2@monmouth.com>
 <519292135.209299.1469637573871.JavaMail.yahoo@mail.yahoo.com>
 <CAN9qwJ-01U=9EmTLHP1A7aLgm2O=y1XPKPab_Ryt102wJHzuig@mail.gmail.com>
 <78239981.209347.1469638199379.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <a42180f5baa04ee6b57fd3b06568f6ed@nafcmb01.exchange.ford.com>

Maybe they could get their email working. it's been hanging, not sending mail, for 4 days, as far my experience has been.

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Elizabeth Zwicky via NANOG
Sent: Wednesday, July 27, 2016 12:50 PM
To: Josh Luthman
Cc: NANOG list
Subject: Re: Yahoo Postmaster or Email Admin


Yes, yes I do. 

    On Wednesday, July 27, 2016 9:44 AM, Josh Luthman <josh at imaginenetworksllc.com> wrote:
 

 Do you mean?https://postmaster.yahoo.com/ ?

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
On Wed, Jul 27, 2016 at 12:39 PM, Elizabeth Zwicky via NANOG <nanog at nanog.org> wrote:

We encourage people to start at https://postmaster.yaho.com?but I can help people who have filed tickets there and not had any luck can contact me, specifying a) what IP addresses and From: line they're talking about and b) exactly what error message they are getting when they try to send us mail.
Elizabeth
On Wednesday, July 27, 2016, 5:31:55 AM PDT, Mark Stevens <manager at monmouth.com> wrote:Good Morning,

If there is a Yahoo postmaster or email Admin that could contact me
offline concerning a deferred IP address it would be great.


Thanks

Mark




  

From manager at monmouth.com  Wed Jul 27 17:05:44 2016
From: manager at monmouth.com (Mark Stevens)
Date: Wed, 27 Jul 2016 13:05:44 -0400
Subject: Yahoo Postmaster or Email Admin
In-Reply-To: <a42180f5baa04ee6b57fd3b06568f6ed@nafcmb01.exchange.ford.com>
References: <f424f693-e87e-6077-d794-51027aa2b2a2@monmouth.com>
 <519292135.209299.1469637573871.JavaMail.yahoo@mail.yahoo.com>
 <CAN9qwJ-01U=9EmTLHP1A7aLgm2O=y1XPKPab_Ryt102wJHzuig@mail.gmail.com>
 <78239981.209347.1469638199379.JavaMail.yahoo@mail.yahoo.com>
 <a42180f5baa04ee6b57fd3b06568f6ed@nafcmb01.exchange.ford.com>
Message-ID: <42265d93-a705-3a9c-86eb-d6f22fa4f893@monmouth.com>

I have been to https://postmaster.yahoo.com and even filled out a bulk 
email form (explained the issue in the notes section) but still no go.
I even have a ticket opened with their support but you can guess how 
that is going.....
This is why I asked if anyone has a contact or if in fact a sysadmin @ 
yahoo is on nanog and could contact me.
I will keep working at this, thanks for the info!

Mark

On 7/27/2016 12:53 PM, Kain, Rebecca (.) wrote:
> Maybe they could get their email working. it's been hanging, not sending mail, for 4 days, as far my experience has been.
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Elizabeth Zwicky via NANOG
> Sent: Wednesday, July 27, 2016 12:50 PM
> To: Josh Luthman
> Cc: NANOG list
> Subject: Re: Yahoo Postmaster or Email Admin
>
>
> Yes, yes I do.
>
>      On Wednesday, July 27, 2016 9:44 AM, Josh Luthman <josh at imaginenetworksllc.com> wrote:
>   
>
>   Do you mean https://postmaster.yahoo.com/ ?
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
> On Wed, Jul 27, 2016 at 12:39 PM, Elizabeth Zwicky via NANOG <nanog at nanog.org> wrote:
>
> We encourage people to start at https://postmaster.yaho.com but I can help people who have filed tickets there and not had any luck can contact me, specifying a) what IP addresses and From: line they're talking about and b) exactly what error message they are getting when they try to send us mail.
> Elizabeth
> On Wednesday, July 27, 2016, 5:31:55 AM PDT, Mark Stevens <manager at monmouth.com> wrote:Good Morning,
>
> If there is a Yahoo postmaster or email Admin that could contact me
> offline concerning a deferred IP address it would be great.
>
>
> Thanks
>
> Mark
>
>
>
>
>    
>
>


From beecher at beecher.cc  Wed Jul 27 17:14:35 2016
From: beecher at beecher.cc (Tom Beecher)
Date: Wed, 27 Jul 2016 13:14:35 -0400
Subject: Yahoo Postmaster or Email Admin
In-Reply-To: <42265d93-a705-3a9c-86eb-d6f22fa4f893@monmouth.com>
References: <f424f693-e87e-6077-d794-51027aa2b2a2@monmouth.com>
 <519292135.209299.1469637573871.JavaMail.yahoo@mail.yahoo.com>
 <CAN9qwJ-01U=9EmTLHP1A7aLgm2O=y1XPKPab_Ryt102wJHzuig@mail.gmail.com>
 <78239981.209347.1469638199379.JavaMail.yahoo@mail.yahoo.com>
 <a42180f5baa04ee6b57fd3b06568f6ed@nafcmb01.exchange.ford.com>
 <42265d93-a705-3a9c-86eb-d6f22fa4f893@monmouth.com>
Message-ID: <CAL9Qcx4CeeoG8ib0BoP+0MY81kdzeMrXsVCFKquVKbz7CY5E=Q@mail.gmail.com>

To quote Elizabeth...

"but I can help people who have filed tickets there and not had any luck
can contact me, specifying a) what IP addresses and From: line they're
talking about and b) exactly what error message they are getting when they
try to send us mail."

On Wed, Jul 27, 2016 at 1:05 PM, Mark Stevens <manager at monmouth.com> wrote:

> I have been to https://postmaster.yahoo.com and even filled out a bulk
> email form (explained the issue in the notes section) but still no go.
> I even have a ticket opened with their support but you can guess how that
> is going.....
> This is why I asked if anyone has a contact or if in fact a sysadmin @
> yahoo is on nanog and could contact me.
> I will keep working at this, thanks for the info!
>
> Mark
>
>
> On 7/27/2016 12:53 PM, Kain, Rebecca (.) wrote:
>
>> Maybe they could get their email working. it's been hanging, not sending
>> mail, for 4 days, as far my experience has been.
>>
>> -----Original Message-----
>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Elizabeth
>> Zwicky via NANOG
>> Sent: Wednesday, July 27, 2016 12:50 PM
>> To: Josh Luthman
>> Cc: NANOG list
>> Subject: Re: Yahoo Postmaster or Email Admin
>>
>>
>> Yes, yes I do.
>>
>>      On Wednesday, July 27, 2016 9:44 AM, Josh Luthman <
>> josh at imaginenetworksllc.com> wrote:
>>
>>   Do you mean https://postmaster.yahoo.com/ ?
>>
>> Josh Luthman
>> Office: 937-552-2340
>> Direct: 937-552-2343
>> 1100 Wayne St
>> Suite 1337
>> Troy, OH 45373
>> On Wed, Jul 27, 2016 at 12:39 PM, Elizabeth Zwicky via NANOG <
>> nanog at nanog.org> wrote:
>>
>> We encourage people to start at https://postmaster.yaho.com but I can
>> help people who have filed tickets there and not had any luck can contact
>> me, specifying a) what IP addresses and From: line they're talking about
>> and b) exactly what error message they are getting when they try to send us
>> mail.
>> Elizabeth
>> On Wednesday, July 27, 2016, 5:31:55 AM PDT, Mark Stevens <
>> manager at monmouth.com> wrote:Good Morning,
>>
>> If there is a Yahoo postmaster or email Admin that could contact me
>> offline concerning a deferred IP address it would be great.
>>
>>
>> Thanks
>>
>> Mark
>>
>>
>>
>>
>>
>>
>>
>

From rsk at gsp.org  Wed Jul 27 17:16:40 2016
From: rsk at gsp.org (Rich Kulawiec)
Date: Wed, 27 Jul 2016 13:16:40 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
Message-ID: <20160727171640.GA28280@gsp.org>

On Wed, Jul 27, 2016 at 10:37:21AM -0400, Paras Jha wrote:
> From just a preliminary test, more than half of these domains are hiding
> behind Cloudflare, and OVH has a sizable fraction too. I suppose it's
> inevitable, given that both are known for having non-existent abuse
> departments.

Here's the list sorted by DNS provider.  (Of course the DNS provider isn't
necessarily the hoster.)  This list omits domains which don't seem to have
NS records at the moment.

	above.com	bootr.org
	above.com	formalitystresser.com
	above.com	masterboot.net
	above.com	olympusstresser.org
	above.com	renegade-products.net
	above.com	royalbooter.de
	arubadns.cz	hyperstresser.com
	arubadns.net	hyperstresser.com
	axc.nl	umbstresser.net
	bodis.com	vbooter.com
	bookmyname.com	evilbooter.net
	cloudflare.com	alphastress.com
	cloudflare.com	anonymous-stresser.net
	cloudflare.com	aurastresser.com
	cloudflare.com	beststresser.com
	cloudflare.com	boot4free.com
	cloudflare.com	booter.eu
	cloudflare.com	booter.org
	cloudflare.com	booter.xyz
	cloudflare.com	bullstresser.com
	cloudflare.com	buybooters.com
	cloudflare.com	cnstresser.com
	cloudflare.com	connectionstresser.com
	cloudflare.com	crazyamp.me
	cloudflare.com	critical-boot.com
	cloudflare.com	cstress.net
	cloudflare.com	cyberstresser.org
	cloudflare.com	darkstresser.info
	cloudflare.com	darkstresser.net
	cloudflare.com	databooter.com
	cloudflare.com	ddos-fighter.com
	cloudflare.com	ddos-him.com
	cloudflare.com	ddos.city
	cloudflare.com	ddosbreak.com
	cloudflare.com	ddosclub.com
	cloudflare.com	ddostheworld.com
	cloudflare.com	defcon.pro
	cloudflare.com	destressbooter.com
	cloudflare.com	destressnetworks.com
	cloudflare.com	diamond-stresser.net
	cloudflare.com	diebooter.com
	cloudflare.com	diebooter.net
	cloudflare.com	down-stresser.com
	cloudflare.com	downthem.org
	cloudflare.com	exitus.to
	cloudflare.com	exostress.in
	cloudflare.com	free-boot.xyz
	cloudflare.com	freebooter4.me
	cloudflare.com	freestresser.xyz
	cloudflare.com	grimbooter.com
	cloudflare.com	heavystresser.com
	cloudflare.com	hornystress.me
	cloudflare.com	iddos.net
	cloudflare.com	inboot.me
	cloudflare.com	instabooter.com
	cloudflare.com	ipstresser.co
	cloudflare.com	ipstresser.com
	cloudflare.com	jitterstresser.com
	cloudflare.com	k-stress.pw
	cloudflare.com	layer-4.com
	cloudflare.com	layer7.pw
	cloudflare.com	legionboot.com
	cloudflare.com	logicstresser.net
	cloudflare.com	mercilesstresser.com
	cloudflare.com	mystresser.com
	cloudflare.com	netbreak.ec
	cloudflare.com	netspoof.net
	cloudflare.com	networkstresser.com
	cloudflare.com	neverddos.com
	cloudflare.com	nismitstresser.net
	cloudflare.com	onestress.com
	cloudflare.com	onestresser.net
	cloudflare.com	parabooter.com
	cloudflare.com	phoenixstresser.com
	cloudflare.com	pineapple-stresser.com
	cloudflare.com	powerstresser.com
	cloudflare.com	privateroot.fr
	cloudflare.com	purestress.net
	cloudflare.com	quantumbooter.net
	cloudflare.com	quezstresser.com
	cloudflare.com	ragebooter.net
	cloudflare.com	rawlayer.com
	cloudflare.com	reafstresser.ga
	cloudflare.com	restricted-stresser.info
	cloudflare.com	routerslap.com
	cloudflare.com	sharkstresser.com
	cloudflare.com	signalstresser.com
	cloudflare.com	silence-stresser.com
	cloudflare.com	skidbooter.info
	cloudflare.com	spboot.net
	cloudflare.com	stormstresser.net
	cloudflare.com	str3ssed.me
	cloudflare.com	stressboss.net
	cloudflare.com	stresser.club
	cloudflare.com	stresser.in
	cloudflare.com	stresser.network
	cloudflare.com	stresser.ru
	cloudflare.com	stresserit.com
	cloudflare.com	synstress.net
	cloudflare.com	titaniumbooter.net
	cloudflare.com	titaniumstresser.net
	cloudflare.com	topstressers.com
	cloudflare.com	ts3booter.net
	cloudflare.com	unseenbooter.com
	cloudflare.com	vbooter.org
	cloudflare.com	vdos-s.com
	cloudflare.com	webbooter.com
	cloudflare.com	webstresser.co
	cloudflare.com	wifistruggles.com
	cloudflare.com	xboot.net
	cloudflare.com	xr8edstresser.com
	cloudflare.com	xtreme.cc
	cloudflare.com	youboot.net
	cloudns.net	bemybooter.eu
	crazydomains.com	buzzbooter.info
	dnsnuts.com	stagestresser.com
	dnsnuts.com	ufa-booters-tools.com
	domaincontrol.com	ddos.tools
	domaincontrol.com	iridiumstresser.net
	domaincontrol.com	national-stresser.net
	domaincontrol.com	onionstresser.com
	domaincontrol.com	pokent.com
	domaincontrol.com	xenon-stresser.com
	domaindiscover.com	instinctproducts.com
	foundationapi.com	booter.in
	foundationapi.com	mini-booter.com
	free-h.org	darkbooter.fr
	free-h.org	omega-stresser.us
	freenom.com	boot.ml
	freenom.com	kth-stress.tk
	hichina.com	stresser.cc
	hostinger.co.uk	powerdos.co.uk
	hostinger.fi	nuke.pe.hu
	hostnet.nl	darkstresser.nl
	hostnetbv.com	darkstresser.nl
	hostnetbv.nl	darkstresser.nl
	ibspark.com	ddos-ip.com
	ibspark.com	national-stresser.com
	ibspark.com	time-stresser.pw
	kdnetworks.net	stressed.pw
	kirklanddc.com	asylumstresser.com
	myhostadmin.net	battle.pw
	name-services.com	anonymous-stresser.com
	name-services.com	avengestresser.com
	name-services.com	celerystresser.com
	name-services.com	ddosit.net
	name-services.com	ddosit.us
	name-services.com	ddossite.com
	name-services.com	divinestresser.com
	name-services.com	down-stresser.us
	name-services.com	ebolastresser.com
	name-services.com	emaizstresser.net
	name-services.com	exile-stresser.net
	name-services.com	hazebooter.com
	name-services.com	ionbooter.com
	name-services.com	isitdownyet.com
	name-services.com	lifetimeboot.com
	name-services.com	networkstresser.net
	name-services.com	omegastresser.com
	name-services.com	powerstress.com
	name-services.com	stuxstresser.com
	name-services.com	xrshellbooter.com
	name.com	infectedstresser.net
	name.com	netstress.net
	namebrightdns.com	dreamstresser.com
	namebrightdns.com	netspoof.com
	namebrightdns.com	yakuzastresser.com
	namecheaphosting.com	ipstresstest.com
	namecheaphosting.com	respawn.ca
	one.com	equinoxstresser.net
	one.com	riotstresser.com
	one.com	wifistruggles.net
	parkingcrew.net	b-h.us
	parkingcrew.net	buyddos.com
	parkingcrew.net	freezystresser.nl
	parkingcrew.net	getsmack.de
	parkingcrew.net	optimusstresser.com
	parkingcrew.net	stress-me.net
	parkingcrew.net	superstresser.com
	parkingcrew.net	xrstresser.net
	parklogic.com	fagstresser.net
	parktons.com	ddoser.xyz
	registrar-servers.com	anonymousbooter.com
	registrar-servers.com	bigbangbooter.com
	registrar-servers.com	booter.io
	registrar-servers.com	kryptonic.pw
	registrar-servers.com	network-stressing.net
	registrar-servers.com	orcahub.com
	registrar-servers.com	ragebooter.com
	registrar-servers.com	stresser.info
	registrar-servers.com	thestresser.com
	registrar-servers.com,	network-stressing.net
	rentondc.com	cyber-sst.com
	rentondc.com	vdoss.net
	rookdns.com	chargen.cf
	rookdns.com	dejabooter.com
	rookdns.com	emo-stresser.com
	rookdns.com	minecraftstresser.com
	rookdns.com	nightlystresser.ml
	rookdns.com	speed-stresser.com
	rookdns.com	vex-stresser.net
	rookdns.com	xtremebooter.com
	sedoparking.com	booter-sales.hourb.com
	sedoparking.com	stresser.org
	strong-stresser.com	strong-stresser.com
	technorail.com	hyperstresser.com
	tini4u.net	ddos.kr
	udag.de	hydrostress.com
	udag.net	hydrostress.com
	udag.org	hydrostress.com
	ztomy.com	foreverinfamous.com

---rsk

From manager at monmouth.com  Wed Jul 27 17:30:49 2016
From: manager at monmouth.com (Mark Stevens)
Date: Wed, 27 Jul 2016 13:30:49 -0400
Subject: Yahoo Postmaster or Email Admin
In-Reply-To: <519292135.209299.1469637573871.JavaMail.yahoo@mail.yahoo.com>
References: <f424f693-e87e-6077-d794-51027aa2b2a2@monmouth.com>
 <519292135.209299.1469637573871.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <683d1258-6e22-3637-c1cf-76de03c36860@monmouth.com>

Thanks Elizabeth,

I sent you a direct email with what you need to (hopefully) assist me.


Thanks

Mark

On 7/27/2016 12:39 PM, Elizabeth Zwicky wrote:
> We encourage people to start at https://postmaster.yaho.com but I can 
> help people who have filed tickets there and not had any luck can 
> contact me, specifying a) what IP addresses and From: line they're 
> talking about and b) exactly what error message they are getting when 
> they try to send us mail.
>
> Elizabeth
>
> On Wednesday, July 27, 2016, 5:31:55 AM PDT, Mark Stevens 
> <manager at monmouth.com> wrote:
> Good Morning,
>
> If there is a Yahoo postmaster or email Admin that could contact me
> offline concerning a deferred IP address it would be great.
>
>
> Thanks
>
> Mark


From morrowc.lists at gmail.com  Wed Jul 27 17:35:09 2016
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 27 Jul 2016 13:35:09 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <CAJayEpFyP5NVsST4y5qSep-uJK7eXjaLXGWzVotVwX1pQ1cZ+Q@mail.gmail.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <CABC6K15-1Vb7C9g_JDfsgGT0QSU7vtEhWfb9Bv3cMyhR8iURmA@mail.gmail.com>
 <CAJayEpFyP5NVsST4y5qSep-uJK7eXjaLXGWzVotVwX1pQ1cZ+Q@mail.gmail.com>
Message-ID: <CAL9jLaYY05zxfPPEJBKZtyJVwQg5s+b9wBgJ-i_CS8druc4_9Q@mail.gmail.com>

On Wed, Jul 27, 2016 at 10:58 AM, Paras Jha <paras at protrafsolutions.com>
wrote:

> I consistently did not even get replies


This is a common 'complaint' point for abuse senders. I often wonder why.
What is a reply supposed to do or tell you?

From math at sizone.org  Wed Jul 27 17:39:44 2016
From: math at sizone.org (Ken Chase)
Date: Wed, 27 Jul 2016 13:39:44 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <CAL9jLaYY05zxfPPEJBKZtyJVwQg5s+b9wBgJ-i_CS8druc4_9Q@mail.gmail.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <CABC6K15-1Vb7C9g_JDfsgGT0QSU7vtEhWfb9Bv3cMyhR8iURmA@mail.gmail.com>
 <CAJayEpFyP5NVsST4y5qSep-uJK7eXjaLXGWzVotVwX1pQ1cZ+Q@mail.gmail.com>
 <CAL9jLaYY05zxfPPEJBKZtyJVwQg5s+b9wBgJ-i_CS8druc4_9Q@mail.gmail.com>
Message-ID: <20160727173944.GE10766@sizone.org>

Because replying admits knowledge and creates a papertrail thereof. Esp.
w.r.t. copyright infringement takedown notices etc.

(or also because said providers are innundated with such requests because they
don't actually care as it's all part of their profit centre.)

/kc


On Wed, Jul 27, 2016 at 01:35:09PM -0400, Christopher Morrow said:
  >On Wed, Jul 27, 2016 at 10:58 AM, Paras Jha <paras at protrafsolutions.com>
  >wrote:
  >
  >> I consistently did not even get replies
  >
  >
  >This is a common 'complaint' point for abuse senders. I often wonder why.
  >What is a reply supposed to do or tell you?

-- 
Ken Chase - math at sizone.org 


From bzs at theworld.com  Wed Jul 27 17:53:33 2016
From: bzs at theworld.com (bzs at theworld.com)
Date: Wed, 27 Jul 2016 13:53:33 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <317C533A-2373-4B06-8A98-6BA10547E8C2@blighty.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <317C533A-2373-4B06-8A98-6BA10547E8C2@blighty.com>
Message-ID: <22424.62749.69727.250895@gargle.gargle.HOWL>


This is why policy, as painful as it is to produce, is useful.

There isn't even general agreement on whether (or what!) Cloudfare is
doing is a problem.

Which is why interested parties need to get together and agree on some
sort of policy regarding this and similar things.

Or not and just let it go.

That policy could, at least in theory, be attached to peering
agreements, BGP agreements, address allocations, etc as contracts as a
means of enforcement. And if necessary presented to law enforcement or
courts as clearly defined violations of GAAP.

It may not be a law per se but it's the sort of thing a court case
might use, say in a civil damages suit or even law enforcement action,
to establish that defendant's behavior exhibited reckless disregard
and so on.

As an analogy you can't accuse someone of mayhem if no one can be
bothered to write down what mayhem might be and why the defendant
should have known their actions were mayhemic.

-- 
        -Barry Shein

Software Tool & Die    | bzs at TheWorld.com             | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

From dhubbard at dino.hostasaurus.com  Wed Jul 27 18:16:27 2016
From: dhubbard at dino.hostasaurus.com (David Hubbard)
Date: Wed, 27 Jul 2016 18:16:27 +0000
Subject: Operations task management software?
Message-ID: <51622BA9-0A59-4E0C-B5CB-518D53015D33@dino.hostasaurus.com>

Hi all, curious if anyone has recommendations on software that helps manage routine duties assigned to operations staff?

For example, let?s say we have a P&P that says someone from the netops group must check that Rancid is successfully backing up all router configs bi-weekly.  Ideally, it would send an email reminder to this pre-defined group of people saying hey, it?s Monday, someone needs to check this and come acknowledge the task as having been completed.  If that doesn?t occur, pre-defined manager X is notified on Tuesday.  If manager X doesn?t get someone to complete the task, director Y is notified, so on and so forth.  Then, perhaps periodically it emails manager X anyway and says hey, it?s been three months, you need to audit netops to ensure they?re actually doing the Rancid audit and not just checking that it was done.  This could be applied to the staff who check on backup failures, backup internet circuit status, out of band interfaces, etc.

A data center I looked at recently had QR code stickers on all of their infrastructure stuff and there were staff assigned to check and log certain displayed values each day.  The software would at least ensure they actually visited the equipment by requiring they scan the relevant QR code when in front of it.  So I figure something that does what I?m looking for properly already exists.

Thanks,

David


From goemon at sasami.anime.net  Wed Jul 27 18:21:02 2016
From: goemon at sasami.anime.net (Dan Hollis)
Date: Wed, 27 Jul 2016 11:21:02 -0700 (PDT)
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <22424.62749.69727.250895@gargle.gargle.HOWL>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <317C533A-2373-4B06-8A98-6BA10547E8C2@blighty.com>
 <22424.62749.69727.250895@gargle.gargle.HOWL>
Message-ID: <Pine.LNX.4.64.1607271119390.20298@yuri.anime.net>

On Wed, 27 Jul 2016, bzs at theworld.com wrote:
> There isn't even general agreement on whether (or what!) Cloudfare is
> doing is a problem.

aiding and abetting. at the very least willful negligence.

-Dan

From ops.lists at gmail.com  Wed Jul 27 18:24:30 2016
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Wed, 27 Jul 2016 23:54:30 +0530
Subject: Operations task management software?
In-Reply-To: <51622BA9-0A59-4E0C-B5CB-518D53015D33@dino.hostasaurus.com>
References: <51622BA9-0A59-4E0C-B5CB-518D53015D33@dino.hostasaurus.com>
Message-ID: <24ECECE6-90EA-4EDB-9CB0-36FDB7CF9FE2@gmail.com>

Been meaning to dig into this one https://www.upguard.com/blog/guardrail-tasks-a-lightweight-tracking-system-for-ops

--srs

> On 27-Jul-2016, at 11:46 PM, David Hubbard <dhubbard at dino.hostasaurus.com> wrote:
> 
> Hi all, curious if anyone has recommendations on software that helps manage routine duties assigned to operations staff?
> 
> For example, let?s say we have a P&P that says someone from the netops group must check that Rancid is successfully backing up all router configs bi-weekly.  Ideally, it would send an email reminder to this pre-defined group of people saying hey, it?s Monday, someone needs to check this and come acknowledge the task as having been completed.  If that doesn?t occur, pre-defined manager X is notified on Tuesday.  If manager X doesn?t get someone to complete the task, director Y is notified, so on and so forth.  Then, perhaps periodically it emails manager X anyway and says hey, it?s been three months, you need to audit netops to ensure they?re actually doing the Rancid audit and not just checking that it was done.  This could be applied to the staff who check on backup failures, backup internet circuit status, out of band interfaces, etc.
> 
> A data center I looked at recently had QR code stickers on all of their infrastructure stuff and there were staff assigned to check and log certain displayed values each day.  The software would at least ensure they actually visited the equipment by requiring they scan the relevant QR code when in front of it.  So I figure something that does what I?m looking for properly already exists.
> 
> Thanks,
> 
> David
> 

From niels=nanog at bakker.net  Wed Jul 27 18:26:29 2016
From: niels=nanog at bakker.net (niels=nanog at bakker.net)
Date: Wed, 27 Jul 2016 20:26:29 +0200
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <Pine.LNX.4.64.1607271119390.20298@yuri.anime.net>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <317C533A-2373-4B06-8A98-6BA10547E8C2@blighty.com>
 <22424.62749.69727.250895@gargle.gargle.HOWL>
 <Pine.LNX.4.64.1607271119390.20298@yuri.anime.net>
Message-ID: <20160727182629.GD3955@excession.tpb.net>

* goemon at sasami.anime.net (Dan Hollis) [Wed 27 Jul 2016, 20:21 CEST]:
>On Wed, 27 Jul 2016, bzs at theworld.com wrote:
>>There isn't even general agreement on whether (or what!) Cloudfare 
>>is doing is a problem.
>
>aiding and abetting. at the very least willful negligence.

I hope the armchairs y'all are lawyering from are comfortable


	-- Niels.

From justin at cloudflare.com  Wed Jul 27 14:44:52 2016
From: justin at cloudflare.com (Justin Paine)
Date: Wed, 27 Jul 2016 07:44:52 -0700
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
Message-ID: <CABC6K15-1Vb7C9g_JDfsgGT0QSU7vtEhWfb9Bv3cMyhR8iURmA@mail.gmail.com>

Hi Paras,

I covered the booter topic in a previous reply on a different (though
basically the same) thread. By "non-existent" you mean we are
processing thousands of reports per week. If you have something to
report you can certainly do so at cloudflare.com/abuse. We'd be more
than happy to process your report also.

Thanks,
Justin

____________
Justin Paine
Head of Trust & Safety
CloudFlare Inc.
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D


On Wed, Jul 27, 2016 at 7:37 AM, Paras Jha <paras at protrafsolutions.com> wrote:
> Hi Jair,
>
> This list is really interesting.
>
> From just a preliminary test, more than half of these domains are hiding
> behind Cloudflare, and OVH has a sizable fraction too. I suppose it's
> inevitable, given that both are known for having non-existent abuse
> departments.
>
> Regards
>
> On Wed, Jul 27, 2016 at 9:49 AM, Jair Santanna <j.j.santanna at utwente.nl>
> wrote:
>
>> Hi folks,
>>
>> A friend forward me your topic about Booters and CloudFlare. Then I
>> decided to join the NANOG list. The *answer* for the first question about
>> CloudFlare and Booters is at: https://www.youtube.com/watch?v=wW5vJyI_HcU
>> (minute 45:55) given by the _CloudFlare CEO_ in the blackhat2013.
>>
>> I investigate Booters since 2013 and I know many (if not all) the possible
>> aspects about this DDoS-as-a-Service phenomenon. A summary of my entire
>> research (or large part of that) can be watched at
>> https://tnc16.geant.org/web/media/archive/3A (from minute 22:53). On top
>> of that, I developed an algorithm to find Booters and publicly share such
>> list (http://booterblacklist.com/). My main goal with this initiative is
>> to convince people to blacklist and keep on track the users that access
>> Booters (that potentially perform attacks)
>>
>> If you have any question about any aspect of the entire phenomenon don't
>> hesitate to contact me. By the way, I want to help deploy the booters
>> blacklist worldwide and help prosecutors to shutdown this bastards. I have
>> many evidences!
>>
>> Cheers,
>>
>> Jair Santanna
>> jairsantanna.com
>>
>>
>>
>>
>
>
> --
> Regards,
> Paras
>
> President
> ProTraf Solutions, LLC
> Enterprise DDoS Mitigation

From justin at cloudflare.com  Wed Jul 27 17:03:19 2016
From: justin at cloudflare.com (Justin Paine)
Date: Wed, 27 Jul 2016 10:03:19 -0700
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <317C533A-2373-4B06-8A98-6BA10547E8C2@blighty.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <317C533A-2373-4B06-8A98-6BA10547E8C2@blighty.com>
Message-ID: <CABC6K14GvB+EdbSwAAeRNuZS1D4XRy6mja3Nw4W35WdxNFkcyA@mail.gmail.com>

Law enforcement (US or international) knows how to contact us if they
have an inquiry to make. We also publish a Transparency
Report that covers those legal inquiries:
https://www.cloudflare.com/transparency/

____________
Justin Paine
Head of Trust & Safety
CloudFlare Inc.
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D


On Wed, Jul 27, 2016 at 9:32 AM, Steve Atkins <steve at blighty.com> wrote:
>
>> On Jul 27, 2016, at 9:17 AM, Baldur Norddahl <baldur.norddahl at gmail.com> wrote:
>>
>> Den 27. jul. 2016 17.12 skrev "Steve Mikulasik" <Steve.Mikulasik at civeo.com>:
>>>
>>> Disclaimer: I have a ton of respect for Clouldflare and what they do on
>> the internet.
>>
>> They just lost all respect from here. Would someone from USA please report
>> these guys to the feds? What they are doing is outright criminal.
>
> They can monitor (passively or actively) all access to the sites they host, even
> the ones that use SSL, and they often use their close working relationship with
> law enforcement to explain why they don't terminate bad actors on their network.
>
> You can probably assume that "the feds" are intimately aware of what they're doing.
>
> Cheers,
>   Steve
>

From justin at cloudflare.com  Wed Jul 27 17:41:48 2016
From: justin at cloudflare.com (Justin Paine)
Date: Wed, 27 Jul 2016 10:41:48 -0700
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <CAL9jLaYY05zxfPPEJBKZtyJVwQg5s+b9wBgJ-i_CS8druc4_9Q@mail.gmail.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <CABC6K15-1Vb7C9g_JDfsgGT0QSU7vtEhWfb9Bv3cMyhR8iURmA@mail.gmail.com>
 <CAJayEpFyP5NVsST4y5qSep-uJK7eXjaLXGWzVotVwX1pQ1cZ+Q@mail.gmail.com>
 <CAL9jLaYY05zxfPPEJBKZtyJVwQg5s+b9wBgJ-i_CS8druc4_9Q@mail.gmail.com>
Message-ID: <CABC6K14iTfpJw=XemVYqMN0-B_F=bF-fe0kJ+0_qOn1Fnw6n_w@mail.gmail.com>

>From our side:

 abuse@ reports generates an auto reply indicating where our reporting
form is located.

Reports at our reporting form generate an auto reply confirming we
received the report. All reports filed via the form are reviewed by a
human and at a minimum passed on to
the responsible hosting provider so they are aware and they can follow their
policies to address with their customer.

____________
Justin Paine
Head of Trust & Safety
CloudFlare Inc.
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D


On Wed, Jul 27, 2016 at 10:35 AM, Christopher Morrow
<morrowc.lists at gmail.com> wrote:
>
> On Wed, Jul 27, 2016 at 10:58 AM, Paras Jha <paras at protrafsolutions.com>
> wrote:
>>
>> I consistently did not even get replies
>
>
> This is a common 'complaint' point for abuse senders. I often wonder why.
> What is a reply supposed to do or tell you?

From edugas at unknowndevice.ca  Wed Jul 27 20:46:58 2016
From: edugas at unknowndevice.ca (Eric Dugas)
Date: Wed, 27 Jul 2016 16:46:58 -0400
Subject: Yellow Pages - YP.ca sys/net admins
Message-ID: <CALKrK4=kEHLaUKH=jBEzSRdVpj4zSHJk0XD5+5FSm9C+f2_+YQ@mail.gmail.com>

Hello,

Just trying to reach a clueful system or network admins from Yellow Pages.

You can contact me off-list.

Eric

From ler762 at gmail.com  Wed Jul 27 23:19:45 2016
From: ler762 at gmail.com (Lee)
Date: Wed, 27 Jul 2016 19:19:45 -0400
Subject: Operations task management software?
In-Reply-To: <51622BA9-0A59-4E0C-B5CB-518D53015D33@dino.hostasaurus.com>
References: <51622BA9-0A59-4E0C-B5CB-518D53015D33@dino.hostasaurus.com>
Message-ID: <CAD8GWssb8cVy=ExG2zv4ys9QcY+FPyytWOhBLgjPu+gdncGbiw@mail.gmail.com>

On 7/27/16, David Hubbard <dhubbard at dino.hostasaurus.com> wrote:
> Hi all, curious if anyone has recommendations on software that helps manage
> routine duties assigned to operations staff?

Have computers do the routine scut work - not people.

> For example, let?s say we have a P&P that says someone from the netops group
> must check that Rancid is successfully backing up all router configs
> bi-weekly.

You've got the source code for rancid, so change rancid-run to do something like
  LOGFILE=$LOGDIR/$GROUP.`date +%Y%m%d.%H%M%S`; export LOGFILE
change the
  ) >$LOGDIR/$GROUP.`date +%Y%m%d.%H%M%S` 2>&1
to
  ) >$LOGFILE 2>&1

and then in control_rancid do something like
  grep "clogin error:" $LOGFILE | sort | uniq -c >$TMP.fail
  if [ -s $TMP.fail ]; then
     # got some output, mail the report
     ...

Do the same type thing for checking on
> backup failures, backup internet circuit status, out of band interfaces, etc.

Automate the checks, put the scripts in crontab & mail out an
"OhNoes!" or "all clear" msg at the end.   At which point you're left
with the problem of making sure the managers are looking at the emails
& making sure whatever problems are found actually get fixed :)

Regards,
Lee



>  Ideally, it would send an email reminder to this pre-defined
> group of people saying hey, it?s Monday, someone needs to check this and
> come acknowledge the task as having been completed.  If that doesn?t occur,
> pre-defined manager X is notified on Tuesday.  If manager X doesn?t get
> someone to complete the task, director Y is notified, so on and so forth.
> Then, perhaps periodically it emails manager X anyway and says hey, it?s
> been three months, you need to audit netops to ensure they?re actually doing
> the Rancid audit and not just checking that it was done.  This could be
> applied to the staff who check on backup failures, backup internet circuit
> status, out of band interfaces, etc.
>
> A data center I looked at recently had QR code stickers on all of their
> infrastructure stuff and there were staff assigned to check and log certain
> displayed values each day.  The software would at least ensure they actually
> visited the equipment by requiring they scan the relevant QR code when in
> front of it.  So I figure something that does what I?m looking for properly
> already exists.
>
> Thanks,
>
> David
>

From dhubbard at dino.hostasaurus.com  Wed Jul 27 23:27:23 2016
From: dhubbard at dino.hostasaurus.com (David Hubbard)
Date: Wed, 27 Jul 2016 23:27:23 +0000
Subject: Operations task management software?
In-Reply-To: <CAD8GWssb8cVy=ExG2zv4ys9QcY+FPyytWOhBLgjPu+gdncGbiw@mail.gmail.com>
References: <51622BA9-0A59-4E0C-B5CB-518D53015D33@dino.hostasaurus.com>
 <CAD8GWssb8cVy=ExG2zv4ys9QcY+FPyytWOhBLgjPu+gdncGbiw@mail.gmail.com>
Message-ID: <712E5359-5217-41AA-A779-F13DCE597537@dino.hostasaurus.com>

Full automation is planned but does not eliminate the need for the software.  Zero human auditing of fully automated processes and data collection are not acceptable to various certifying entities, the relevant auditors, the inevitably involved lawyers, and won?t pick up on bad data, like a bad thermometer or snmp counter that says a CRAC is 65 degrees when it?s really 90.  So I?m still going to need a management solution to the issue whether it?s to tell someone to do the work or to tell someone to check the automated work.

David

On 7/27/16, 7:19 PM, "Lee" <ler762 at gmail.com> wrote:

    On 7/27/16, David Hubbard <dhubbard at dino.hostasaurus.com> wrote:
    > Hi all, curious if anyone has recommendations on software that helps manage
    > routine duties assigned to operations staff?
    
    Have computers do the routine scut work - not people.
    
    > For example, let?s say we have a P&P that says someone from the netops group
    > must check that Rancid is successfully backing up all router configs
    > bi-weekly.
    
    You've got the source code for rancid, so change rancid-run to do something like
      LOGFILE=$LOGDIR/$GROUP.`date +%Y%m%d.%H%M%S`; export LOGFILE
    change the
      ) >$LOGDIR/$GROUP.`date +%Y%m%d.%H%M%S` 2>&1
    to
      ) >$LOGFILE 2>&1
    
    and then in control_rancid do something like
      grep "clogin error:" $LOGFILE | sort | uniq -c >$TMP.fail
      if [ -s $TMP.fail ]; then
         # got some output, mail the report
         ...
    
    Do the same type thing for checking on
    > backup failures, backup internet circuit status, out of band interfaces, etc.
    
    Automate the checks, put the scripts in crontab & mail out an
    "OhNoes!" or "all clear" msg at the end.   At which point you're left
    with the problem of making sure the managers are looking at the emails
    & making sure whatever problems are found actually get fixed :)
    
    Regards,
    Lee
 


From ler762 at gmail.com  Thu Jul 28 00:20:29 2016
From: ler762 at gmail.com (Lee)
Date: Wed, 27 Jul 2016 20:20:29 -0400
Subject: Operations task management software?
In-Reply-To: <712E5359-5217-41AA-A779-F13DCE597537@dino.hostasaurus.com>
References: <51622BA9-0A59-4E0C-B5CB-518D53015D33@dino.hostasaurus.com>
 <CAD8GWssb8cVy=ExG2zv4ys9QcY+FPyytWOhBLgjPu+gdncGbiw@mail.gmail.com>
 <712E5359-5217-41AA-A779-F13DCE597537@dino.hostasaurus.com>
Message-ID: <CAD8GWsuOFmVh4BX8MPnpKWokxo10h7RMK3_vYeJ4ZnisRTS49w@mail.gmail.com>

On 7/27/16, David Hubbard <dhubbard at dino.hostasaurus.com> wrote:
> Full automation is planned but does not eliminate the need for the software.
>  Zero human auditing of fully automated processes and data collection are
> not acceptable to various certifying entities, the relevant auditors, the
> inevitably involved lawyers, and won?t pick up on bad data, like a bad
> thermometer or snmp counter that says a CRAC is 65 degrees when it?s really
> 90.  So I?m still going to need a management solution to the issue whether
> it?s to tell someone to do the work or to tell someone to check the
> automated work.

You have a ticketing system - right?  Create a cron job that creates a
ticket to check whatever.

Regards,
Lee


>
> David
>
> On 7/27/16, 7:19 PM, "Lee" <ler762 at gmail.com> wrote:
>
>     On 7/27/16, David Hubbard <dhubbard at dino.hostasaurus.com> wrote:
>     > Hi all, curious if anyone has recommendations on software that helps
> manage
>     > routine duties assigned to operations staff?
>
>     Have computers do the routine scut work - not people.
>
>     > For example, let?s say we have a P&P that says someone from the netops
> group
>     > must check that Rancid is successfully backing up all router configs
>     > bi-weekly.
>
>     You've got the source code for rancid, so change rancid-run to do
> something like
>       LOGFILE=$LOGDIR/$GROUP.`date +%Y%m%d.%H%M%S`; export LOGFILE
>     change the
>       ) >$LOGDIR/$GROUP.`date +%Y%m%d.%H%M%S` 2>&1
>     to
>       ) >$LOGFILE 2>&1
>
>     and then in control_rancid do something like
>       grep "clogin error:" $LOGFILE | sort | uniq -c >$TMP.fail
>       if [ -s $TMP.fail ]; then
>          # got some output, mail the report
>          ...
>
>     Do the same type thing for checking on
>     > backup failures, backup internet circuit status, out of band
> interfaces, etc.
>
>     Automate the checks, put the scripts in crontab & mail out an
>     "OhNoes!" or "all clear" msg at the end.   At which point you're left
>     with the problem of making sure the managers are looking at the emails
>     & making sure whatever problems are found actually get fixed :)
>
>     Regards,
>     Lee
>
>
>

From Valdis.Kletnieks at vt.edu  Thu Jul 28 00:33:51 2016
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 27 Jul 2016 20:33:51 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <Pine.LNX.4.64.1607271119390.20298@yuri.anime.net>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <317C533A-2373-4B06-8A98-6BA10547E8C2@blighty.com>
 <22424.62749.69727.250895@gargle.gargle.HOWL>
 <Pine.LNX.4.64.1607271119390.20298@yuri.anime.net>
Message-ID: <23235.1469666031@turing-police.cc.vt.edu>

On Wed, 27 Jul 2016 11:21:02 -0700, Dan Hollis said:
> On Wed, 27 Jul 2016, bzs at theworld.com wrote:
> > There isn't even general agreement on whether (or what!) Cloudfare is
> > doing is a problem.
>
> aiding and abetting. at the very least willful negligence.

aiding and abetting of what, *exactly*?  You can't accuse somebody of
it until (as Barry Shein pointed out) you have a workable definition of
what exactly you're talking about.  Similarly, "willful negligence" in most
places requires you to draw a dotted line between the alleged negligent
action, and some claimed damage or loss on your part - of a form that
a court can provide a remedy for.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160727/f7f8b79a/attachment.pgp>

From marka at isc.org  Thu Jul 28 00:48:47 2016
From: marka at isc.org (Mark Andrews)
Date: Thu, 28 Jul 2016 10:48:47 +1000
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: Your message of "Wed, 27 Jul 2016 20:33:51 -0400."
 <23235.1469666031@turing-police.cc.vt.edu>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <317C533A-2373-4B06-8A98-6BA10547E8C2@blighty.com>
 <22424.62749.69727.250895@gargle.gargle.HOWL>
 <Pine.LNX.4.64.1607271119390.20298@yuri.anime.net>
 <23235.1469666031@turing-police.cc.vt.edu>
Message-ID: <20160728004847.216944F976B0@rock.dv.isc.org>


In message <23235.1469666031 at turing-police.cc.vt.edu>, Valdis.Kletnieks at vt.edu 
writes:
> On Wed, 27 Jul 2016 11:21:02 -0700, Dan Hollis said:
> > On Wed, 27 Jul 2016, bzs at theworld.com wrote:
> > > There isn't even general agreement on whether (or what!) Cloudfare is
> > > doing is a problem.
> >
> > aiding and abetting. at the very least willful negligence.
> 
> aiding and abetting of what, *exactly*?  You can't accuse somebody of
> it until (as Barry Shein pointed out) you have a workable definition of
> what exactly you're talking about.  Similarly, "willful negligence" in most
> places requires you to draw a dotted line between the alleged negligent
> action, and some claimed damage or loss on your part - of a form that
> a court can provide a remedy for.

As soon as a transaction takes place, conspiricy to harm <X> by
<Y>.  If the DoS actually occurs you can add additional charges for
the actual actions.

This is no different conceptually to hiring a thug to take a baseball
bat to a place.  You can be charged for consipiricy to commit a
crime even if the crime does not occur.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

From Valdis.Kletnieks at vt.edu  Thu Jul 28 01:01:21 2016
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 27 Jul 2016 21:01:21 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <20160728004847.216944F976B0@rock.dv.isc.org>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <317C533A-2373-4B06-8A98-6BA10547E8C2@blighty.com>
 <22424.62749.69727.250895@gargle.gargle.HOWL>
 <Pine.LNX.4.64.1607271119390.20298@yuri.anime.net>
 <23235.1469666031@turing-police.cc.vt.edu>
 <20160728004847.216944F976B0@rock.dv.isc.org>
Message-ID: <31450.1469667681@turing-police.cc.vt.edu>

On Thu, 28 Jul 2016 10:48:47 +1000, Mark Andrews said:

> As soon as a transaction takes place, conspiricy to harm <X> by
> <Y>.  If the DoS actually occurs you can add additional charges for
> the actual actions.

If the claim is that a law has been broken, you have to show that <Y> is
actually a crime in the jurisdiction involved.  If it's a civil claim, in
general only <X> will have standing to actually file suit.  That's a big chunk
of the problem - the gamer who ticked off another gamer and got DDoSed doesn't
have the knowledge, time, or resources to file a claim that will actually
accomplish anything, and nobody else can file the claim on their behalf.

> This is no different conceptually to hiring a thug to take a baseball
> bat to a place.  You can be charged for consipiricy to commit a
> crime even if the crime does not occur.

Bringing a baseball bat to a place isn't usually in and of itself
illegal. Thug A may bring a bat to someplace, but absent evidence that
Thug B will then use said bat for nefarious purposes, you're still left
with nothing. You have to draw *all* the dots, Mark. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160727/68c6a8b5/attachment.pgp>

From marka at isc.org  Thu Jul 28 01:34:00 2016
From: marka at isc.org (Mark Andrews)
Date: Thu, 28 Jul 2016 11:34:00 +1000
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: Your message of "Wed, 27 Jul 2016 21:01:21 -0400."
 <31450.1469667681@turing-police.cc.vt.edu>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <317C533A-2373-4B06-8A98-6BA10547E8C2@blighty.com>
 <22424.62749.69727.250895@gargle.gargle.HOWL>
 <Pine.LNX.4.64.1607271119390.20298@yuri.anime.net>
 <23235.1469666031@turing-police.cc.vt.edu>
 <20160728004847.216944F976B0@rock.dv.isc.org>
 <31450.1469667681@turing-police.cc.vt.edu>
Message-ID: <20160728013400.9157B4F97B83@rock.dv.isc.org>


In message <31450.1469667681 at turing-police.cc.vt.edu>, Valdis.Kletnieks at vt.edu 
writes:
> On Thu, 28 Jul 2016 10:48:47 +1000, Mark Andrews said:
> 
> > As soon as a transaction takes place, conspiricy to harm <X> by
> > <Y>.  If the DoS actually occurs you can add additional charges for
> > the actual actions.
> 
> If the claim is that a law has been broken, you have to show that <Y> is
> actually a crime in the jurisdiction involved.  If it's a civil claim, in
> general only <X> will have standing to actually file suit.  That's a big chun
> k
> of the problem - the gamer who ticked off another gamer and got DDoSed doesn'
> t
> have the knowledge, time, or resources to file a claim that will actually
> accomplish anything, and nobody else can file the claim on their behalf.

There have always been plenty of laws to cover DoS attacks.  You
don't need "with a computer" in the law.  You just need to apply
existing laws.

> > This is no different conceptually to hiring a thug to take a baseball
> > bat to a place.  You can be charged for consipiricy to commit a
> > crime even if the crime does not occur.
> 
> Bringing a baseball bat to a place isn't usually in and of itself
> illegal. Thug A may bring a bat to someplace, but absent evidence that
> Thug B will then use said bat for nefarious purposes, you're still left
> with nothing. You have to draw *all* the dots, Mark. :)

It's the hiring that triggers the conspircy.  The crime has been
committed the moment there is agreement to perform the act.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

From paras at protrafsolutions.com  Thu Jul 28 02:04:38 2016
From: paras at protrafsolutions.com (Paras Jha)
Date: Wed, 27 Jul 2016 22:04:38 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <20160728013400.9157B4F97B83@rock.dv.isc.org>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <317C533A-2373-4B06-8A98-6BA10547E8C2@blighty.com>
 <22424.62749.69727.250895@gargle.gargle.HOWL>
 <Pine.LNX.4.64.1607271119390.20298@yuri.anime.net>
 <23235.1469666031@turing-police.cc.vt.edu>
 <20160728004847.216944F976B0@rock.dv.isc.org>
 <31450.1469667681@turing-police.cc.vt.edu>
 <20160728013400.9157B4F97B83@rock.dv.isc.org>
Message-ID: <CAJayEpF+EbuADB-Rr_yYdAXjHvq00M7b2yow2nh9XZ-TfZG3ww@mail.gmail.com>

He's right, conspiracy to commit X is a valid criminal charge, at least in
the US. Conspiracy to commit fraud, theft, murder, racketeering, etc are
all "sister charges" of charges of ones actually carried out.

From paras at protrafsolutions.com  Thu Jul 28 02:07:39 2016
From: paras at protrafsolutions.com (Paras Jha)
Date: Wed, 27 Jul 2016 22:07:39 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <CAJayEpF+EbuADB-Rr_yYdAXjHvq00M7b2yow2nh9XZ-TfZG3ww@mail.gmail.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <317C533A-2373-4B06-8A98-6BA10547E8C2@blighty.com>
 <22424.62749.69727.250895@gargle.gargle.HOWL>
 <Pine.LNX.4.64.1607271119390.20298@yuri.anime.net>
 <23235.1469666031@turing-police.cc.vt.edu>
 <20160728004847.216944F976B0@rock.dv.isc.org>
 <31450.1469667681@turing-police.cc.vt.edu>
 <20160728013400.9157B4F97B83@rock.dv.isc.org>
 <CAJayEpF+EbuADB-Rr_yYdAXjHvq00M7b2yow2nh9XZ-TfZG3ww@mail.gmail.com>
Message-ID: <CAJayEpEgXyCvMhMCF7m7XspAqq3U90TS+05LEk+zRt_7B2oH2Q@mail.gmail.com>

I am not a lawyer and I don't pretend to be, but I believe

> the gamer who ticked off another gamer and got DDoSed doesn't
> have the knowledge, time, or resources to file a claim that will actually
> accomplish anything, and nobody else can file the claim on their behalf.

I believe a class action lawsuit would sidestep this. Don't quote me on
that though, I may be wrong.

On Wed, Jul 27, 2016 at 10:04 PM, Paras Jha <paras at protrafsolutions.com>
wrote:

> He's right, conspiracy to commit X is a valid criminal charge, at least in
> the US. Conspiracy to commit fraud, theft, murder, racketeering, etc are
> all "sister charges" of charges of ones actually carried out.
>



-- 
Regards,
Paras

President
ProTraf Solutions, LLC
Enterprise DDoS Mitigation

From randy at psg.com  Thu Jul 28 02:48:01 2016
From: randy at psg.com (Randy Bush)
Date: Thu, 28 Jul 2016 11:48:01 +0900
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
Message-ID: <m2k2g61nry.wl%randy@psg.com>

> They just lost all respect from here. Would someone from USA please
> report these guys to the feds? What they are doing is outright
> criminal.

hyperbole.  it is not criminal.  you just don't happen to like it.

From mfidelman at meetinghouse.net  Thu Jul 28 02:55:54 2016
From: mfidelman at meetinghouse.net (Miles Fidelman)
Date: Wed, 27 Jul 2016 22:55:54 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <m2k2g61nry.wl%randy@psg.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
Message-ID: <b0fe8104-ff68-e18d-c738-944fbb515d91@meetinghouse.net>



On 7/27/16 10:48 PM, Randy Bush wrote:
>> They just lost all respect from here. Would someone from USA please
>> report these guys to the feds? What they are doing is outright
>> criminal.
> hyperbole.  it is not criminal.  you just don't happen to like it.

Actually, as someone pointed out, it might well be conspiracy - which is 
criminal.

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra


From morrowc.lists at gmail.com  Thu Jul 28 03:11:33 2016
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 28 Jul 2016 04:11:33 +0100
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <b0fe8104-ff68-e18d-c738-944fbb515d91@meetinghouse.net>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <b0fe8104-ff68-e18d-c738-944fbb515d91@meetinghouse.net>
Message-ID: <CAL9jLaZ3jAGESfdLe1O-FKsXuOptsZKLO4oSe1cEEbjY9RPgJA@mail.gmail.com>

On Thu, Jul 28, 2016 at 3:55 AM, Miles Fidelman <mfidelman at meetinghouse.net>
wrote:

>
>
> On 7/27/16 10:48 PM, Randy Bush wrote:
>
>> They just lost all respect from here. Would someone from USA please
>>> report these guys to the feds? What they are doing is outright
>>> criminal.
>>>
>> hyperbole.  it is not criminal.  you just don't happen to like it.
>>
>
> Actually, as someone pointed out, it might well be conspiracy - which is
> criminal.


looking forward to the court case, if it's really important it'll happen
shortly, right?

From Valdis.Kletnieks at vt.edu  Thu Jul 28 09:30:13 2016
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 28 Jul 2016 05:30:13 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <b0fe8104-ff68-e18d-c738-944fbb515d91@meetinghouse.net>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <b0fe8104-ff68-e18d-c738-944fbb515d91@meetinghouse.net>
Message-ID: <17158.1469698213@turing-police.cc.vt.edu>

On Wed, 27 Jul 2016 22:55:54 -0400, Miles Fidelman said:
> On 7/27/16 10:48 PM, Randy Bush wrote:
> >> They just lost all respect from here. Would someone from USA please
> >> report these guys to the feds? What they are doing is outright
> >> criminal.
> > hyperbole.  it is not criminal.  you just don't happen to like it.
>
> Actually, as someone pointed out, it might well be conspiracy - which is
> criminal.

In general, the conspiracy isn't criminal if the conspired act isn't criminal.
If you're trying to make a criminal conspiracy out of non-criminal acts,
your best bet is probably finding a new way to abuse the RICO statutes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160728/659357da/attachment.pgp>

From baldur.norddahl at gmail.com  Thu Jul 28 10:00:00 2016
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Thu, 28 Jul 2016 12:00:00 +0200
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <17158.1469698213@turing-police.cc.vt.edu>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <b0fe8104-ff68-e18d-c738-944fbb515d91@meetinghouse.net>
 <17158.1469698213@turing-police.cc.vt.edu>
Message-ID: <CAPkb-7CA7JW3TsUd93-B-ZxGyrzxi-TAqPSb8PnSSJ=fkrfnjA@mail.gmail.com>

On 28 July 2016 at 11:30, <Valdis.Kletnieks at vt.edu> wrote:

> In general, the conspiracy isn't criminal if the conspired act isn't
> criminal.
> If you're trying to make a criminal conspiracy out of non-criminal acts,
> your best bet is probably finding a new way to abuse the RICO statutes.
>

DDoS attacks using stolen resources and fake identities is not legal and it
is not free speech. Moreover it is illegal just as it is illegal for me to
smash your car.

Cloudflare are saying they are not smashing any cars. Cloudflare will
however act as couriers, provide anonymity and protect anyone that does
smash cars. Also Cloudflare sells "protection" against car smashing.

But all this is just free speech - sorry no, this is not any better than
what the mafia guys are doing in bad parts of the town.

Regards,

Baldur

From Valdis.Kletnieks at vt.edu  Thu Jul 28 11:01:20 2016
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 28 Jul 2016 07:01:20 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <CAPkb-7CA7JW3TsUd93-B-ZxGyrzxi-TAqPSb8PnSSJ=fkrfnjA@mail.gmail.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <b0fe8104-ff68-e18d-c738-944fbb515d91@meetinghouse.net>
 <17158.1469698213@turing-police.cc.vt.edu>
 <CAPkb-7CA7JW3TsUd93-B-ZxGyrzxi-TAqPSb8PnSSJ=fkrfnjA@mail.gmail.com>
Message-ID: <24589.1469703680@turing-police.cc.vt.edu>

On Thu, 28 Jul 2016 12:00:00 +0200, Baldur Norddahl said:

> DDoS attacks using stolen resources and fake identities is not legal

Are you making a blanket statement that covers all jurisdictions on
the planet?

For bonus points - is it more like "illegal as in murder", or "illegal
as in jaywalking"?  (Hint - which one will you get a DA to actually
press a case that almost certainly crosses jurisdictions, and may involve
extradition proceedings?)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160728/98780e01/attachment.pgp>

From justin at cloudflare.com  Thu Jul 28 13:07:51 2016
From: justin at cloudflare.com (Justin Paine)
Date: Thu, 28 Jul 2016 06:07:51 -0700
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <24589.1469703680@turing-police.cc.vt.edu>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <b0fe8104-ff68-e18d-c738-944fbb515d91@meetinghouse.net>
 <17158.1469698213@turing-police.cc.vt.edu>
 <CAPkb-7CA7JW3TsUd93-B-ZxGyrzxi-TAqPSb8PnSSJ=fkrfnjA@mail.gmail.com>
 <24589.1469703680@turing-police.cc.vt.edu>
Message-ID: <CABC6K16UUiWF7E=CmCUQWwzVzpjtS7mYiascU026aD7NSRjuUw@mail.gmail.com>

@Baldur

"They just lost all respect from here. Would someone from USA please report
these guys to the feds? What they are doing is outright criminal."

I'm happy to put you in touch with an FBI agent if you have questions
or concerns you'd like to discuss.

____________
Justin Paine
Head of Trust & Safety
CloudFlare Inc.
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D


On Thu, Jul 28, 2016 at 4:01 AM,  <Valdis.Kletnieks at vt.edu> wrote:
> On Thu, 28 Jul 2016 12:00:00 +0200, Baldur Norddahl said:
>
>> DDoS attacks using stolen resources and fake identities is not legal
>
> Are you making a blanket statement that covers all jurisdictions on
> the planet?
>
> For bonus points - is it more like "illegal as in murder", or "illegal
> as in jaywalking"?  (Hint - which one will you get a DA to actually
> press a case that almost certainly crosses jurisdictions, and may involve
> extradition proceedings?)
>
>

From ahebert at pubnix.net  Thu Jul 28 13:31:37 2016
From: ahebert at pubnix.net (Alain Hebert)
Date: Thu, 28 Jul 2016 09:31:37 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <CABC6K16UUiWF7E=CmCUQWwzVzpjtS7mYiascU026aD7NSRjuUw@mail.gmail.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <b0fe8104-ff68-e18d-c738-944fbb515d91@meetinghouse.net>
 <17158.1469698213@turing-police.cc.vt.edu>
 <CAPkb-7CA7JW3TsUd93-B-ZxGyrzxi-TAqPSb8PnSSJ=fkrfnjA@mail.gmail.com>
 <24589.1469703680@turing-police.cc.vt.edu>
 <CABC6K16UUiWF7E=CmCUQWwzVzpjtS7mYiascU026aD7NSRjuUw@mail.gmail.com>
Message-ID: <9450b4c5-4cab-feb5-7b18-f0ce1f6cd260@pubnix.net>

    Well,

    I do not think feeding the trolls is a good exercise for a
representative of any company that is taking this subject seriously.

    Don't you think?

-----
Alain Hebert                                ahebert at pubnix.net   
PubNIX Inc.        
50 boul. St-Charles
P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
Tel: 514-990-5911  http://www.pubnix.net    Fax: 514-990-9443

On 07/28/16 09:07, Justin Paine via NANOG wrote:
> @Baldur
>
> "They just lost all respect from here. Would someone from USA please report
> these guys to the feds? What they are doing is outright criminal."
>
> I'm happy to put you in touch with an FBI agent if you have questions
> or concerns you'd like to discuss.
>
> ____________
> Justin Paine
> Head of Trust & Safety
> CloudFlare Inc.
> PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D
>
>
> On Thu, Jul 28, 2016 at 4:01 AM,  <Valdis.Kletnieks at vt.edu> wrote:
>> On Thu, 28 Jul 2016 12:00:00 +0200, Baldur Norddahl said:
>>
>>> DDoS attacks using stolen resources and fake identities is not legal
>> Are you making a blanket statement that covers all jurisdictions on
>> the planet?
>>
>> For bonus points - is it more like "illegal as in murder", or "illegal
>> as in jaywalking"?  (Hint - which one will you get a DA to actually
>> press a case that almost certainly crosses jurisdictions, and may involve
>> extradition proceedings?)
>>
>>


From SNaslund at medline.com  Thu Jul 28 13:45:17 2016
From: SNaslund at medline.com (Naslund, Steve)
Date: Thu, 28 Jul 2016 13:45:17 +0000
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <17158.1469698213@turing-police.cc.vt.edu>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <b0fe8104-ff68-e18d-c738-944fbb515d91@meetinghouse.net>
 <17158.1469698213@turing-police.cc.vt.edu>
Message-ID: <9578293AE169674F9A048B2BC9A081B401E66659CC@MUNPRDMBXA1.medline.com>

A DDoS attack is illegal.  In the United States it is considered as theft of service.  The legal construct used is that the DDoS attack is a theft of CPU cycles, compute resources, and power by other than the rightful owner for its intended purposes.

Steven Naslund
Chicago IL

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Valdis.Kletnieks at vt.edu
Sent: Thursday, July 28, 2016 4:30 AM
To: Miles Fidelman
Cc: nanog at nanog.org
Subject: Re: EVERYTHING about Booters (and CloudFlare)

On Wed, 27 Jul 2016 22:55:54 -0400, Miles Fidelman said:
> On 7/27/16 10:48 PM, Randy Bush wrote:
> >> They just lost all respect from here. Would someone from USA please 
> >> report these guys to the feds? What they are doing is outright 
> >> criminal.
> > hyperbole.  it is not criminal.  you just don't happen to like it.
>
> Actually, as someone pointed out, it might well be conspiracy - which 
> is criminal.

In general, the conspiracy isn't criminal if the conspired act isn't criminal.
If you're trying to make a criminal conspiracy out of non-criminal acts, your best bet is probably finding a new way to abuse the RICO statutes.

From aaron at wholesaleinternet.net  Thu Jul 28 14:24:09 2016
From: aaron at wholesaleinternet.net (Aaron)
Date: Thu, 28 Jul 2016 09:24:09 -0500
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <9578293AE169674F9A048B2BC9A081B401E66659CC@MUNPRDMBXA1.medline.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <b0fe8104-ff68-e18d-c738-944fbb515d91@meetinghouse.net>
 <17158.1469698213@turing-police.cc.vt.edu>
 <9578293AE169674F9A048B2BC9A081B401E66659CC@MUNPRDMBXA1.medline.com>
Message-ID: <5ea3f8ea-5db6-ae8a-eb37-706b40d69e74@wholesaleinternet.net>

If you believe someone is doing something illegal than you should report 
it to law enforcement.  Their job is to investigate and bring charges if 
they feel they are warranted.  You do not have to be from the USA to 
report a crime in the USA.

Here is a list with contact info for the FBI's field offices: 
https://www.fbi.gov/contact-us/field-offices

FBI Headquarters: https://www.fbi.gov/contact-us/fbi-headquarters

List of overseas offices for those of you not in the US that want to 
talk to someone local: https://www.fbi.gov/contact-us/legal-attache-offices

Most network operators are not law enforcement or lawyers.

Aaron


On 7/28/2016 8:45 AM, Naslund, Steve wrote:
> A DDoS attack is illegal.  In the United States it is considered as theft of service.  The legal construct used is that the DDoS attack is a theft of CPU cycles, compute resources, and power by other than the rightful owner for its intended purposes.
>
> Steven Naslund
> Chicago IL
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Valdis.Kletnieks at vt.edu
> Sent: Thursday, July 28, 2016 4:30 AM
> To: Miles Fidelman
> Cc: nanog at nanog.org
> Subject: Re: EVERYTHING about Booters (and CloudFlare)
>
> On Wed, 27 Jul 2016 22:55:54 -0400, Miles Fidelman said:
>> On 7/27/16 10:48 PM, Randy Bush wrote:
>>>> They just lost all respect from here. Would someone from USA please
>>>> report these guys to the feds? What they are doing is outright
>>>> criminal.
>>> hyperbole.  it is not criminal.  you just don't happen to like it.
>> Actually, as someone pointed out, it might well be conspiracy - which
>> is criminal.
> In general, the conspiracy isn't criminal if the conspired act isn't criminal.
> If you're trying to make a criminal conspiracy out of non-criminal acts, your best bet is probably finding a new way to abuse the RICO statutes.
>

-- 
================================================================
Aaron Wendel
Chief Technical Officer
Wholesale Internet, Inc. (AS 32097)
(816)550-9030
http://www.wholesaleinternet.com
================================================================


From pauldotwall at gmail.com  Thu Jul 28 14:41:47 2016
From: pauldotwall at gmail.com (Paul WALL)
Date: Thu, 28 Jul 2016 10:41:47 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <m2k2g61nry.wl%randy@psg.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
Message-ID: <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>

I'm sorry, but this entire discussion is predicated on half-truths and
nonsense spewing out of the CF team.  It's a shame too, as they're
usually great community minded folks who are well respected around
here.

No matter how you define the CloudFlare service, that they can claim
ignorance due to "common carrier" passthrough is preposterous,
especially given their purported knowledge of what's going on.
Likewise if the booter sites were connected to any other CDN,
WAF/proxy, public cloud provider, etc.  Call it what you want, but at
the end of the day, they're providing connectivity and keeping the
storefront online.  Want the problem stopped?  Easy, stop it at the
source by denying them service.  Every service provider (or its
upstream at some point) has an AUP which prevents the service from
being used for illegal purposes.  Telling NANOG members that they
don't understand the nature of the CF service, and that they should
somehow get a pass, is dishonest.

That they're keeping these criminals online at the requirement of the
FBI?  Anyone who's actually worked with law enforcement can tell you
that the first rule of fight club is to NOT talk about it, especially
if you're under gag order.  A more likely story is they're just doing
this for the attention, and basking in it, kind of like a certain blog
post suggesting they pioneered the practice of configuring hosts with
LACP for throughput and HA.

If Justin/Matthew/Martin/etc. are listening, I implore you to do the
right thing and stop providing service to criminals.  Full stop,
without caving in to your very talented marketing department.  And to
everyone else, I'd ask you to do what you think is right, and treat
CloudFlare's anycasted IP blocks as you would any other network
harboring criminal activity and security risk to the detriment of your
customers.   (Is Team CYMRU listening?)  Much like the original spam
problem in the 90s, the collateral damage might be annoying at first,
but the end will justify the means.

Drive Slow (like a souped up Supra),
Paul Wall

On Wed, Jul 27, 2016 at 10:48 PM, Randy Bush <randy at psg.com> wrote:
>> They just lost all respect from here. Would someone from USA please
>> report these guys to the feds? What they are doing is outright
>> criminal.
>
> hyperbole.  it is not criminal.  you just don't happen to like it.

From paras at protrafsolutions.com  Thu Jul 28 15:04:06 2016
From: paras at protrafsolutions.com (Paras Jha)
Date: Thu, 28 Jul 2016 11:04:06 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
Message-ID: <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>

Nothing is going to happen. Cloudflare will continue to turn a blind eye
towards abusive customers, and even downright allow customers to HTTP scan
from their network without batting an eyelash. The mere act of scanning
isn't illegal, but it shows the kind of mindset that they have.

From rsk at gsp.org  Thu Jul 28 15:27:22 2016
From: rsk at gsp.org (Rich Kulawiec)
Date: Thu, 28 Jul 2016 11:27:22 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
Message-ID: <20160728152722.GA25938@gsp.org>

On Wed, Jul 27, 2016 at 03:09:51PM +0000, Steve Mikulasik wrote:
> I am sure a lawyer would see it very differently, [...]

For what it's worth I agree, but I'm not an attorney (and neither
are most of us), so I'll write from the perspective of an operator.

The healthy functioning of the Internet community relies on mutual
cooperation.  It always has.  Part of that cooperation is ensuring
that one's own operation, whether it's a single server or a worldwide
collection of data centers, is not an operational hazard to the rest
of the Internet.  That is our first, our primary, our over-arching
responsibility at all times.  Understanding it, embracing it, and
practicing it is something required of all of us.

This isn't a question of what's legal and what's not -- after all,
that varies by jurisdiction and it's a moving target and the machinery
of jurisprudence moves a few orders of magnitude more slowly than
does Internet technology.  It's a question of what's right.  We should
all know that hosting spammers or phishers, DoS-attackers or carders,
or anyone/anything like that is wrong.  (Yes, there are gray areas where
reasonable people can differ about what's right/wrong.  But these
are not among them.)  We should all be doing everything we
can to avoid giving them services, and if we fail in that, if they
get by our screening, we should be cutting them off the moment we're
aware of their presence, and banning them permanently, AND informing
other operators in order to forestall their relocation.

This doesn't require legal involvement: it requires ToS that stipulate
it, and if, in 2016, any service *doesn't* have ToS that stipulate these
things: you need to get new attorneys and fix that today.

It also requires having a functioning abuse@ address (per RFC 2142
and decades of best practices) that connects to a functioning abuse
department that is empowered to investigate and act on everything
that shows up there.  In a better world, this wouldn't be necessary:
abuse sources/sinks/facilitators would already know of their own
involvement and nobody would need to tell them.  But we don't live
in that world and in some cases, it's arguably difficult to tell
even for very diligent operators.  So if third parties are doing you
the incredibly gracious favor of reporting abuse to you, thus making
*your* job easier despite the fact that *your* operation is making
their job harder...you should listen.  You should investigate.  You
should say thank you.  You should report the outcome.

This isn't hard.  It's really not.  (And to those who say "we get too
many abuse complaints", there is a very simple fix for that: stop
facilitating so much abuse.  The complaints will drop proportionately.)

The alternative to this is an Internet of escalating attacks and abuse --
which is where we find ourselves after a few decades of incompetence
and negligence (those who can't be bothered) and deliberate support
(those who choose to take dirty money and cash in on abuse).  It's already
pretty bad, which is why there are now entire sectors built on mitigating
it.  We can either continue to light stacks of money on fire (and that's
one of the smaller costs of this) trying to stave this off or we can
do what we should have been doing all along: be *personally* responsible
for what our technology is doing.  No excuses.  No stonewalling.  No blowoffs
with a nod to the legal department.  Just step up and do the right thing
for the good of the community -- because without that community, even
the biggest, richest operation is of no importance and value whatsoever.

---rsk

From choprboy at dakotacom.net  Wed Jul 27 23:03:24 2016
From: choprboy at dakotacom.net (Adrian)
Date: Wed, 27 Jul 2016 16:03:24 -0700
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <CAJayEpFyP5NVsST4y5qSep-uJK7eXjaLXGWzVotVwX1pQ1cZ+Q@mail.gmail.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CABC6K15-1Vb7C9g_JDfsgGT0QSU7vtEhWfb9Bv3cMyhR8iURmA@mail.gmail.com>
 <CAJayEpFyP5NVsST4y5qSep-uJK7eXjaLXGWzVotVwX1pQ1cZ+Q@mail.gmail.com>
Message-ID: <201607271603.24730.choprboy@dakotacom.net>

On Wednesday 27 July 2016 07:58:49 Paras Jha wrote:
> Hi Justin,
> 
> I have submitted abuse reports in the past, maybe from 2014 - 2015, but I
> gave up after I consistently did not even get replies and saw no action
> being taken. It is the same behavior with other providers who host malware
> knowingly. I appreciate you coming out onto the list though, it's nice to
> see that CF does maintain a presence here.
> 

I am not seeing Justin's replies hitting my mailbox, only snipets of quotes 
and replies... but my experience to date with CloudFlare has been exactly the 
same, no response or action of any kind to abuse reports.

...Searching... here is an example. Banco do Brasil "you must update your 
details" phishing fraud using compromised hosts. Example email and for details 
neccessary to confirm sent to abuse at cloudflare.com on 7/17. Ten days later and 
the compromised CloudFlare-fronted site is still up and still running. Would 
there be any confusion if the following abuse report (plus attached original 
email) arrived in your mailbox?

====================
Phishing / Fraud / Compromised server

Phishing URL:
http://www.rua.edu.kh/joomla/tecno/porta-bb2.com.jpg/

Redirects to:
http://fonecomercial.com.br/admin/wip.php/index.php

Redirects to:
http://app.flipedition.com/css/www2.bb.com.br.jpg/

Compromised server:
www.rua.edu.kh - 203.189.134.18
fonecomercial.com.br - 104.27.148.36  104.27.149.36
app.flipedition.com - 62.75.219.22

====================

Any guesses who 104.27.148.36 104.27.149.36 is? PlusServer.de (62.75.219.22) 
terminated the final destination compromised pages within 12 hours... The 
others are still up. Some providers actively monitor and take control of 
reported abuses. Some providers actively ignore reported abuses.



From outsider at scarynet.org  Thu Jul 28 15:44:20 2016
From: outsider at scarynet.org (Alexander Maassen)
Date: Thu, 28 Jul 2016 17:44:20 +0200
Subject: EVERYTHING about Booters (and CloudFlare)
Message-ID: <19876815d14b97428e9eb9fe1a2635fb.squirrel@mail.scarynet.org>

Sigh, another long thread that goes nowhere in the end and simply dies a
dull dead. So let's add my 2ct donation into it.

First of all, CF like any other carrier/provider/hoster/whatever only
cares about the bucks, nothing else, you all do to, so that should be
clear enough. Them actually booting customers just because some other
instance (except through govermential powers) wants them to is not done,
as it would decrease the income. Period. Same goes for ISP's blocking
access to resources. They will simply switch to another provider and or
try to find workarounds for it (see pirate bay and the alikes). Thats like
mopping the floor while the fire sprinklers are still on.

Second, CF indeed offers DDoS mitigation, but only on their heavy paid
plans, if you also want the netflow logs of the attacks etc, it will cost
you extra. If you are on a free plan, and your assigned gw gets ddossed,
and they figure out you are the target, they drop the 'protection' by
simply changing dns to it's real values and letting the attacker know:
don't dos us if you want to hit that site, use the real endpoint IP
instead and you will hit them directly. (Been there with DroneBL, and as
soon as I figured out they do that, dropped them immediately). In the end,
you are better off at hosters like OVH/Foonet and such as they learned
from the IRC age where it was common to nuke clients/bnc's in order to
hijack nicknames/channels when the network didn't have channel/nick
services.

Third, for those who do not know it yet, CF only acts as an intermediate
RELAY that provides a method of attempting to identify bad asses, nothing
more. And the badasses they also relay for? Testpigs and informational
source! (Keep your friends close, your enemies closer?).

Hell, aren't some of the best security advisors former hackers? At least
the ones I know used to be. And I rather have some decent hacker in my
team, keeping me updated with the stuff thats going on in the scene, then
some million dollar company trying to sell you crap that is always behind
the facts. Oh, and I am talking about real hackers, not those
scriptkiddies using ready made tools thinking they are god.

Fourth, and I see it in this mail as well and a lot of others: The
Jurisdictional issues. Why aren't there any international Cyber Crime laws
yet? We all do need to enforce crap like DMCA (which the
music/entertainment industry is responsible for), EU Cookie Law (which
should have been handled through the browsers and not force it upon the
websites) and it's inbread stupid derivates, but everyone, despite acting
out international by it's presence on a global spanning network, is still
hiding behind his/her's organizations local law. Kinda stupid, don't you
agree ?

Kind regards,

Alexander Maassen
Maintainer DroneBL

On Thu, July 28, 2016 4:41 pm, Paul WALL wrote:
> I'm sorry, but this entire discussion is predicated on half-truths and
nonsense spewing out of the CF team.  It's a shame too, as they're
usually great community minded folks who are well respected around here.
>
> No matter how you define the CloudFlare service, that they can claim
ignorance due to "common carrier" passthrough is preposterous,
> especially given their purported knowledge of what's going on.
> Likewise if the booter sites were connected to any other CDN,
> WAF/proxy, public cloud provider, etc.  Call it what you want, but at
the end of the day, they're providing connectivity and keeping the
storefront online.  Want the problem stopped?  Easy, stop it at the
source by denying them service.  Every service provider (or its
> upstream at some point) has an AUP which prevents the service from being
used for illegal purposes.  Telling NANOG members that they don't
understand the nature of the CF service, and that they should somehow
get a pass, is dishonest.
>
> That they're keeping these criminals online at the requirement of the
FBI?  Anyone who's actually worked with law enforcement can tell you
that the first rule of fight club is to NOT talk about it, especially if
you're under gag order.  A more likely story is they're just doing this
for the attention, and basking in it, kind of like a certain blog post
suggesting they pioneered the practice of configuring hosts with LACP
for throughput and HA.
>
> If Justin/Matthew/Martin/etc. are listening, I implore you to do the
right thing and stop providing service to criminals.  Full stop, without
caving in to your very talented marketing department.  And to everyone
else, I'd ask you to do what you think is right, and treat CloudFlare's
anycasted IP blocks as you would any other network
> harboring criminal activity and security risk to the detriment of your
customers.   (Is Team CYMRU listening?)  Much like the original spam
problem in the 90s, the collateral damage might be annoying at first,
but the end will justify the means.
>
> Drive Slow (like a souped up Supra),
> Paul Wall
>
> On Wed, Jul 27, 2016 at 10:48 PM, Randy Bush <randy at psg.com> wrote:
>>> They just lost all respect from here. Would someone from USA please
report these guys to the feds? What they are doing is outright
criminal.
>>
>> hyperbole.  it is not criminal.  you just don't happen to like it.
>





From mfidelman at meetinghouse.net  Thu Jul 28 15:38:50 2016
From: mfidelman at meetinghouse.net (Miles Fidelman)
Date: Thu, 28 Jul 2016 11:38:50 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
Message-ID: <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>

On 7/28/16 11:04 AM, Paras Jha wrote:

> Nothing is going to happen. Cloudflare will continue to turn a blind eye
> towards abusive customers, and even downright allow customers to HTTP scan
> from their network without batting an eyelash. The mere act of scanning
> isn't illegal, but it shows the kind of mindset that they have.

Let's see:

Vbooter (on their home page) claims:
"#1 FREE WEBBASED SERVER STRESSER"
"Using vBooter you can take down home internet connections, websites and 
game servers such us Minecraft, XBOX Live, PSN and many more."
"You don't have to pay anything in order to use this stresser! In 
addition there are NO limits if you are a free user."

So they're advertising a free service that explicitly offers DDoS 
capabilities.

Now - with the caveat that I'm not a lawyer, and I'm talking from a US 
perspective only - as a sometimes hosting provider who pays attention to 
our legal liabilities, and who's had one of our boxes compromised and 
used to vector a DDoS against a gaming site....

1.  DDoS is clearly illegal under multiple statutes - most notably the 
Computer Fraud and Abuse Act - see
https://www.justice.gov/sites/default/files/criminal-ccips/legacy/2015/01/14/ccmanual.pdf 
- for a Justice Dept. memo on "Prosecuting Computer Crimes."  When 
coupled with threats, requests for payoffs, etc. - it expands into lots 
of other crimes (e.g., extortion).  And that's before one starts 
attacking Government-owned computer systems.

2. One might infer that, while "stress testing" is a legitimate and 
useful service - under specific circumstances, vBooter's tools might 
also fall under laws regarding being an accomplice to a criminal act, 
aiding & abetting, "burglar's tools," etc., and more generally "creating 
a public nuisance."

3. There are also various (mostly state) laws against the sale of 
burglar's tools (e.g., sale of a lockpick to someone who's not a 
professional locksmith).  I expect some of those laws might apply.

4. All of those certainly could be applied to vBooter.org.  Whether 
Cloudflare is liable for anything would seem to depend on whether 
Cloudflare is complicit in the use of vBooter's use for criminal 
purposes, or promoting it's use therefore.  Hosting would certainly fall 
into that category - and while, I have no direct knowledge that 
Cloudflare hosts vBooter, they do provide nameservice, and their web 
server's IP address is in a network block registered to Cloudflare - 
that would seem to establish complicity.  Now if Cloudflare were to 
actively suggest that folks use vBooter to test systems, as a way to 
boost sales for Cloudflare - that would certainly be an interesting test 
case for RICO (akin to McAfee encouraging folks to write and release 
viruses).

As to whether "Nothing is going to happen" - I expect something WILL 
happen, when somebody big, with a good legal department, gets hit by a 
really damaging DDoS attack, and starts looking for some deep pockets to 
sue.  Or, if somebody attacks the wrong Government computer and the FBI, 
or DoD, or DHS get ticked off.

It will make for very good theater - at least for anyone not directly in 
the cross-hairs.

Miles Fidelman


-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra


From niels=nanog at bakker.net  Thu Jul 28 15:56:38 2016
From: niels=nanog at bakker.net (Niels Bakker)
Date: Thu, 28 Jul 2016 17:56:38 +0200
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
Message-ID: <20160728155638.GE3955@excession.tpb.net>

* mfidelman at meetinghouse.net (Miles Fidelman) [Thu 28 Jul 2016, 17:42 CEST]:
[...]
>Now if Cloudflare were to actively suggest that folks use vBooter to 
>test systems, as a way to boost sales for Cloudflare - that would 
>certainly be an interesting test case for RICO

CloudFlare is doing nothing of the sort, and it's kind of vile for 
you to suggest otherwise, even ostensibly by way of floating it as 
a hypothetical.


	-- Niels.

From SNaslund at medline.com  Thu Jul 28 16:00:45 2016
From: SNaslund at medline.com (Naslund, Steve)
Date: Thu, 28 Jul 2016 16:00:45 +0000
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <19876815d14b97428e9eb9fe1a2635fb.squirrel@mail.scarynet.org>
References: <19876815d14b97428e9eb9fe1a2635fb.squirrel@mail.scarynet.org>
Message-ID: <9578293AE169674F9A048B2BC9A081B401E6666878@MUNPRDMBXA1.medline.com>

There are not international cyber crime laws because there is no international law enforcement agency with the reach to enforce them and because most countries like things like sovereignty.  There is also an inherent conflict between private citizen hacking and state sponsored hacking and the line is sometimes blurry.  If a state sponsor is using a private DDoS network, what are the chances they are going to allow an investigation/arrest in that case?  There are already enough laws on the books in most cases to handle this stuff, there just isn't the law enforcement resources/interest to pursue this.  

Companies like CloudFare generally end up in one of two states given my experience since the first public Internet became available.

1.  Various service providers get screwed with enough and eventually retaliate by messing with CloudFare's connectivity/peering/availability to the point that CloudFare becomes an unviable platform for the nefarious services.  This happened in the original spam wars with regularity.  As soon as CloudFare becomes inconvenient or too visible to law enforcement, they move on to the next provider and enough legit business is scared away that CloudFare dies on the vine.

2.  Eventually one of the nefarious services messes around with something large enough to create big law enforcement interest (a successful hit on a critical national resource) at which point they cut all the intergovernmental red tape and take out everyone including the hacker, the server farm, the hosting company, and anyone else involved.  Remember that they don't necessarily have to prove a criminal case to shut your business down.  All they really have to do is get a judge to order a seizure of enough of your gear to shut you down for a period of time that sends all your other business out the door.  Note that I don't support/not support that tactic but it's a fact that it works.  Sure, you can try to defend yourself but how deep are your legal pockets?  The US Justice Department has shown time and again that they can wipe out large swaths of nefarious operators when they care enough to do so.  They have also shown the ability to cross international border to do so.  They put some serious dents in Pirate Bay and Anonymous.  They don't kill them permanently but it doesn't matter to the guys sitting in prison for years.

Steven Naslund
Chicago IL





From SNaslund at medline.com  Thu Jul 28 16:12:25 2016
From: SNaslund at medline.com (Naslund, Steve)
Date: Thu, 28 Jul 2016 16:12:25 +0000
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
Message-ID: <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>

Miles is right.  Their thinly veiled "stress tester" thing is not going to be much of a defense.  They must not have very good legal counsel.  Here is the issue.  Stress testing is perfectly legal as long as I am:

	a) Stress testing my own stuff
	b) Stress testing your stuff WITH YOUR CONSENT

Selling a product or service that is unsafe can lead to serious civil consequences.  For example, I sell you roach killer and don't warn you that it will also kill every other living thing in your home, I am going to get sued and lose badly.

Let's say I am running a demolition company that offers to knock down any house for a price.  Don't you think I have a responsibility to verify that you own the house you just asked me to knock down?   (by the way, this has happened in the real world -wrong address on paperwork- and the demolition company was held liable) Obviously I have that responsibility and obviously the same rules would apply to any service that can potentially damage someone's property.

Steven Naslund
Chicago IL

>Let's see:
>
>Vbooter (on their home page) claims:
>"#1 FREE WEBBASED SERVER STRESSER"
>"Using vBooter you can take down home internet connections, websites and game servers such us Minecraft, XBOX Live, PSN and many more."
>"You don't have to pay anything in order to use this stresser! In addition there are NO limits if you are a free user."

>So they're advertising a free service that explicitly offers DDoS capabilities.

>Now - with the caveat that I'm not a lawyer, and I'm talking from a US perspective only - as a sometimes hosting provider who pays attention to our legal liabilities, and >who's had one of our boxes compromised and used to vector a DDoS against a gaming site....

>1.  DDoS is clearly illegal under multiple statutes - most notably the Computer Fraud and Abuse Act - see https://www.justice.gov/sites/default/files/criminal->ccips/legacy/2015/01/14/ccmanual.pdf
>- for a Justice Dept. memo on "Prosecuting Computer Crimes."  When coupled with threats, requests for payoffs, etc. - it expands into lots of other crimes (e.g., >extortion).  And that's before one starts attacking Government-owned computer systems.
>
>2. One might infer that, while "stress testing" is a legitimate and useful service - under specific circumstances, vBooter's tools might also fall under laws regarding >being an accomplice to a criminal act, aiding & abetting, "burglar's tools," etc., and more generally "creating a public nuisance."
>
>3. There are also various (mostly state) laws against the sale of burglar's tools (e.g., sale of a lockpick to someone who's not a professional locksmith).  I expect some >of those laws might apply.
>
>4. All of those certainly could be applied to vBooter.org.  Whether Cloudflare is liable for anything would seem to depend on whether Cloudflare is complicit in the use >of vBooter's use for criminal purposes, or promoting it's use therefore.  Hosting would certainly fall into that category - and while, I have no direct knowledge that >Cloudflare hosts vBooter, they do provide nameservice, and their web server's IP address is in a network block registered to Cloudflare - that would seem to establish >complicity.  Now if Cloudflare were to actively suggest that folks use vBooter to test systems, as a way to boost sales for Cloudflare - that would certainly be an >interesting test case for RICO (akin to McAfee encouraging folks to write and release viruses).
>
>As to whether "Nothing is going to happen" - I expect something WILL happen, when somebody big, with a good legal department, gets hit by a really damaging DDoS attack, >and starts looking for some deep pockets to sue.  Or, if somebody attacks the wrong Government computer and the FBI, or DoD, or DHS get ticked off.
>
>It will make for very good theater - at least for anyone not directly in the cross-hairs.
>
>Miles Fidelman


From pr at isprime.com  Thu Jul 28 16:20:24 2016
From: pr at isprime.com (Phil Rosenthal)
Date: Thu, 28 Jul 2016 12:20:24 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
Message-ID: <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>

Keep in mind also, the victims of these DDoS attacks do not know which "booter" service was paid to attack them. The packets do not have "Stress test provided by vBooter" in them. The attack packets do not come from the booter's or Cloudflare's IP addresses, they come from secondary victims -- compromised servers, PC's infected with malware, and abused DNS/NTP [and a few other protocols] reflectors.

It is impossible for a victim to submit a complaint to Cloudflare stating "I was attacked by someone paying vBooter", because they do not know which of the numerous "booter" services was responsible.

-Phil
> On Jul 28, 2016, at 12:12 PM, Naslund, Steve <SNaslund at medline.com> wrote:
> 
> Miles is right.  Their thinly veiled "stress tester" thing is not going to be much of a defense.  They must not have very good legal counsel.  Here is the issue.  Stress testing is perfectly legal as long as I am:
> 
> 	a) Stress testing my own stuff
> 	b) Stress testing your stuff WITH YOUR CONSENT
> 
> Selling a product or service that is unsafe can lead to serious civil consequences.  For example, I sell you roach killer and don't warn you that it will also kill every other living thing in your home, I am going to get sued and lose badly.
> 
> Let's say I am running a demolition company that offers to knock down any house for a price.  Don't you think I have a responsibility to verify that you own the house you just asked me to knock down?   (by the way, this has happened in the real world -wrong address on paperwork- and the demolition company was held liable) Obviously I have that responsibility and obviously the same rules would apply to any service that can potentially damage someone's property.
> 
> Steven Naslund
> Chicago IL
> 
>> Let's see:
>> 
>> Vbooter (on their home page) claims:
>> "#1 FREE WEBBASED SERVER STRESSER"
>> "Using vBooter you can take down home internet connections, websites and game servers such us Minecraft, XBOX Live, PSN and many more."
>> "You don't have to pay anything in order to use this stresser! In addition there are NO limits if you are a free user."
> 
>> So they're advertising a free service that explicitly offers DDoS capabilities.
> 
>> Now - with the caveat that I'm not a lawyer, and I'm talking from a US perspective only - as a sometimes hosting provider who pays attention to our legal liabilities, and >who's had one of our boxes compromised and used to vector a DDoS against a gaming site....
> 
>> 1.  DDoS is clearly illegal under multiple statutes - most notably the Computer Fraud and Abuse Act - see https://www.justice.gov/sites/default/files/criminal->ccips/legacy/2015/01/14/ccmanual.pdf
>> - for a Justice Dept. memo on "Prosecuting Computer Crimes."  When coupled with threats, requests for payoffs, etc. - it expands into lots of other crimes (e.g., >extortion).  And that's before one starts attacking Government-owned computer systems.
>> 
>> 2. One might infer that, while "stress testing" is a legitimate and useful service - under specific circumstances, vBooter's tools might also fall under laws regarding >being an accomplice to a criminal act, aiding & abetting, "burglar's tools," etc., and more generally "creating a public nuisance."
>> 
>> 3. There are also various (mostly state) laws against the sale of burglar's tools (e.g., sale of a lockpick to someone who's not a professional locksmith).  I expect some >of those laws might apply.
>> 
>> 4. All of those certainly could be applied to vBooter.org.  Whether Cloudflare is liable for anything would seem to depend on whether Cloudflare is complicit in the use >of vBooter's use for criminal purposes, or promoting it's use therefore.  Hosting would certainly fall into that category - and while, I have no direct knowledge that >Cloudflare hosts vBooter, they do provide nameservice, and their web server's IP address is in a network block registered to Cloudflare - that would seem to establish >complicity.  Now if Cloudflare were to actively suggest that folks use vBooter to test systems, as a way to boost sales for Cloudflare - that would certainly be an >interesting test case for RICO (akin to McAfee encouraging folks to write and release viruses).
>> 
>> As to whether "Nothing is going to happen" - I expect something WILL happen, when somebody big, with a good legal department, gets hit by a really damaging DDoS attack, >and starts looking for some deep pockets to sue.  Or, if somebody attacks the wrong Government computer and the FBI, or DoD, or DHS get ticked off.
>> 
>> It will make for very good theater - at least for anyone not directly in the cross-hairs.
>> 
>> Miles Fidelman
> 


From tknchris at gmail.com  Thu Jul 28 16:27:52 2016
From: tknchris at gmail.com (chris)
Date: Thu, 28 Jul 2016 12:27:52 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
Message-ID: <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>

They don't discriminate, anyone can be a customer
https://www.youtube.com/watch?v=T4GfoSZ_sDc

great quote from the reporter "why do you need a court order to do the
right thing?"

On Thu, Jul 28, 2016 at 12:20 PM, Phil Rosenthal <pr at isprime.com> wrote:

> Keep in mind also, the victims of these DDoS attacks do not know which
> "booter" service was paid to attack them. The packets do not have "Stress
> test provided by vBooter" in them. The attack packets do not come from the
> booter's or Cloudflare's IP addresses, they come from secondary victims --
> compromised servers, PC's infected with malware, and abused DNS/NTP [and a
> few other protocols] reflectors.
>
> It is impossible for a victim to submit a complaint to Cloudflare stating
> "I was attacked by someone paying vBooter", because they do not know which
> of the numerous "booter" services was responsible.
>
> -Phil
> > On Jul 28, 2016, at 12:12 PM, Naslund, Steve <SNaslund at medline.com>
> wrote:
> >
> > Miles is right.  Their thinly veiled "stress tester" thing is not going
> to be much of a defense.  They must not have very good legal counsel.  Here
> is the issue.  Stress testing is perfectly legal as long as I am:
> >
> >       a) Stress testing my own stuff
> >       b) Stress testing your stuff WITH YOUR CONSENT
> >
> > Selling a product or service that is unsafe can lead to serious civil
> consequences.  For example, I sell you roach killer and don't warn you that
> it will also kill every other living thing in your home, I am going to get
> sued and lose badly.
> >
> > Let's say I am running a demolition company that offers to knock down
> any house for a price.  Don't you think I have a responsibility to verify
> that you own the house you just asked me to knock down?   (by the way, this
> has happened in the real world -wrong address on paperwork- and the
> demolition company was held liable) Obviously I have that responsibility
> and obviously the same rules would apply to any service that can
> potentially damage someone's property.
> >
> > Steven Naslund
> > Chicago IL
> >
> >> Let's see:
> >>
> >> Vbooter (on their home page) claims:
> >> "#1 FREE WEBBASED SERVER STRESSER"
> >> "Using vBooter you can take down home internet connections, websites
> and game servers such us Minecraft, XBOX Live, PSN and many more."
> >> "You don't have to pay anything in order to use this stresser! In
> addition there are NO limits if you are a free user."
> >
> >> So they're advertising a free service that explicitly offers DDoS
> capabilities.
> >
> >> Now - with the caveat that I'm not a lawyer, and I'm talking from a US
> perspective only - as a sometimes hosting provider who pays attention to
> our legal liabilities, and >who's had one of our boxes compromised and used
> to vector a DDoS against a gaming site....
> >
> >> 1.  DDoS is clearly illegal under multiple statutes - most notably the
> Computer Fraud and Abuse Act - see
> https://www.justice.gov/sites/default/files/criminal-
> >ccips/legacy/2015/01/14/ccmanual.pdf
> >> - for a Justice Dept. memo on "Prosecuting Computer Crimes."  When
> coupled with threats, requests for payoffs, etc. - it expands into lots of
> other crimes (e.g., >extortion).  And that's before one starts attacking
> Government-owned computer systems.
> >>
> >> 2. One might infer that, while "stress testing" is a legitimate and
> useful service - under specific circumstances, vBooter's tools might also
> fall under laws regarding >being an accomplice to a criminal act, aiding &
> abetting, "burglar's tools," etc., and more generally "creating a public
> nuisance."
> >>
> >> 3. There are also various (mostly state) laws against the sale of
> burglar's tools (e.g., sale of a lockpick to someone who's not a
> professional locksmith).  I expect some >of those laws might apply.
> >>
> >> 4. All of those certainly could be applied to vBooter.org.  Whether
> Cloudflare is liable for anything would seem to depend on whether
> Cloudflare is complicit in the use >of vBooter's use for criminal purposes,
> or promoting it's use therefore.  Hosting would certainly fall into that
> category - and while, I have no direct knowledge that >Cloudflare hosts
> vBooter, they do provide nameservice, and their web server's IP address is
> in a network block registered to Cloudflare - that would seem to establish
> >complicity.  Now if Cloudflare were to actively suggest that folks use
> vBooter to test systems, as a way to boost sales for Cloudflare - that
> would certainly be an >interesting test case for RICO (akin to McAfee
> encouraging folks to write and release viruses).
> >>
> >> As to whether "Nothing is going to happen" - I expect something WILL
> happen, when somebody big, with a good legal department, gets hit by a
> really damaging DDoS attack, >and starts looking for some deep pockets to
> sue.  Or, if somebody attacks the wrong Government computer and the FBI, or
> DoD, or DHS get ticked off.
> >>
> >> It will make for very good theater - at least for anyone not directly
> in the cross-hairs.
> >>
> >> Miles Fidelman
> >
>
>

From SNaslund at medline.com  Thu Jul 28 16:51:19 2016
From: SNaslund at medline.com (Naslund, Steve)
Date: Thu, 28 Jul 2016 16:51:19 +0000
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
Message-ID: <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>

It is not beyond the realm of law enforcement to run down the entire chain of events all the way back to the ?whodunit? and ?howdunit?.  It is pretty amazing what they can figure out when they put their minds to it and don?t underestimate what they can learn by getting someone in the hot seat under the bare light bulb.  They also have lots of informants.

Victim complaints don?t matter a bit to these guys, it will take the guys in the windbreakers kicking in the doors one of these days.

Steven Naslund
Chicago IL

>On Thu, Jul 28, 2016 at 12:20 PM, Phil Rosenthal <pr at isprime.com<mailto:pr at isprime.com>> wrote:
>Keep in mind also, the victims of these DDoS attacks do not know which "booter" service was paid to attack them. The packets do not have "Stress test provided by vBooter" in them. The attack packets do not ?>come from the booter's or Cloudflare's IP addresses, they come from secondary victims -- compromised servers, PC's infected with malware, and abused DNS/NTP [and a few other protocols] reflectors.
>
>It is impossible for a victim to submit a complaint to Cloudflare stating "I was attacked by someone paying vBooter", because they do not know which of the numerous "booter" services was responsible.
>
>-Phil

From pr at isprime.com  Thu Jul 28 16:56:39 2016
From: pr at isprime.com (Phil Rosenthal)
Date: Thu, 28 Jul 2016 12:56:39 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
Message-ID: <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>

Are you of the opinion that the victim of a DDoS attack who is not a multi-billion-dollar corporation would actually receive help from the FBI as a result of a DDoS attack?
In the past, I have been told that the dollar-threshold for the FBI to even consider looking at a case was at least $2M in damages. This was 10 years ago, and I can't imagine the threshold has gone down.

-Phil

> On Jul 28, 2016, at 12:51 PM, Naslund, Steve <SNaslund at medline.com> wrote:
> 
> It is not beyond the realm of law enforcement to run down the entire chain of events all the way back to the ?whodunit? and ?howdunit?.  It is pretty amazing what they can figure out when they put their minds to it and don?t underestimate what they can learn by getting someone in the hot seat under the bare light bulb.  They also have lots of informants.
> 
> Victim complaints don?t matter a bit to these guys, it will take the guys in the windbreakers kicking in the doors one of these days.
> 
> Steven Naslund
> Chicago IL
> 
>> On Thu, Jul 28, 2016 at 12:20 PM, Phil Rosenthal <pr at isprime.com<mailto:pr at isprime.com>> wrote:
>> Keep in mind also, the victims of these DDoS attacks do not know which "booter" service was paid to attack them. The packets do not have "Stress test provided by vBooter" in them. The attack packets do not ?>come from the booter's or Cloudflare's IP addresses, they come from secondary victims -- compromised servers, PC's infected with malware, and abused DNS/NTP [and a few other protocols] reflectors.
>> 
>> It is impossible for a victim to submit a complaint to Cloudflare stating "I was attacked by someone paying vBooter", because they do not know which of the numerous "booter" services was responsible.
>> 
>> -Phil


From SNaslund at medline.com  Thu Jul 28 17:06:08 2016
From: SNaslund at medline.com (Naslund, Steve)
Date: Thu, 28 Jul 2016 17:06:08 +0000
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
Message-ID: <9578293AE169674F9A048B2BC9A081B401E6666BD9@MUNPRDMBXA1.medline.com>

No, as I said earlier, I am of the opinion that these networks get swept up once they go too big and hit something that law enforcement really cares about (read: embarrassed by).  At that point they get everyone.  You and I and our customers can't do much of anything until that point unless the service provider community gets aggravated enough to go to war with them.   Thing is no one knows who is Senator Xs friend or has someone with enough pull to get a response.  Eventually they all trip over one of those mines.

Steven Naslund
Chicago IL

>-----Original Message-----
>From: Phil Rosenthal [mailto:pr at isprime.com] 
>Sent: Thursday, July 28, 2016 11:57 AM
>To: Naslund, Steve
>Cc: nanog at nanog.org
>Subject: Re: EVERYTHING about Booters (and CloudFlare)
>
>Are you of the opinion that the victim of a DDoS attack who is not a multi-billion-dollar corporation would actually receive help from the FBI as a result of a DDoS attack?
>In the past, I have been told that the dollar-threshold for the FBI to even consider looking at a case was at least $2M in damages. This was 10 years ago, and I can't imagine the threshold has gone down.
>
>-Phil

From SNaslund at medline.com  Thu Jul 28 17:13:46 2016
From: SNaslund at medline.com (Naslund, Steve)
Date: Thu, 28 Jul 2016 17:13:46 +0000
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <9578293AE169674F9A048B2BC9A081B401E6666BD9@MUNPRDMBXA1.medline.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <9578293AE169674F9A048B2BC9A081B401E6666BD9@MUNPRDMBXA1.medline.com>
Message-ID: <9578293AE169674F9A048B2BC9A081B401E6666C4B@MUNPRDMBXA1.medline.com>


The best analogy to real world would be to look at CloudFare as an arms dealer.  They don't start the war but they sure enable it.  The governments probably don't care who you sell arms to until their goat gets gored and then they are coming for you.  Believe me they have more than enough laws on the books to find one that applies to just about any circumstance they want.  In that world, legal and illegal don?t matter as much as who likes you and who doesn't.

Steven Naslund
Chicago IL

From mfidelman at meetinghouse.net  Thu Jul 28 17:15:58 2016
From: mfidelman at meetinghouse.net (Miles Fidelman)
Date: Thu, 28 Jul 2016 13:15:58 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <20160728155638.GE3955@excession.tpb.net>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <20160728155638.GE3955@excession.tpb.net>
Message-ID: <7e51c546-68cc-0ea4-7550-a49c2085ffa2@meetinghouse.net>

On 7/28/16 11:56 AM, Niels Bakker wrote:

> * mfidelman at meetinghouse.net (Miles Fidelman) [Thu 28 Jul 2016, 17:42 
> CEST]:
> [...]
>> Now if Cloudflare were to actively suggest that folks use vBooter to 
>> test systems, as a way to boost sales for Cloudflare - that would 
>> certainly be an interesting test case for RICO
>
> CloudFlare is doing nothing of the sort, and it's kind of vile for you 
> to suggest otherwise, even ostensibly by way of floating it as a 
> hypothetical.
>

Well, I don't know - if I were in the business of selling security 
services, I'd probably suggest that potential customers do some 
penetration and stress testing of their systems.  And that seems pretty 
legitimate.

For that matter - "here are some tools you can use to test your systems" 
also strikes me as pretty legitimate.

On the other hand - one might argue that publishing something like "How 
to Launch a 65Gbps DDoS, and How to Stop One" 
https://blog.cloudflare.com/65gbps-ddos-no-problem/ - pushes the limits 
a bit - depending on how much detailed "how-to" information one 
provides, and how much one presents oneself as the solution.

Granted, that there's a lot of value in education - I certainly want to 
know the various ways folks might attack our systems, and the various 
ways we might defend ourselves.  But there are limits - not just legal 
ones, but, as others have pointed out, ethical ones and ones of good 
taste.  The CERT draws its lines one place; on the other hand, Symantec 
publishes white papers that give some rather in depth analyses of 
specific viruses - there for the googling. Cloudflare certainly comes 
closer to one line than the other.

Opinions vary as to the ethics, taste, and legality of publishing 
detailed how-to information - there's certainly enough out there from 
sources with ill intent (including rather nasty libraries and tools that 
require little technical expertise to utilize) - so I tend to favor more 
details.

When one directly ties detailed how-to information, with product/service 
sales - now that strikes me as begging to be the target of some 
interesting test cases.  In Cloudflare's case - telling people how to 
attack a site, hosting free & openly available tools that can support 
such an attack, and selling services to mitigate the attack - now that's 
a test case just waiting to happen.  "How to Launch a 65Gbps DDoS, and 
How to Stop One" seems like an open invitation to ambulance chasers and 
aggressive prosecutors.

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra


From joquendo at e-fensive.net  Thu Jul 28 17:17:08 2016
From: joquendo at e-fensive.net (J. Oquendo)
Date: Thu, 28 Jul 2016 12:17:08 -0500
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
References: <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
Message-ID: <20160728171708.GA87119@e-fensive.net>


While many are chanting: #NetworkLivesMatter, I have yet
to see, read, or hear about any network provider being
the first to set precedence by either de-peering, or
blocking traffic from Cloudflare. There is a lot of
keyboard posturing: "I am mad and I am not going to take
it anymore" hooplah but no one is lifting a finger to
do anything other than regurgitate "I am mad... This is
criminal."

Government in the US is not going to get involved as the
financial cost won't warrant an investigation. Would you
spend $100 to tow a car worth $1. Cloudflare, Amazon,
Rackspace, and countless others are, and have been 
allowing the same thing since the dawn of their creation
and network operators... Shame on you for allowing it.

It is legal? Is it moral? Does it serve a real world
benefit? (booters). Let's get real these booters serve
little purpose. Anyone can go back to romper room and do
the simple math: I have a 100mb pipe, if someone sends me
200mb will it flood me? A pre-schooler can give anyone
the answer. Yet here is everyone chiming in on legal
matters when not one respondent that I have seen is a
lawyer.

I wrote about this in my rambling which is linked in the
NANOG LinkedIn group: "Why Do Networking Providers Like
Cybercriminals So Much" and the responses I have read on
this thread, make me believe it more so. Networking
operators could give a rats ass about doing anything about
DDoS, viruses. etc., since it is a source of revenue
down the daisy chain. Like it or not. I would be surprised
if ANYONE in this NOG, or any other "NOG" de-peered out of
principle. With that said, I don't even know why this
thread is being continued. 


-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM

"Where ignorance is our master, there is no possibility of
real peace" - Dalai Lama

0B23 595C F07C 6092 8AEB  074B FC83 7AF5 9D8A 4463
https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463

From SNaslund at medline.com  Thu Jul 28 17:26:26 2016
From: SNaslund at medline.com (Naslund, Steve)
Date: Thu, 28 Jul 2016 17:26:26 +0000
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <20160728171708.GA87119@e-fensive.net>
References: <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
Message-ID: <9578293AE169674F9A048B2BC9A081B401E6666D41@MUNPRDMBXA1.medline.com>

You obviously have a much shorter Internet memory than some of the engineers on here that have had a long history of killing off and blacklisting various spam and malware operations over the years.  I think the one thing that has changed is that the service providers are now large corporate entities that do not take going to war with each other as lightly as we did back in the day.

Steven Naslund
Chicago IL

>-----Original Message-----
>From: J. Oquendo [mailto:joquendo at e-fensive.net] 
>Sent: Thursday, July 28, 2016 12:17 PM
>To: Phil Rosenthal
>Cc: Naslund, Steve; nanog at nanog.org
>Subject: Cloudflare, dirty networks and politricks
>
>
>While many are chanting: #NetworkLivesMatter, I have yet to see, read, or hear about any network provider being the first to set precedence by either de-peering, or blocking traffic from Cloudflare. There is a lot of keyboard >posturing: "I am mad and I am not going to take it anymore" hooplah but no one is lifting a finger to do anything other than regurgitate "I am mad... This is criminal."
>
>Government in the US is not going to get involved as the financial cost won't warrant an investigation. Would you spend $100 to tow a car worth $1. Cloudflare, Amazon, Rackspace, and countless others are, and have been allowing the >same thing since the dawn of their creation and network operators... Shame on you for allowing it.
>
>It is legal? Is it moral? Does it serve a real world benefit? (booters). Let's get real these booters serve little purpose. Anyone can go back to romper room and do the simple math: I have a 100mb pipe, if someone sends me 200mb >will it flood me? A pre-schooler can give anyone the answer. Yet here is everyone chiming in on legal matters when not one respondent that I have seen is a lawyer.
>
>I wrote about this in my rambling which is linked in the NANOG LinkedIn group: "Why Do Networking Providers Like Cybercriminals So Much" and the responses I have read on this thread, make me believe it more so. Networking operators >could give a rats ass about doing anything about DDoS, viruses. etc., since it is a source of revenue down the daisy chain. Like it or not. I would be surprised if ANYONE in this NOG, or any other "NOG" de-peered out of principle. >With that said, I don't even know why this thread is being continued. 
>
>
>--
>=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
>J. Oquendo
>SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM


From joquendo at e-fensive.net  Thu Jul 28 17:35:14 2016
From: joquendo at e-fensive.net (J. Oquendo)
Date: Thu, 28 Jul 2016 12:35:14 -0500
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <9578293AE169674F9A048B2BC9A081B401E6666D41@MUNPRDMBXA1.medline.com>
References: <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
 <9578293AE169674F9A048B2BC9A081B401E6666D41@MUNPRDMBXA1.medline.com>
Message-ID: <20160728173514.GA88164@e-fensive.net>

On Thu, 28 Jul 2016, Naslund, Steve wrote:

> You obviously have a much shorter Internet memory than some of the engineers on here that have had a long history of killing off and blacklisting various spam and malware operations over the years.  I think the one thing that has changed is that the service providers are now large corporate entities that do not take going to war with each other as lightly as we did back in the day.
> 
> Steven Naslund
> Chicago IL

It is this same attitude that throws everything into the
loop we are seeing: "Well Mega Corporation is allowing it
and we can't stop them lest we want to go to war with
them." Define war. What will they do if you de-peer? They
will find another provider to peer with it. That is it.
There is no "war" no one is coming to our offices in full
military gear. The more you guys allow this, the more it
will continue.

Start de-peering companies similar to BGP Dampening. "Oh
didn't respond to our Nthousandth abuse. De-peered for N
amount of time. Increment the time, and when some of these
providers start seeing the cost of associating with these
types of crimes (spam, malware), they have a choice, ship
in or ship out. If ALL PROVIDERS did the same, who would
a dirty host have left to peer with?

Any other answer is nonsense and an excuse... "This will
start a war!!!" Nonsense and quite possibly the sorriest
excuse I have read for lifting a finger. 100 more people
with the same response, means nothing will ever get done.
OTOH ... Let's go back to "OMG THIS HAS TO STOP BUT I AM
NOT GOING TO BE THE ONE LIFTING A FINGER!!! Because...
ERMAHGERD WAR"



-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM

"Where ignorance is our master, there is no possibility of
real peace" - Dalai Lama

0B23 595C F07C 6092 8AEB  074B FC83 7AF5 9D8A 4463
https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463

From mcdonald.richards at gmail.com  Thu Jul 28 18:24:58 2016
From: mcdonald.richards at gmail.com (McDonald Richards)
Date: Thu, 28 Jul 2016 11:24:58 -0700
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <20160728173514.GA88164@e-fensive.net>
References: <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
 <9578293AE169674F9A048B2BC9A081B401E6666D41@MUNPRDMBXA1.medline.com>
 <20160728173514.GA88164@e-fensive.net>
Message-ID: <CACrsH-5eKXdSMp7BfL_YebcPW0-js5_tUyLXpS-TXp55-8yKjg@mail.gmail.com>

Be sure to let us all know how this works out for your business.

On Thu, Jul 28, 2016 at 10:35 AM, J. Oquendo <joquendo at e-fensive.net> wrote:

> On Thu, 28 Jul 2016, Naslund, Steve wrote:
>
> > You obviously have a much shorter Internet memory than some of the
> engineers on here that have had a long history of killing off and
> blacklisting various spam and malware operations over the years.  I think
> the one thing that has changed is that the service providers are now large
> corporate entities that do not take going to war with each other as lightly
> as we did back in the day.
> >
> > Steven Naslund
> > Chicago IL
>
> It is this same attitude that throws everything into the
> loop we are seeing: "Well Mega Corporation is allowing it
> and we can't stop them lest we want to go to war with
> them." Define war. What will they do if you de-peer? They
> will find another provider to peer with it. That is it.
> There is no "war" no one is coming to our offices in full
> military gear. The more you guys allow this, the more it
> will continue.
>
> Start de-peering companies similar to BGP Dampening. "Oh
> didn't respond to our Nthousandth abuse. De-peered for N
> amount of time. Increment the time, and when some of these
> providers start seeing the cost of associating with these
> types of crimes (spam, malware), they have a choice, ship
> in or ship out. If ALL PROVIDERS did the same, who would
> a dirty host have left to peer with?
>
> Any other answer is nonsense and an excuse... "This will
> start a war!!!" Nonsense and quite possibly the sorriest
> excuse I have read for lifting a finger. 100 more people
> with the same response, means nothing will ever get done.
> OTOH ... Let's go back to "OMG THIS HAS TO STOP BUT I AM
> NOT GOING TO BE THE ONE LIFTING A FINGER!!! Because...
> ERMAHGERD WAR"
>
>
>
> --
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
> J. Oquendo
> SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM
>
> "Where ignorance is our master, there is no possibility of
> real peace" - Dalai Lama
>
> 0B23 595C F07C 6092 8AEB  074B FC83 7AF5 9D8A 4463
> https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463
>

From joquendo at e-fensive.net  Thu Jul 28 18:39:50 2016
From: joquendo at e-fensive.net (J. Oquendo)
Date: Thu, 28 Jul 2016 13:39:50 -0500
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <CACrsH-5eKXdSMp7BfL_YebcPW0-js5_tUyLXpS-TXp55-8yKjg@mail.gmail.com>
References: <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
 <9578293AE169674F9A048B2BC9A081B401E6666D41@MUNPRDMBXA1.medline.com>
 <20160728173514.GA88164@e-fensive.net>
 <CACrsH-5eKXdSMp7BfL_YebcPW0-js5_tUyLXpS-TXp55-8yKjg@mail.gmail.com>
Message-ID: <20160728183950.GA91416@e-fensive.net>

On Thu, 28 Jul 2016, McDonald Richards wrote:

> Be sure to let us all know how this works out for your business.
> 
> On Thu, Jul 28, 2016 at 10:35 AM, J. Oquendo <joquendo at e-fensive.net> wrote:
> 

As stated... "Networkers don't give a rats ass about
ethics/morals. Solely a fistful of dollars"

In the interim, this conversation differs little from
fergdawg's "How to Handle ISPs Who Turn a Blind Eye to
Criminal Activity?"

https://www.nanog.org/mailinglist/mailarchives/old_archive/2007-10/msg00348.html

Back to what matters now... Money, because cybercrime meh.

-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM

"Where ignorance is our master, there is no possibility of
real peace" - Dalai Lama

0B23 595C F07C 6092 8AEB  074B FC83 7AF5 9D8A 4463
https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463

From list at satchell.net  Thu Jul 28 18:52:02 2016
From: list at satchell.net (Stephen Satchell)
Date: Thu, 28 Jul 2016 11:52:02 -0700
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <20160728171708.GA87119@e-fensive.net>
References: <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
Message-ID: <b567d949-0e2b-e2a5-1d93-5d1786b9027a@satchell.net>

On 07/28/2016 10:17 AM, J. Oquendo wrote:
> While many are chanting: #NetworkLivesMatter, I have yet
> to see, read, or hear about any network provider being
> the first to set precedence by either de-peering, or
> blocking traffic from Cloudflare. There is a lot of
> keyboard posturing: "I am mad and I am not going to take
> it anymore" hooplah but no one is lifting a finger to
> do anything other than regurgitate "I am mad... This is
> criminal."

Let's supposed someone did indeed de-peer or otherwise block Cloudflare 
from their entire network.

Which of y'all would be the first to say to that network operator, "Hope 
you enjoy your intranet"?

From sethm at rollernet.us  Thu Jul 28 18:52:06 2016
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 28 Jul 2016 11:52:06 -0700
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <CACrsH-5eKXdSMp7BfL_YebcPW0-js5_tUyLXpS-TXp55-8yKjg@mail.gmail.com>
References: <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
 <9578293AE169674F9A048B2BC9A081B401E6666D41@MUNPRDMBXA1.medline.com>
 <20160728173514.GA88164@e-fensive.net>
 <CACrsH-5eKXdSMp7BfL_YebcPW0-js5_tUyLXpS-TXp55-8yKjg@mail.gmail.com>
Message-ID: <220251a1-e93e-fc74-2e4e-9ff2a468259a@rollernet.us>

On 7/28/16 11:24, McDonald Richards wrote:
> Be sure to let us all know how this works out for your business.


And that's why these problems are such as they are.

~Seth

From mcdonald.richards at gmail.com  Thu Jul 28 19:01:00 2016
From: mcdonald.richards at gmail.com (McDonald Richards)
Date: Thu, 28 Jul 2016 12:01:00 -0700
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <220251a1-e93e-fc74-2e4e-9ff2a468259a@rollernet.us>
References: <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
 <9578293AE169674F9A048B2BC9A081B401E6666D41@MUNPRDMBXA1.medline.com>
 <20160728173514.GA88164@e-fensive.net>
 <CACrsH-5eKXdSMp7BfL_YebcPW0-js5_tUyLXpS-TXp55-8yKjg@mail.gmail.com>
 <220251a1-e93e-fc74-2e4e-9ff2a468259a@rollernet.us>
Message-ID: <CACrsH-4suky2PQhTe-0DvL8kqAL_2QAuUrUCdon5xNe=tsURrw@mail.gmail.com>

Feel free to demonstrate to us all how you're leading by example.

Until then, as a consumer of "the Internet", I'd like my any-to-any access
to remain that way.



On Thu, Jul 28, 2016 at 11:52 AM, Seth Mattinen <sethm at rollernet.us> wrote:

> On 7/28/16 11:24, McDonald Richards wrote:
>
>> Be sure to let us all know how this works out for your business.
>>
>
>
> And that's why these problems are such as they are.
>
> ~Seth
>

From joquendo at e-fensive.net  Thu Jul 28 19:03:50 2016
From: joquendo at e-fensive.net (J. Oquendo)
Date: Thu, 28 Jul 2016 14:03:50 -0500
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <b567d949-0e2b-e2a5-1d93-5d1786b9027a@satchell.net>
References: <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
 <b567d949-0e2b-e2a5-1d93-5d1786b9027a@satchell.net>
Message-ID: <20160728190350.GA92226@e-fensive.net>

On Thu, 28 Jul 2016, Stephen Satchell wrote:

> Let's supposed someone did indeed de-peer or otherwise block Cloudflare 
> from their entire network.
> 
> Which of y'all would be the first to say to that network operator, "Hope 
> you enjoy your intranet"?

Really? Again more boogeyman nonsense. The world does not
revolve around Cloudflare or any other provider. If I were
a customer, and my customers could not reach me, I would
go to my provider. If I discovered my provider was being
unethical in their practice, I would be an idiot to stay
with them. "Hey its ok for me to conduct eCommerce
transactions. I mean they're only allowing DoS, malware,
ransomware."

Tell me how would that work for you when your clients
started jumping ship because your network is dirty. Again
I go back to square one... The responders ("No you can
never!!!") are those who truly could care less about the
current state of garbage on the net. Masquerading it along
the lines of:

"Ermahgerd WAR!!!"
"OMG YOU WILL ONLY HAVE AN INTRANET"
"You can't be serious!!!"


-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM

"Where ignorance is our master, there is no possibility of
real peace" - Dalai Lama

0B23 595C F07C 6092 8AEB  074B FC83 7AF5 9D8A 4463
https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463

From randy at psg.com  Thu Jul 28 19:09:44 2016
From: randy at psg.com (Randy Bush)
Date: Fri, 29 Jul 2016 04:09:44 +0900
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <CAL9jLaZ3jAGESfdLe1O-FKsXuOptsZKLO4oSe1cEEbjY9RPgJA@mail.gmail.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <b0fe8104-ff68-e18d-c738-944fbb515d91@meetinghouse.net>
 <CAL9jLaZ3jAGESfdLe1O-FKsXuOptsZKLO4oSe1cEEbjY9RPgJA@mail.gmail.com>
Message-ID: <m27fc5ziiv.wl%randy@psg.com>

>> Actually, as someone pointed out, it might well be conspiracy - which
>> is criminal.
> looking forward to the court case, if it's really important it'll
> happen shortly, right?

we don't need no flippin' court.  we can lynch 'em right here.

From sethm at rollernet.us  Thu Jul 28 19:11:18 2016
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 28 Jul 2016 12:11:18 -0700
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <CACrsH-4suky2PQhTe-0DvL8kqAL_2QAuUrUCdon5xNe=tsURrw@mail.gmail.com>
References: <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
 <9578293AE169674F9A048B2BC9A081B401E6666D41@MUNPRDMBXA1.medline.com>
 <20160728173514.GA88164@e-fensive.net>
 <CACrsH-5eKXdSMp7BfL_YebcPW0-js5_tUyLXpS-TXp55-8yKjg@mail.gmail.com>
 <220251a1-e93e-fc74-2e4e-9ff2a468259a@rollernet.us>
 <CACrsH-4suky2PQhTe-0DvL8kqAL_2QAuUrUCdon5xNe=tsURrw@mail.gmail.com>
Message-ID: <81be7000-4c92-f13e-1a17-2e42fae011c9@rollernet.us>

On 7/28/16 12:01, McDonald Richards wrote:
> Feel free to demonstrate to us all how you're leading by example.
>
> Until then, as a consumer of "the Internet", I'd like my any-to-any access
> to remain that way.


Again, and that's why these problems are such as they are.

~Seth

From bzs at theworld.com  Thu Jul 28 19:22:05 2016
From: bzs at theworld.com (bzs at theworld.com)
Date: Thu, 28 Jul 2016 15:22:05 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
Message-ID: <22426.23389.18392.609810@gargle.gargle.HOWL>


The difference between everyone posting here and for example the
intellectual property folks like RIAA is the latter has organization
and money.

As I said earlier one thing that organization and money has done is
defined, with some precision, where the boundaries are. It's a moving
target but that's a lot better than nothing.

And money for lobbyists etc to go to govts and courts to impress them
with their point of view and even get it written into law and
precedents.

It's not perfect, nothing is, but when someone puts up a music sharing
service with a million recordings none authorized in Lower Slobbovia
they usually manage to get it shut down (that happens, ok not Lower
Slobbovia exactly.)

Something else they get is budget assigned to law enforcement agencies
to pursue those commercial violations.

I remember speaking early on to someone in an FBI office about spam
and related, this was probably ca 2000, and he completely sympathized
but said sorry, the FBI has no budget to pursue such things.

Like many very nice people you think LEAs pursue crimes merely because
they are crimes. That the money to do so just appears on demand
because IT'S A CRIME! Book 'em Dan-o!

Hah! I'll repeat that. Hah!

These are commercial crimes not terrorism or kidnapping or murder or
tearing those labels off mattresses.

Much more difficult to get on LEAs radar.

On the darker side be careful what you wish for.

You won't personally be defining these boundaries. People like
lobbyists and policy wonks and legislators will. People this
hypothetical organization hires and those influenced by those
hires. People who can spend full time wordsmithing all this and
getting attention.

It takes very active involvement to steer good intentions to good
results and not just end up with scattershot gibberish or worse
overbearing laws which do more harm than good.

And that all takes organization and money and involvement not postings
on NANOG except inasmuch as they might lead to organization and money
etc.

It's possible and maybe even desirable but what I see here ain't it.

-- 
        -Barry Shein

Software Tool & Die    | bzs at TheWorld.com             | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

From dwessels at verisign.com  Thu Jul 28 22:37:39 2016
From: dwessels at verisign.com (Wessels, Duane)
Date: Thu, 28 Jul 2016 22:37:39 +0000
Subject: Root Zone DNSSEC Operational Update -- ZSK length change
Message-ID: <E7ACD441-57F6-4DD0-985E-6751E5B3D35C@verisign.com>

As you may know, Verisign, in its role as the Root Zone Maintainer
is also the operator of the root zone Zone Signing Key (ZSK).  Later
this year, we will increase the size of the ZSK from 1024-bits to
2048-bits.

The root zone ZSK is normally rolled every calendar quarter, as per
our ?DNSSEC Practice Statement for the Root Zone ZSK operator.?[1]
The ZSK public keys are signed at quarterly key signing ceremonies
by ICANN in its role as the IANA Functions Operator.

On September 20, 2016 the 2048-bit ZSK will be pre-published in the
root zone, following the standard ZSK rollover procedure.  We intend
to begin publishing root zones signed with the first 2048-bit ZSK
on October 1, 2016.

Some details of the ZSK size transition have recently been presented
at the DNS-OARC, NANOG, RIPE, ICANN, and IETF meetings.[2]  If you
have any questions or concerns, please feel free to contact us at
zms at verisign.com.

Please feel free to forward this message to anyone who might not have
seen it here.

[1] https://www.verisign.com/assets/dps-zsk-operator-1532.pdf
[2] https://ripe72.ripe.net/wp-content/uploads/presentations/168-verisign-zsk-change.pdf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160728/7917e8c2/attachment.pgp>

From D.Lasher at f5.com  Thu Jul 28 23:30:12 2016
From: D.Lasher at f5.com (Donn Lasher)
Date: Thu, 28 Jul 2016 23:30:12 +0000
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <20160728171708.GA87119@e-fensive.net>
References: <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
Message-ID: <28E6FC71-F6FF-49B9-B861-3B573372594F@f5.com>

On 7/28/16, 10:17 AM, "NANOG on behalf of J. Oquendo" <nanog-bounces at nanog.org on behalf of joquendo at e-fensive.net> wrote:


>While many are chanting: #NetworkLivesMatter, I have yet
>to see, read, or hear about any network provider being
>the first to set precedence by either de-peering, or
>blocking traffic from Cloudflare. There is a lot of
>keyboard posturing: "I am mad and I am not going to take
>it anymore" hooplah but no one is lifting a finger to
>do anything other than regurgitate "I am mad... This is
>criminal."

(long discussion, was waiting for a place to jump in..)

If we want to be accurate about it, Cloudflare doesn?t host the DDoS, they protect the website of seller of the product. We shouldn?t be de-peering Cloud Flare over sites they protect any more than we would de-peer GoDaddy over sites they host, some of which, no doubt, sell gray/black market/illegal items/services.

If, on the other hand,  you can find a specific network actually generating the volumes of DDoS, you should have a conversation about de-peering?.

$0.02?







From tshaw at oitc.com  Thu Jul 28 23:45:14 2016
From: tshaw at oitc.com (TR Shaw)
Date: Thu, 28 Jul 2016 19:45:14 -0400
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <28E6FC71-F6FF-49B9-B861-3B573372594F@f5.com>
References: <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
 <28E6FC71-F6FF-49B9-B861-3B573372594F@f5.com>
Message-ID: <86BCDE1A-A2A5-45D8-9142-5F4A0AEA36E2@oitc.com>


> On Jul 28, 2016, at 7:30 PM, Donn Lasher via NANOG <nanog at nanog.org> wrote:
> 
> On 7/28/16, 10:17 AM, "NANOG on behalf of J. Oquendo" <nanog-bounces at nanog.org on behalf of joquendo at e-fensive.net> wrote:
> 
> 
>> While many are chanting: #NetworkLivesMatter, I have yet
>> to see, read, or hear about any network provider being
>> the first to set precedence by either de-peering, or
>> blocking traffic from Cloudflare. There is a lot of
>> keyboard posturing: "I am mad and I am not going to take
>> it anymore" hooplah but no one is lifting a finger to
>> do anything other than regurgitate "I am mad... This is
>> criminal."
> 
> (long discussion, was waiting for a place to jump in..)
> 
> If we want to be accurate about it, Cloudflare doesn?t host the DDoS, they protect the website of seller of the product. We shouldn?t be de-peering Cloud Flare over sites they protect any more than we would de-peer GoDaddy over sites they host, some of which, no doubt, sell gray/black market/illegal items/services.
> 
> If, on the other hand,  you can find a specific network actually generating the volumes of DDoS, you should have a conversation about de-peering?.
> 
> $0.02?
> 

It would be nice however if Cloudflare would announce there ?freebie? ciders and the IP block that host their paying customers. Most of the abuse centers on the free clients.


From owen at delong.com  Fri Jul 29 00:21:22 2016
From: owen at delong.com (Owen DeLong)
Date: Thu, 28 Jul 2016 20:21:22 -0400
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <28E6FC71-F6FF-49B9-B861-3B573372594F@f5.com>
References: <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
 <28E6FC71-F6FF-49B9-B861-3B573372594F@f5.com>
Message-ID: <5565B93C-28C7-46F6-A836-E539EAA0267D@delong.com>


> On Jul 28, 2016, at 7:30 PM, Donn Lasher via NANOG <nanog at nanog.org> wrote:
> 
> On 7/28/16, 10:17 AM, "NANOG on behalf of J. Oquendo" <nanog-bounces at nanog.org on behalf of joquendo at e-fensive.net> wrote:
> 
> 
>> While many are chanting: #NetworkLivesMatter, I have yet
>> to see, read, or hear about any network provider being
>> the first to set precedence by either de-peering, or
>> blocking traffic from Cloudflare. There is a lot of
>> keyboard posturing: "I am mad and I am not going to take
>> it anymore" hooplah but no one is lifting a finger to
>> do anything other than regurgitate "I am mad... This is
>> criminal."
> 
> (long discussion, was waiting for a place to jump in..)
> 
> If we want to be accurate about it, Cloudflare doesn?t host the DDoS, they protect the website of seller of the product. We shouldn?t be de-peering Cloud Flare over sites they protect any more than we would de-peer GoDaddy over sites they host, some of which, no doubt, sell gray/black market/illegal items/services.
> 
> If, on the other hand,  you can find a specific network actually generating the volumes of DDoS, you should have a conversation about de-peering?.
> 
> $0.02?

On one hand, I agree with you? ?We should no more de-peer Cloud Flare over sites they protect than we would de-peer GoDaddy over sites they host.?

However, if GoDaddy or Cloud Flare consistently refused to take down sites which specifically sell malicious activities as a service, I see no reason not to consider de-peering either one of them.

I?m not well enough versed in the exact details of the alleged actions/non-actions of CF in this scenario, but the idea that we should not apply rational peer pressure against the accessible indirect party in favor of playing whack-a-mole with the less accessible directly offending party seems patently absurd to me.

The actual dDOS is probably not even performed by the company advertising the service, but rather by one ore more bot-nets that they either directly control (pwn, but don?t own) or contract (someone else pwned the machines and sells bot services to them).

It?s one thing if a site is advertising legitimate load or stress testing abilities and is conducting itself in an ethical manner.

Its an entirely different matter if the site is advertising their ability to carry out malicious attacks for hire (e.g. ?We can take down XYZ for mere pennies per hour.?, etc.).

In the latter case, I would expect any ethical company that found themselves hosting such content to take swift action against such a customer for TOS/AUP violation. In the former, there?s likely nothing wrong there and while you may not like what they do, it may well be a legitimate service, none-the-less.

Now there is a bit of a grey area which probably merits consideration? What if company A runs a web-site. They are a transit customer of company B. Company C is the VPS hosting company which is under contract to company D to provide machines and bandwidth for their ?Security Testing Products.?.

(Quick cheat-diagram to make the rest easier to follow)
[Web Site A] <-> [Transit B] <-> {internet} <-> [VPS Host C] <-> [?Security Contractor? D]

Suppose company A dramatically overestimates their needed stress level for a traffic test and contracts company D to send them a stress test which turns out to overwhelm the peering between B and C.

Clearly, this is problematic to both B and C, but it?s not clear that it?s an actual violation or that either A or D has actually done anything wrong, per se. I would expect D to cease and desist promptly upon notification from C or A. Ideally they would also politely cease and desist upon credible request from company B, but the definition of credible is somewhat difficult here and may be subjective (B will generally consider themselves credible whether C does or not).

The problem may extend further, depending on whether B and C are directly peered or are connected via some additional set of transit networks in between. (see footnote [1]  for exact definitions of peering and transit intended in this message. Short version: packet flow, not money).

Obviously the more transit networks impacted, the more complex the issue becomes.

Owen

[1]
peering: The advertising of routes to and acceptance of packets for ones own autonomous system(s) and those autonomous systems for which you provide transit.
transit: The advertising of all known routes, default, or some superset of the above definition of peering and the willingness to accept, carry, and pass along packets destined to other peers and/or transit providers beyond the limits set by peering above.



From cb.list6 at gmail.com  Fri Jul 29 00:34:39 2016
From: cb.list6 at gmail.com (Ca By)
Date: Thu, 28 Jul 2016 17:34:39 -0700
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <28E6FC71-F6FF-49B9-B861-3B573372594F@f5.com>
References: <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
 <28E6FC71-F6FF-49B9-B861-3B573372594F@f5.com>
Message-ID: <CAD6AjGSWo+Oj0FyUZVATa-cZyJpBWbaWdq75+tXb-UatVW+z5Q@mail.gmail.com>

On Thursday, July 28, 2016, Donn Lasher via NANOG <nanog at nanog.org> wrote:

> On 7/28/16, 10:17 AM, "NANOG on behalf of J. Oquendo" <
> nanog-bounces at nanog.org <javascript:;> on behalf of joquendo at e-fensive.net
> <javascript:;>> wrote:
>
>
> >While many are chanting: #NetworkLivesMatter, I have yet
> >to see, read, or hear about any network provider being
> >the first to set precedence by either de-peering, or
> >blocking traffic from Cloudflare. There is a lot of
> >keyboard posturing: "I am mad and I am not going to take
> >it anymore" hooplah but no one is lifting a finger to
> >do anything other than regurgitate "I am mad... This is
> >criminal."
>
> (long discussion, was waiting for a place to jump in..)
>
> If we want to be accurate about it, Cloudflare doesn?t host the DDoS, they
> protect the website of seller of the product. We shouldn?t be de-peering
> Cloud Flare over sites they protect any more than we would de-peer GoDaddy
> over sites they host, some of which, no doubt, sell gray/black
> market/illegal items/services.
>
> If, on the other hand,  you can find a specific network actually
> generating the volumes of DDoS, you should have a conversation about
> de-peering?.
>
> $0.02?
>
>
>
Agreed. Cloudflare is just the messenger

The ddos is coming from your ssdp, dns, and ntp servers. Not Cloudflare.

I see a lot of ddos traffic.

It is always udp

Comcast took a huge step in stemming the ssdp problem in their network,
http://labs.comcast.com/preventing-ssdp-abuse

Thanks Comcast!

But they still host tens of thousands, perhaps more, open dns resolvers
that attack us.

From surfer at mauigateway.com  Fri Jul 29 01:28:37 2016
From: surfer at mauigateway.com (Scott Weeks)
Date: Thu, 28 Jul 2016 18:28:37 -0700
Subject: EVERYTHING about Booters (and CloudFlare)
Message-ID: <20160728182837.7611C8EA@m0087797.ppops.net>



--- tknchris at gmail.com wrote:

They don't discriminate, anyone can be a customer
https://www.youtube.com/watch?v=T4GfoSZ_sDc

great quote from the reporter "why do you need a 
court order to do the right thing?"
------------------------------------------


Holy crap that girl was painful to listen to!

scott

From dovid at telecurve.com  Fri Jul 29 01:29:20 2016
From: dovid at telecurve.com (Dovid Bender)
Date: Fri, 29 Jul 2016 01:29:20 +0000
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <86BCDE1A-A2A5-45D8-9142-5F4A0AEA36E2@oitc.com>
References: <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
 <28E6FC71-F6FF-49B9-B861-3B573372594F@f5.com>
 <86BCDE1A-A2A5-45D8-9142-5F4A0AEA36E2@oitc.com>
Message-ID: <300752684-1469755760-cardhu_decombobulator_blackberry.rim.net-1819398455-@b16.c1.bise6.blackberry>

The issue is that cloudfare in a way is generating their own market. If the ddos sites weren't protected by cloudfare they would eat each other alive. It's in their interest that their sites stay up so there is a need for their service. When GoDaddy hosts a bad site they aren't causing customer to sign up for the exact service for the protection they need from the bad site.

  
Regards,

Dovid

-----Original Message-----
From: TR Shaw <tshaw at oitc.com>
Sender: "NANOG" <nanog-bounces at nanog.org>Date: Thu, 28 Jul 2016 19:45:14 
To: Donn Lasher<D.Lasher at f5.com>
Cc: nanog at nanog.org<nanog at nanog.org>
Subject: Re: Cloudflare, dirty networks and politricks


> On Jul 28, 2016, at 7:30 PM, Donn Lasher via NANOG <nanog at nanog.org> wrote:
> 
> On 7/28/16, 10:17 AM, "NANOG on behalf of J. Oquendo" <nanog-bounces at nanog.org on behalf of joquendo at e-fensive.net> wrote:
> 
> 
>> While many are chanting: #NetworkLivesMatter, I have yet
>> to see, read, or hear about any network provider being
>> the first to set precedence by either de-peering, or
>> blocking traffic from Cloudflare. There is a lot of
>> keyboard posturing: "I am mad and I am not going to take
>> it anymore" hooplah but no one is lifting a finger to
>> do anything other than regurgitate "I am mad... This is
>> criminal."
> 
> (long discussion, was waiting for a place to jump in..)
> 
> If we want to be accurate about it, Cloudflare doesn?t host the DDoS, they protect the website of seller of the product. We shouldn?t be de-peering Cloud Flare over sites they protect any more than we would de-peer GoDaddy over sites they host, some of which, no doubt, sell gray/black market/illegal items/services.
> 
> If, on the other hand,  you can find a specific network actually generating the volumes of DDoS, you should have a conversation about de-peering?.
> 
> $0.02?
> 

It would be nice however if Cloudflare would announce there ?freebie? ciders and the IP block that host their paying customers. Most of the abuse centers on the free clients.


From cb.list6 at gmail.com  Fri Jul 29 03:20:54 2016
From: cb.list6 at gmail.com (Ca By)
Date: Thu, 28 Jul 2016 20:20:54 -0700
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <300752684-1469755760-cardhu_decombobulator_blackberry.rim.net-1819398455-@b16.c1.bise6.blackberry>
References: <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
 <28E6FC71-F6FF-49B9-B861-3B573372594F@f5.com>
 <86BCDE1A-A2A5-45D8-9142-5F4A0AEA36E2@oitc.com>
 <300752684-1469755760-cardhu_decombobulator_blackberry.rim.net-1819398455-@b16.c1.bise6.blackberry>
Message-ID: <CAD6AjGSrGc_H4rhUFTB6YYv7rzjkSskVy5TBH0GpbOzNB-p0qw@mail.gmail.com>

On Thursday, July 28, 2016, Dovid Bender <dovid at telecurve.com> wrote:

> The issue is that cloudfare in a way is generating their own market. If
> the ddos sites weren't protected by cloudfare they would eat each other
> alive. It's in their interest that their sites stay up so there is a need
> for their service. When GoDaddy hosts a bad site they aren't causing
> customer to sign up for the exact service for the protection they need from
> the bad site.
>
>
>
I feel the same way about all the ddos protection rackets. But i genuinely
feel Cloudflare is just a cdn that got good at fending off ddos just to
stay alive.

And they do a lot of good things with IPv6, dnssec, TLS 1.2++ , and open
source. It is not fair to blame them for our (network operators)
negligent open udp ampliers.

We are the real problems.

If Cloudflare did not host them, someone else would.

Perhaps only on tor.

But once you remove the open dns amplifiers, or put up the appropriate acls
(bcp38 + blocks obviously abused ssdp, dns, ntp to the extent you can)   ,
then you have really taking ddos capacity offline




> Regards,
>
> Dovid
>
> -----Original Message-----
> From: TR Shaw <tshaw at oitc.com <javascript:;>>
> Sender: "NANOG" <nanog-bounces at nanog.org <javascript:;>>Date: Thu, 28 Jul
> 2016 19:45:14
> To: Donn Lasher<D.Lasher at f5.com <javascript:;>>
> Cc: nanog at nanog.org <javascript:;><nanog at nanog.org <javascript:;>>
> Subject: Re: Cloudflare, dirty networks and politricks
>
>
> > On Jul 28, 2016, at 7:30 PM, Donn Lasher via NANOG <nanog at nanog.org
> <javascript:;>> wrote:
> >
> > On 7/28/16, 10:17 AM, "NANOG on behalf of J. Oquendo" <
> nanog-bounces at nanog.org <javascript:;> on behalf of joquendo at e-fensive.net
> <javascript:;>> wrote:
> >
> >
> >> While many are chanting: #NetworkLivesMatter, I have yet
> >> to see, read, or hear about any network provider being
> >> the first to set precedence by either de-peering, or
> >> blocking traffic from Cloudflare. There is a lot of
> >> keyboard posturing: "I am mad and I am not going to take
> >> it anymore" hooplah but no one is lifting a finger to
> >> do anything other than regurgitate "I am mad... This is
> >> criminal."
> >
> > (long discussion, was waiting for a place to jump in..)
> >
> > If we want to be accurate about it, Cloudflare doesn?t host the DDoS,
> they protect the website of seller of the product. We shouldn?t be
> de-peering Cloud Flare over sites they protect any more than we would
> de-peer GoDaddy over sites they host, some of which, no doubt, sell
> gray/black market/illegal items/services.
> >
> > If, on the other hand,  you can find a specific network actually
> generating the volumes of DDoS, you should have a conversation about
> de-peering?.
> >
> > $0.02?
> >
>
> It would be nice however if Cloudflare would announce there ?freebie?
> ciders and the IP block that host their paying customers. Most of the abuse
> centers on the free clients.
>
>

From randy at psg.com  Fri Jul 29 03:30:51 2016
From: randy at psg.com (Randy Bush)
Date: Fri, 29 Jul 2016 12:30:51 +0900
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <20160728182837.7611C8EA@m0087797.ppops.net>
References: <20160728182837.7611C8EA@m0087797.ppops.net>
Message-ID: <m2vazpxgr8.wl%randy@psg.com>

>> They don't discriminate, anyone can be a customer
>> https://www.youtube.com/watch?v=T4GfoSZ_sDc
> 
> Holy crap that girl was painful to listen to!

missed the girl.  all i saw was prince and a fox 'news' woman.  it was
pretty much like reading nanog.

randy

From saku at ytti.fi  Fri Jul 29 08:25:54 2016
From: saku at ytti.fi (Saku Ytti)
Date: Fri, 29 Jul 2016 11:25:54 +0300
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
Message-ID: <CAAeewD9owkk76VnKUZf7a+cUt8vour58r2m6e111fcUJCnZywQ@mail.gmail.com>

On 28 July 2016 at 19:27, chris <tknchris at gmail.com> wrote:
> They don't discriminate, anyone can be a customer
> https://www.youtube.com/watch?v=T4GfoSZ_sDc
>
> great quote from the reporter "why do you need a court order to do the
> right thing?"

Only failure here is accepting interview request from FOX. Who obvious
just want to be sensational rather than have an actual discussion.

-- 
  ++ytti

From rsk at gsp.org  Fri Jul 29 12:08:05 2016
From: rsk at gsp.org (Rich Kulawiec)
Date: Fri, 29 Jul 2016 08:08:05 -0400
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <28E6FC71-F6FF-49B9-B861-3B573372594F@f5.com>
References: <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
 <28E6FC71-F6FF-49B9-B861-3B573372594F@f5.com>
Message-ID: <20160729120805.GA5869@gsp.org>

On Thu, Jul 28, 2016 at 11:30:12PM +0000, Donn Lasher via NANOG wrote:
> If we want to be accurate about it, Cloudflare doesn???t host the DDoS,
> they protect the website of seller of the product. We shouldn???t be
> de-peering Cloud Flare over sites they protect any more than we would
> de-peer GoDaddy over sites they host, some of which, no doubt, sell
> gray/black market/illegal items/services.

This strategy fails for two reasons.

First, nobody gets a pass.  Anybody providing services to abusers
needs to cut them off, whether it's a registrar, a web host, an email
provider, a DNS provider, or anything else.  Nobody gets to shrug it
off with "Well, but..."

Second, nobody *can* get a pass, because the people behind these operations
have long since learned to distribute their assets widely -- in an attempt
to avoid exactly the actions in the first point.  And you know what?
It works.  "We're just hosting their email", says X, and "We're just
hosting their DNS", says Y, and "We're just hosting their web site",
says Z, and none of them do anything, and nothing gets done. 

The only way to make action against them effective is to do it broadly,
do it swiftly, and do it permanently.

---rsk

From joquendo at e-fensive.net  Fri Jul 29 12:50:09 2016
From: joquendo at e-fensive.net (J. Oquendo)
Date: Fri, 29 Jul 2016 07:50:09 -0500
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <20160729120805.GA5869@gsp.org>
References: <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
 <28E6FC71-F6FF-49B9-B861-3B573372594F@f5.com>
 <20160729120805.GA5869@gsp.org>
Message-ID: <20160729125009.GA42429@e-fensive.net>

On Fri, 29 Jul 2016, Rich Kulawiec wrote:

> On Thu, Jul 28, 2016 at 11:30:12PM +0000, Donn Lasher via NANOG wrote:
> > If we want to be accurate about it, Cloudflare doesn???t host the DDoS,
> > they protect the website of seller of the product. We shouldn???t be
> > de-peering Cloud Flare over sites they protect any more than we would
> > de-peer GoDaddy over sites they host, some of which, no doubt, sell
> > gray/black market/illegal items/services.
> 
> The only way to make action against them effective is to do it broadly,
> do it swiftly, and do it permanently.
> 

In my ramblings on "Why network operators love filth", I
associate a landlord that knowingly allows his/her tenant
to sell drugs. In America, your house is gone. This should
be the case on the Internet as well. Keep sending out crap
and ARIN should yank your IP space after everyone else
has de-peered you.

So let's get to these horrible analogies of "weapons" and
whether or not CloudFlare is solely the gun manufacturer
and is not responsible whether or not their ARCLOUD rifle
was used to shoot up a school killing children.

Analogy: Hotel Cloud is a pretty big hotel in the city.
They have 5,000 rooms. When you walk by, their tenants
are throwing rocks out of the windows, garbage, etc.
People complain to the hotel management that does nothing
about it. Hotel Cloud's response is: 'Well this is really
not our problem, we only rent a room, what the occupant
does...' --- And this makes sense to how many of you who'd
respond: "Well I don't know about you but I want to walk
around freely" Freely? At some point in time, you WILL
walk by this hotel, or another that WILL become just like
it. Why? Because there will be no one to say: "Hey this
is wrong buck stops here..."

I have seen these discussions on this list for so many
years, and there are those that want to do good, but won't
lift a finger out of fear of the herd/praetorian guard.
Anyone saying it cannot be done, is a coward bowing to
the dollar (euro/yen/whatever). The analogy above is spot
on, with the only difference being a hotel is physical,
and on the Interwebs, out of sight out of mind. This is
until one of your relatives' sites gets taken offline by
some bored moron via DDoS, and there go their sales, there
goes their business. THEN and only THEN will some of the
naysayers say: "Shit we could have stopped it."

Do you need law enforcement to be moral? "I can see
that person is getting pulverized by some drunken idiot
better not intervene because well... I want to walk
freely..." That beating can come full circle, where
beating can be DDoS, a sophisticated attack, malware.

I am so tempted to start a shaming site for networks
including all of the big boys with detailed records
showing how abuse was contacted, no one did nothing,
and oh by the way... "Are you sure you want to host
or transit with this company? Last I checked via
logs, they were a filthy network that catered to
peds, RBN folk, etc" Maybe when some of you guys
(that sit around twiddling fingers) see your companies
all over the place, maybe then you'll think about doing
the right thing.


-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM

"Where ignorance is our master, there is no possibility of
real peace" - Dalai Lama

0B23 595C F07C 6092 8AEB  074B FC83 7AF5 9D8A 4463
https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463

From randy at psg.com  Fri Jul 29 13:03:41 2016
From: randy at psg.com (Randy Bush)
Date: Fri, 29 Jul 2016 22:03:41 +0900
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <CAAeewD9owkk76VnKUZf7a+cUt8vour58r2m6e111fcUJCnZywQ@mail.gmail.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <CAAeewD9owkk76VnKUZf7a+cUt8vour58r2m6e111fcUJCnZywQ@mail.gmail.com>
Message-ID: <m2eg6cy4sy.wl%randy@psg.com>

> great quote from the reporter "why do you need a court order to do the
> right thing?"

because i am not judge and jury.  we leave that to network technicians.

randy

From SNaslund at medline.com  Fri Jul 29 13:28:25 2016
From: SNaslund at medline.com (Naslund, Steve)
Date: Fri, 29 Jul 2016 13:28:25 +0000
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <m2eg6cy4sy.wl%randy@psg.com>
References: <31050b39-6c4e-3cad-4429-3eb7eea9e4de@utwente.nl>
 <CAJayEpErus=H-+wE+pH4Am10pc4i8_pFJcmqRprYr-O=2QMg8A@mail.gmail.com>
 <m2popz2kqj.wl%randy@psg.com>
 <CY1PR07MB220000E95084743D26344C21FA0F0@CY1PR07MB2200.namprd07.prod.outlook.com>
 <CAPkb-7CwhN=KKgG=iKH6whVHQbDwxGYT0288wJTFU90tGkpJAA@mail.gmail.com>
 <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <CAAeewD9owkk76VnKUZf7a+cUt8vour58r2m6e111fcUJCnZywQ@mail.gmail.com>
 <m2eg6cy4sy.wl%randy@psg.com>
Message-ID: <9578293AE169674F9A048B2BC9A081B401E666866D@MUNPRDMBXA1.medline.com>

What he said.  If I am given a court order and follow it, I can't get sued when I knock you off the Internet.

Steven Naslund

>-----Original Message-----
>From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy Bush
>Sent: Friday, July 29, 2016 8:04 AM
>To: chris
>Cc: North American Network Operators' Group
>Subject: Re: EVERYTHING about Booters (and CloudFlare)

> great quote from the reporter "why do you need a court order to do the 
> right thing?"

>because i am not judge and jury.  we leave that to network technicians.

>randy

From joquendo at e-fensive.net  Fri Jul 29 13:34:26 2016
From: joquendo at e-fensive.net (J. Oquendo)
Date: Fri, 29 Jul 2016 08:34:26 -0500
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <9578293AE169674F9A048B2BC9A081B401E666866D@MUNPRDMBXA1.medline.com>
References: <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <CAAeewD9owkk76VnKUZf7a+cUt8vour58r2m6e111fcUJCnZywQ@mail.gmail.com>
 <m2eg6cy4sy.wl%randy@psg.com>
 <9578293AE169674F9A048B2BC9A081B401E666866D@MUNPRDMBXA1.medline.com>
Message-ID: <20160729133426.GA44736@e-fensive.net>

On Fri, 29 Jul 2016, Naslund, Steve wrote:

> What he said.  If I am given a court order and follow it, I can't get sued when I knock you off the Internet.
> 
> Steven Naslund

Because someone breaking AUPs and TOS is not enough. "Hey
I know you broke every rule in the book. Forget that for
now I am not a judge, feel free to DDoS, steal someone's
life savings with your malware/phishing. You're fine by
me until a judge tells me otherwise." -- Smart answer

-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM

"Where ignorance is our master, there is no possibility of
real peace" - Dalai Lama

0B23 595C F07C 6092 8AEB  074B FC83 7AF5 9D8A 4463
https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463

From rdobbins at arbor.net  Fri Jul 29 13:58:23 2016
From: rdobbins at arbor.net (Roland Dobbins)
Date: Fri, 29 Jul 2016 20:58:23 +0700
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <20160729133426.GA44736@e-fensive.net>
References: <m2k2g61nry.wl%randy@psg.com>
 <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <CAAeewD9owkk76VnKUZf7a+cUt8vour58r2m6e111fcUJCnZywQ@mail.gmail.com>
 <m2eg6cy4sy.wl%randy@psg.com>
 <9578293AE169674F9A048B2BC9A081B401E666866D@MUNPRDMBXA1.medline.com>
 <20160729133426.GA44736@e-fensive.net>
Message-ID: <608BD679-7FD3-4EA8-AF98-10BEEF434A7B@arbor.net>


On 29 Jul 2016, at 20:34, J. Oquendo wrote:

> Because someone breaking AUPs and TOS is not enough.

The AUP, the TOS, and the RFP are the most powerful security tools any 
network operator has at their disposal - assuming they've invested some 
time and effort in crafting them, and in ensuring they can be enforced.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From hugo at slabnet.com  Fri Jul 29 15:38:38 2016
From: hugo at slabnet.com (Hugo Slabbert)
Date: Fri, 29 Jul 2016 08:38:38 -0700
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <20160729125009.GA42429@e-fensive.net>
References: <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
 <28E6FC71-F6FF-49B9-B861-3B573372594F@f5.com>
 <20160729120805.GA5869@gsp.org>
 <20160729125009.GA42429@e-fensive.net>
Message-ID: <20160729153838.GB1207@bamboo.slabnet.com>


On Fri 2016-Jul-29 07:50:09 -0500, J. Oquendo <joquendo at e-fensive.net> wrote:

>On Fri, 29 Jul 2016, Rich Kulawiec wrote:
>
>> On Thu, Jul 28, 2016 at 11:30:12PM +0000, Donn Lasher via NANOG wrote:
>> > If we want to be accurate about it, Cloudflare doesn???t host the DDoS,
>> > they protect the website of seller of the product. We shouldn???t be
>> > de-peering Cloud Flare over sites they protect any more than we would
>> > de-peer GoDaddy over sites they host, some of which, no doubt, sell
>> > gray/black market/illegal items/services.
>>
>> The only way to make action against them effective is to do it broadly,
>> do it swiftly, and do it permanently.
>>
>
>In my ramblings on "Why network operators love filth", I
>associate a landlord that knowingly allows his/her tenant
>to sell drugs. In America, your house is gone. This should
>be the case on the Internet as well. Keep sending out crap
>and ARIN should yank your IP space after everyone else
>has de-peered you.
>
>So let's get to these horrible analogies of "weapons" and
>whether or not CloudFlare is solely the gun manufacturer
>and is not responsible whether or not their ARCLOUD rifle
>was used to shoot up a school killing children.
>
>Analogy: Hotel Cloud is a pretty big hotel in the city.
>They have 5,000 rooms. When you walk by, their tenants
>are throwing rocks out of the windows, garbage, etc.
>People complain to the hotel management that does nothing
>about it. Hotel Cloud's response is: 'Well this is really
>not our problem, we only rent a room, what the occupant
>does...' --- And this makes sense to how many of you who'd
>respond: "Well I don't know about you but I want to walk
>around freely" Freely? At some point in time, you WILL
>walk by this hotel, or another that WILL become just like
>it. Why? Because there will be no one to say: "Hey this
>is wrong buck stops here..."
>
>I have seen these discussions on this list for so many
>years, and there are those that want to do good, but won't
>lift a finger out of fear of the herd/praetorian guard.
>Anyone saying it cannot be done, is a coward bowing to
>the dollar (euro/yen/whatever). The analogy above is spot
>on...

This may seem pedantic, but no it's not, at least not in the Cloudflare 
situation.  In the Hotel Cloudflare example, the miscreants don't hurl the 
rocks and filth out of the hotels' windows.  They set up a storefront/shop 
in the hotel to sell rock- and filth-slinging for hire, with the actual 
rock- and filth-flinging being done elsewhere.

That said:

I don't believe the hotel can turn a blind eye to rock- and filth-slinging 
being peddled from their premises without consequence.  If we caught 
someone running a booter web storefront on our net, they'd be gone.  And 
the premises from which rock- and filth-slinging occurs (networks that 
originate garbage traffic, especially those that permit source address 
spoofing) also need to be held accountable.

Again: not disagreeing that we need to hold people accountable; just 
clarifying the analogy for this case.

I've cut off service for customer gear that was spewing garbage where they 
failed to do anything about it.  We generally give an initial grace period 
and assist the customer however we can in getting their stuff cleaned up 
(or try to drop just the abusive traffic to start and leave the rest of 
their feed).  But if you keep getting repeatedly compromised, fail to 
protect your stuff or clean it up, and keep spewing ever more varied 
garbage, you've proven yourself incapable of running an Internet-facing 
service and I'll quit trying to play whack-a-mole and just drop you.

And yes:
BCP38: we haz it.

We're not at the scale of the big boys, but we try to do our part to run a 
clean shop.

>...with the only difference being a hotel is physical,
>and on the Interwebs, out of sight out of mind. 

>This is until one of your relatives' sites gets taken offline by
>some bored moron via DDoS, and there go their sales, there
>goes their business. THEN and only THEN will some of the
>naysayers say: "Shit we could have stopped it."
>
>Do you need law enforcement to be moral? "I can see
>that person is getting pulverized by some drunken idiot
>better not intervene because well... I want to walk
>freely..." That beating can come full circle, where
>beating can be DDoS, a sophisticated attack, malware.
>
>I am so tempted to start a shaming site for networks
>including all of the big boys with detailed records
>showing how abuse was contacted, no one did nothing,
>and oh by the way... "Are you sure you want to host
>or transit with this company? Last I checked via
>logs, they were a filthy network that catered to
>peds, RBN folk, etc" Maybe when some of you guys
>(that sit around twiddling fingers) see your companies
>all over the place, maybe then you'll think about doing
>the right thing.
>
>
>-- 
>=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
>J. Oquendo
>SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM
>
>"Where ignorance is our master, there is no possibility of
>real peace" - Dalai Lama
>
>0B23 595C F07C 6092 8AEB  074B FC83 7AF5 9D8A 4463
>https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463

-- 
Hugo Slabbert       | email, xmpp/jabber: hugo at slabnet.com
pgp key: B178313E   | also on Signal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160729/fb54e47b/attachment.pgp>

From manager at monmouth.com  Fri Jul 29 15:41:41 2016
From: manager at monmouth.com (Mark Stevens)
Date: Fri, 29 Jul 2016 11:41:41 -0400
Subject: Yahoo Postmaster or Email Admin
In-Reply-To: <42265d93-a705-3a9c-86eb-d6f22fa4f893@monmouth.com>
References: <f424f693-e87e-6077-d794-51027aa2b2a2@monmouth.com>
 <519292135.209299.1469637573871.JavaMail.yahoo@mail.yahoo.com>
 <CAN9qwJ-01U=9EmTLHP1A7aLgm2O=y1XPKPab_Ryt102wJHzuig@mail.gmail.com>
 <78239981.209347.1469638199379.JavaMail.yahoo@mail.yahoo.com>
 <a42180f5baa04ee6b57fd3b06568f6ed@nafcmb01.exchange.ford.com>
 <42265d93-a705-3a9c-86eb-d6f22fa4f893@monmouth.com>
Message-ID: <bd75aedf-0a9b-27a5-8be2-b30a83cc2fc4@monmouth.com>

Thanks to everyone who helped with this issue. All cleared up now.

Mark
On 7/27/2016 1:05 PM, Mark Stevens wrote:
> I have been to https://postmaster.yahoo.com and even filled out a bulk 
> email form (explained the issue in the notes section) but still no go.
> I even have a ticket opened with their support but you can guess how 
> that is going.....
> This is why I asked if anyone has a contact or if in fact a sysadmin @ 
> yahoo is on nanog and could contact me.
> I will keep working at this, thanks for the info!
>
> Mark
>
> On 7/27/2016 12:53 PM, Kain, Rebecca (.) wrote:
>> Maybe they could get their email working. it's been hanging, not 
>> sending mail, for 4 days, as far my experience has been.
>>
>> -----Original Message-----
>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Elizabeth 
>> Zwicky via NANOG
>> Sent: Wednesday, July 27, 2016 12:50 PM
>> To: Josh Luthman
>> Cc: NANOG list
>> Subject: Re: Yahoo Postmaster or Email Admin
>>
>>
>> Yes, yes I do.
>>
>>      On Wednesday, July 27, 2016 9:44 AM, Josh Luthman 
>> <josh at imaginenetworksllc.com> wrote:
>>
>>   Do you mean https://postmaster.yahoo.com/ ?
>>
>> Josh Luthman
>> Office: 937-552-2340
>> Direct: 937-552-2343
>> 1100 Wayne St
>> Suite 1337
>> Troy, OH 45373
>> On Wed, Jul 27, 2016 at 12:39 PM, Elizabeth Zwicky via NANOG 
>> <nanog at nanog.org> wrote:
>>
>> We encourage people to start at https://postmaster.yaho.com but I can 
>> help people who have filed tickets there and not had any luck can 
>> contact me, specifying a) what IP addresses and From: line they're 
>> talking about and b) exactly what error message they are getting when 
>> they try to send us mail.
>> Elizabeth
>> On Wednesday, July 27, 2016, 5:31:55 AM PDT, Mark Stevens 
>> <manager at monmouth.com> wrote:Good Morning,
>>
>> If there is a Yahoo postmaster or email Admin that could contact me
>> offline concerning a deferred IP address it would be great.
>>
>>
>> Thanks
>>
>> Mark
>>
>>
>>
>>
>>
>>
>
>


From tech.andrewn at gmail.com  Fri Jul 29 16:56:27 2016
From: tech.andrewn at gmail.com (Andrew N)
Date: Fri, 29 Jul 2016 09:56:27 -0700
Subject: ASR920-12G-2-10G
Message-ID: <CAJ_7C9DuDW0NAghZSg7v-RDtuh=14xRb4HZ+bAtuLfAUTw5dvg@mail.gmail.com>

Hello,
We're looking to purchase 1. Can anyone confirm this is a permanent license
for the router?
 Thanks.
Andrew

From vikash_sorout at yahoo.com  Fri Jul 29 15:02:44 2016
From: vikash_sorout at yahoo.com (Vikash Sorout)
Date: Fri, 29 Jul 2016 15:02:44 +0000 (UTC)
Subject: Google.com redirecting to Google.co.in
References: <1057746612.7763541.1469804564857.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <1057746612.7763541.1469804564857.JavaMail.yahoo@mail.yahoo.com>

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px #715FFA solid !important; padding-left:1ex !important; background-color:white !important; }  Hi All,
When I am trying to hit Google.com it's redirecting me to Google.co.in. I am using VPN network globally over MPLS networks ?
So for all locations internet is going via Level 3 in North America .?
You can go here for my IP details.


I am seeking for support please help me out.?

Side note : Google geo-coding is looking good.?

Sent from Yahoo Mail for iPhone

From cscora at apnic.net  Fri Jul 29 18:01:38 2016
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 30 Jul 2016 04:01:38 +1000 (AEST)
Subject: Weekly Routing Table Report
Message-ID: <20160729180138.13B46AB450@thyme.apnic.net>

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG,
SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG.

Daily listings are sent to bgp-stats at lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith <pfsinoz at gmail.com>.

Routing Table Report   04:00 +10GMT Sat 30 Jul, 2016

Report Website:     http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              605937
    Prefixes after maximum aggregation (per Origin AS):          218930
    Deaggregation factor:                                          2.77
    Unique aggregates announced (without unneeded subnets):      295442
Total ASes present in the Internet Routing Table:                 54446
    Prefixes per ASN:                                             11.13
Origin-only ASes present in the Internet Routing Table:           36489
Origin ASes announcing only one prefix:                           15509
Transit ASes present in the Internet Routing Table:                6470
Transit-only ASes present in the Internet Routing Table:            172
Average AS path length visible in the Internet Routing Table:       4.3
    Max AS path length visible:                                      54
    Max AS path prepend of ASN ( 55644)                              51
Prefixes from unregistered ASNs in the Routing Table:                68
    Unregistered ASNs in the Routing Table:                          16
Number of 32-bit ASNs allocated by the RIRs:                      14821
Number of 32-bit ASNs visible in the Routing Table:               11487
Prefixes from 32-bit ASNs in the Routing Table:                   45357
Number of bogon 32-bit ASNs visible in the Routing Table:            14
Special use prefixes present in the Routing Table:                    0
Prefixes being announced from unallocated address space:            377
Number of addresses announced to Internet:                   2822086116
    Equivalent to 168 /8s, 53 /16s and 157 /24s
    Percentage of available address space announced:               76.2
    Percentage of allocated address space announced:               76.2
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               98.2
Total number of prefixes smaller than registry allocations:      196985

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                   156685
    Total APNIC prefixes after maximum aggregation:               42877
    APNIC Deaggregation factor:                                    3.65
Prefixes being announced from the APNIC address blocks:          169189
    Unique aggregates announced from the APNIC address blocks:    68365
APNIC Region origin ASes present in the Internet Routing Table:    5197
    APNIC Prefixes per ASN:                                       32.56
APNIC Region origin ASes announcing only one prefix:               1180
APNIC Region transit ASes present in the Internet Routing Table:    933
Average APNIC Region AS path length visible:                        4.4
    Max APNIC Region AS path length visible:                         54
Number of APNIC region 32-bit ASNs visible in the Routing Table:   2259
Number of APNIC addresses announced to Internet:              759212868
    Equivalent to 45 /8s, 64 /16s and 171 /24s
    Percentage of available APNIC address space announced:         88.7

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 63488-64098, 64297-64395, 131072-137529
APNIC Address Blocks     1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
                        49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
                       106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
                       116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
                       123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
                       163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
                       203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
                       222/8, 223/8,

ARIN Region Analysis Summary
----------------------------

Prefixes being announced by ARIN Region ASes:                    182664
    Total ARIN prefixes after maximum aggregation:                89227
    ARIN Deaggregation factor:                                     2.05
Prefixes being announced from the ARIN address blocks:           188251
    Unique aggregates announced from the ARIN address blocks:     88506
ARIN Region origin ASes present in the Internet Routing Table:    16265
    ARIN Prefixes per ASN:                                        11.57
ARIN Region origin ASes announcing only one prefix:                5757
ARIN Region transit ASes present in the Internet Routing Table:    1699
Average ARIN Region AS path length visible:                         3.8
    Max ARIN Region AS path length visible:                          23
Number of ARIN region 32-bit ASNs visible in the Routing Table:    1357
Number of ARIN addresses announced to Internet:              1105299936
    Equivalent to 65 /8s, 225 /16s and 137 /24s
    Percentage of available ARIN address space announced:          58.5

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 62464-63487, 64198-64296, 393216-397212
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  45/8,  47/8,  48/8,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/8,  63/8,  64/8,
                        65/8,  66/8,  67/8,  68/8,  69/8,  70/8,  71/8,
                        72/8,  73/8,  74/8,  75/8,  76/8,  96/8,  97/8,
                        98/8,  99/8, 100/8, 104/8, 107/8, 108/8, 128/8,
                       129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8,
                       137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8,
                       146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8,
                       157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8,
                       165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8,
                       173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8,
                       205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8,
                       216/8,

RIPE Region Analysis Summary
----------------------------

Prefixes being announced by RIPE Region ASes:                    145236
    Total RIPE prefixes after maximum aggregation:                71314
    RIPE Deaggregation factor:                                     2.04
Prefixes being announced from the RIPE address blocks:           155038
    Unique aggregates announced from the RIPE address blocks:     95411
RIPE Region origin ASes present in the Internet Routing Table:    18101
    RIPE Prefixes per ASN:                                         8.57
RIPE Region origin ASes announcing only one prefix:                7832
RIPE Region transit ASes present in the Internet Routing Table:    3016
Average RIPE Region AS path length visible:                         4.4
    Max RIPE Region AS path length visible:                          27
Number of RIPE region 32-bit ASNs visible in the Routing Table:    4958
Number of RIPE addresses announced to Internet:               706001024
    Equivalent to 42 /8s, 20 /16s and 184 /24s
    Percentage of available RIPE address space announced:         102.6

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       59392-61439, 61952-62463, 196608-204287
RIPE Address Blocks      2/8,   5/8,  25/8,  31/8,  37/8,  46/8,  51/8,
                        62/8,  77/8,  78/8,  79/8,  80/8,  81/8,  82/8,
                        83/8,  84/8,  85/8,  86/8,  87/8,  88/8,  89/8,
                        90/8,  91/8,  92/8,  93/8,  94/8,  95/8, 109/8,
                       141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8,
                       193/8, 194/8, 195/8, 212/8, 213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   61638
    Total LACNIC prefixes after maximum aggregation:              12265
    LACNIC Deaggregation factor:                                   5.03
Prefixes being announced from the LACNIC address blocks:          76799
    Unique aggregates announced from the LACNIC address blocks:   36773
LACNIC Region origin ASes present in the Internet Routing Table:   2483
    LACNIC Prefixes per ASN:                                      30.93
LACNIC Region origin ASes announcing only one prefix:               568
LACNIC Region transit ASes present in the Internet Routing Table:   576
Average LACNIC Region AS path length visible:                       4.8
    Max LACNIC Region AS path length visible:                        24
Number of LACNIC region 32-bit ASNs visible in the Routing Table:  2675
Number of LACNIC addresses announced to Internet:             170224704
    Equivalent to 10 /8s, 37 /16s and 108 /24s
    Percentage of available LACNIC address space announced:       101.5

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       61440-61951, 64099-64197, 262144-265628 + ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       191/8, 200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                  14288
    Total AfriNIC prefixes after maximum aggregation:              3237
    AfriNIC Deaggregation factor:                                  4.41
Prefixes being announced from the AfriNIC address blocks:         16283
    Unique aggregates announced from the AfriNIC address blocks:   6049
AfriNIC Region origin ASes present in the Internet Routing Table:   734
    AfriNIC Prefixes per ASN:                                     22.18
AfriNIC Region origin ASes announcing only one prefix:              172
AfriNIC Region transit ASes present in the Internet Routing Table:  176
Average AfriNIC Region AS path length visible:                      4.5
    Max AfriNIC Region AS path length visible:                       21
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:  238
Number of AfriNIC addresses announced to Internet:             81007360
    Equivalent to 4 /8s, 212 /16s and 19 /24s
    Percentage of available AfriNIC address space announced:       80.5

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 154/8, 196/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4538     5553       4191          75   ERX-CERNET-BKB China Education and Rese
 7545     3428        384         253   TPG-INTERNET-AP TPG Telecom Limited, AU
 4766     3186      11145        1126   KIXS-AS-KR Korea Telecom, KR
17974     2933        904          78   TELKOMNET-AS2-AP PT Telekomunikasi Indo
 9829     2613       1488         513   BSNL-NIB National Internet Backbone, IN
 1659     2493       1466          38   ERX-TANET-ASN1 Taiwan Academic Network 
 9808     2233       8761          40   CMNET-GD Guangdong Mobile Communication
 4755     2079        432         243   TATACOMM-AS TATA Communications formerl
 4808     1796       2309         548   CHINA169-BJ China Unicom Beijing Provin
38197     1507         93         277   SUNHK-DATA-AS-AP Sun Network (Hong Kong

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC

ARIN Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
22773     3497       2965         144   ASN-CXA-ALL-CCI-22773-RDC - Cox Communi
 6389     2225       3671          41   BELLSOUTH-NET-BLK - BellSouth.net Inc.,
18566     2195        405         110   MEGAPATH5-US - MegaPath Corporation, US
20115     1932       1956         410   CHARTER-NET-HKY-NC - Charter Communicat
30036     1726        345         354   MEDIACOM-ENTERPRISE-BUSINESS - Mediacom
  209     1709       5083         651   CENTURYLINK-US-LEGACY-QWEST - Qwest Com
 6983     1689        849         228   ITCDELTA - Earthlink, Inc., US
16509     1348       2478         432   AMAZON-02 - Amazon.com, Inc., US
 7018     1340      20070         995   ATT-INTERNET4 - AT&T Services, Inc., US
11492     1309        233         567   CABLEONE - CABLE ONE, INC., US

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN

RIPE Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
39891     3329        169          15   ALJAWWALSTC-AS , SA
20940     2719       1048        1933   AKAMAI-ASN1 , US
34984     1974        327         358   TELLCOM-AS , TR
12479     1294       1018          46   UNI2-AS , ES
 8551     1212        377          46   BEZEQ-INTERNATIONAL-AS Bezeqint Interne
 6849     1148        355          21   UKRTELNET , UA
13188     1094         98          62   BANKINFORM-AS , UA
 8402     1025        544          15   CORBINA-AS Russia, RU
31148     1017         47          44   FREENET-AS , UA
 9198      967        352          25   KAZTELECOM-AS , KZ

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
10620     3475        542         129   Telmex Colombia S.A., CO
 8151     2265       3369         547   Uninet S.A. de C.V., MX
 7303     1530        945         244   Telecom Argentina S.A., AR
11830     1493        369          66   Instituto Costarricense de Electricidad
 6503     1413        437          54   Axtel, S.A.B. de C.V., MX
 6147     1095        377          27   Telefonica del Peru S.A.A., PE
 3816      996        479         182   COLOMBIA TELECOMUNICACIONES S.A. ESP, C
 7738      994       1882          40   Telemar Norte Leste S.A., BR
11172      907        125          76   Alestra, S. de R.L. de C.V., MX
28573      899       2181         159   CLARO S.A., BR

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC

AfriNIC Region per AS prefix count summary
------------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
24863     1166        402          48   LINKdotNET-AS, EG
36903      656        330         109   MT-MPLS, MA
37611      649         48           2   Afrihost, ZA
36992      538       1357          26   ETISALAT-MISR, EG
 8452      501       1472          15   TE-AS TE-AS, EG
37492      373        234          68   ORANGE-TN, TN
24835      333        594          15   RAYA-AS, EG
29571      300         37          12   CITelecom-AS, CI
15399      289         35           6   WANANCHI-KE, KE
 2018      268        327          74   TENET-1, ZA

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC

Global Per AS prefix count summary
----------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4538     5553       4191          75   ERX-CERNET-BKB China Education and Rese
22773     3497       2965         144   ASN-CXA-ALL-CCI-22773-RDC - Cox Communi
10620     3475        542         129   Telmex Colombia S.A., CO
 7545     3428        384         253   TPG-INTERNET-AP TPG Telecom Limited, AU
39891     3329        169          15   ALJAWWALSTC-AS , SA
 4766     3186      11145        1126   KIXS-AS-KR Korea Telecom, KR
17974     2933        904          78   TELKOMNET-AS2-AP PT Telekomunikasi Indo
20940     2719       1048        1933   AKAMAI-ASN1 , US
 9829     2613       1488         513   BSNL-NIB National Internet Backbone, IN
 1659     2493       1466          38   ERX-TANET-ASN1 Taiwan Academic Network 

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
22773      3497        3353      ASN-CXA-ALL-CCI-22773-RDC - Cox Communi
10620      3475        3346      Telmex Colombia S.A., CO
39891      3329        3314      ALJAWWALSTC-AS , SA
 7545      3428        3175      TPG-INTERNET-AP TPG Telecom Limited, AU
17974      2933        2855      TELKOMNET-AS2-AP PT Telekomunikasi Indo
 1659      2493        2455      ERX-TANET-ASN1 Taiwan Academic Network 
 9808      2233        2193      CMNET-GD Guangdong Mobile Communication
 6389      2225        2184      BELLSOUTH-NET-BLK - BellSouth.net Inc.,
 9829      2613        2100      BSNL-NIB National Internet Backbone, IN
18566      2195        2085      MEGAPATH5-US - MegaPath Corporation, US

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS  Designation  Network              Transit AS  Description
65001   PRIVATE      5.143.176.0/20       15468       KLGELECS-AS 38, Teatralnaya st
65001   PRIVATE      31.172.192.0/20      15468       KLGELECS-AS 38, Teatralnaya st
65001   PRIVATE      31.172.192.0/21      15468       KLGELECS-AS 38, Teatralnaya st
65001   PRIVATE      31.172.200.0/21      15468       KLGELECS-AS 38, Teatralnaya st
65001   PRIVATE      31.172.208.0/21      15468       KLGELECS-AS 38, Teatralnaya st
65001   PRIVATE      31.172.216.0/21      15468       KLGELECS-AS 38, Teatralnaya st
65000   PRIVATE      31.219.177.0/25       8966       ETISALAT-AS P.O. Box 1150, Dub
65000   PRIVATE      31.219.177.128/25     8966       ETISALAT-AS P.O. Box 1150, Dub
65412   PRIVATE      41.89.7.0/24         36866       JTL, KE
65512   PRIVATE      45.252.244.0/24      45899       VNPT-AS-VN VNPT Corp, VN

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
23.249.144.0/20      40430     COLO4JAX-AS - colo4jax, LLC, US
27.100.7.0/24        56096     UNKNOWN
41.73.1.0/24         37004     -Reserved AS-, ZZ
41.73.2.0/24         37004     -Reserved AS-, ZZ
41.73.3.0/24         37004     -Reserved AS-, ZZ
41.73.4.0/24         37004     -Reserved AS-, ZZ
41.73.5.0/24         37004     -Reserved AS-, ZZ
41.73.6.0/24         37004     -Reserved AS-, ZZ
41.73.7.0/24         37004     -Reserved AS-, ZZ
41.73.8.0/24         37004     -Reserved AS-, ZZ

Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA

Number of prefixes announced per prefix length (Global)
-------------------------------------------------------

 /1:0        /2:0        /3:0        /4:0        /5:0        /6:0       
 /7:0        /8:16       /9:13      /10:36      /11:101     /12:266     
/13:518     /14:1051    /15:1765    /16:13157   /17:7823    /18:12745   
/19:25321   /20:38313   /21:40218   /22:67197   /23:58829   /24:336901  
/25:566     /26:586     /27:378     /28:54      /29:32      /30:16      
/31:1       /32:34      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
39891     2896          3329      ALJAWWALSTC-AS , SA
22773     2726          3497      ASN-CXA-ALL-CCI-22773-RDC - Cox Communi
18566     2087          2195      MEGAPATH5-US - MegaPath Corporation, US
30036     1540          1726      MEDIACOM-ENTERPRISE-BUSINESS - Mediacom
 6389     1440          2225      BELLSOUTH-NET-BLK - BellSouth.net Inc.,
10620     1384          3475      Telmex Colombia S.A., CO
 6983     1340          1689      ITCDELTA - Earthlink, Inc., US
34984     1257          1974      TELLCOM-AS , TR
11492     1207          1309      CABLEONE - CABLE ONE, INC., US
 6849      968          1148      UKRTELNET , UA

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:1578      2:748       4:21        5:2129      6:31        8:973    
  12:1774     13:41       14:1719     15:45       16:2        17:88     
  18:117      20:49       22:1        23:1619     24:1798     27:2300   
  31:1778     32:68       33:3        34:2        35:5        36:318    
  37:2281     38:1247     39:35       40:93       41:2814     42:447    
  43:1833     44:43       45:2127     46:2511     47:84       49:1165   
  50:889      51:12       52:531      54:342      55:8        56:7      
  57:42       58:1613     59:950      60:353      61:1807     62:1504   
  63:1920     64:4529     65:2169     66:4229     67:2200     68:1127   
  69:3265     70:1247     71:484      72:2014     74:2526     75:344    
  76:391      77:1431     78:1266     79:861      80:1250     81:1383   
  82:975      83:721      84:849      85:1585     86:497      87:1097   
  88:551      89:2089     90:210      91:6056     92:975      93:2365   
  94:2426     95:2511     96:503      97:354      98:947      99:41     
 100:76      101:1084    103:11793   104:2562    105:125     106:431    
 107:1399    108:663     109:2234    110:1284    111:1631    112:1038   
 113:1132    114:1092    115:1659    116:1628    117:1540    118:1998   
 119:1597    120:1220    121:1122    122:2195    123:2001    124:1586   
 125:1772    128:672     129:423     130:409     131:1331    132:620    
 133:175     134:446     135:138     136:379     137:399     138:1793   
 139:417     140:712     141:454     142:651     143:925     144:719    
 145:165     146:884     147:658     148:1384    149:538     150:659    
 151:867     152:637     153:302     154:656     155:952     156:517    
 157:490     158:380     159:1142    160:509     161:736     162:2358   
 163:921     164:898     165:1062    166:322     167:1155    168:1961   
 169:670     170:1807    171:263     172:625     173:1641    174:757    
 175:702     176:1721    177:4004    178:2213    179:1123    180:2150   
 181:1811    182:1981    183:987     184:828     185:7031    186:3067   
 187:2083    188:2193    189:1741    190:7804    191:1284    192:9056   
 193:5730    194:4426    195:3852    196:1711    197:1145    198:5545   
 199:5741    200:7081    201:3750    202:10116   203:10095   204:4511   
 205:2725    206:2985    207:3084    208:4059    209:3863    210:4261   
 211:2039    212:2694    213:2327    214:871     215:71      216:5829   
 217:1983    218:800     219:610     220:1635    221:867     222:683    
 223:1259   

End of report

From rsk at gsp.org  Fri Jul 29 19:14:05 2016
From: rsk at gsp.org (Rich Kulawiec)
Date: Fri, 29 Jul 2016 15:14:05 -0400
Subject: EVERYTHING about Booters (and CloudFlare)
In-Reply-To: <608BD679-7FD3-4EA8-AF98-10BEEF434A7B@arbor.net>
References: <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <CAAeewD9owkk76VnKUZf7a+cUt8vour58r2m6e111fcUJCnZywQ@mail.gmail.com>
 <m2eg6cy4sy.wl%randy@psg.com>
 <9578293AE169674F9A048B2BC9A081B401E666866D@MUNPRDMBXA1.medline.com>
 <20160729133426.GA44736@e-fensive.net>
 <608BD679-7FD3-4EA8-AF98-10BEEF434A7B@arbor.net>
Message-ID: <20160729191405.GA22364@gsp.org>

On Fri, Jul 29, 2016 at 08:58:23PM +0700, Roland Dobbins wrote:
> The AUP, the TOS, and the RFP are the most powerful security tools any
> network operator has at their disposal - assuming they've invested some time
> and effort in crafting them, and in ensuring they can be enforced.

This.  A hundred times this.

And keep in mind that these tools are not just to protect your operation;
they're to protect the Internet *from* your operation.

---rsk

From bzs at TheWorld.com  Fri Jul 29 19:36:03 2016
From: bzs at TheWorld.com (bzs at TheWorld.com)
Date: Fri, 29 Jul 2016 15:36:03 -0400
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <20160729120805.GA5869@gsp.org>
References: <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
 <28E6FC71-F6FF-49B9-B861-3B573372594F@f5.com>
 <20160729120805.GA5869@gsp.org>
Message-ID: <22427.45091.239632.929005@gargle.gargle.HOWL>


Unfortunately that raises the issue of what's generally termed in law
a "business boycott" which is at least tortiable if not illegal.

The grocer can't agree with your landlord not to sell you food until
you catch up on the rent.

They can agree to use this information to refuse you credit but even
that's quite constrained by law even if often done anyhow. And that's
a credit relationship so different.

I went over this with my attorney when another ISP asked me to shut a
customer's account down because they were spamming them from a third
ISP's account.

I asked to look at the emails (spam) in question and none originated
at our site. The acct in question on my site didn't do anything
problematic that I could find.

My lawyer explained the above to me: You can't do that, business
boycott.

The other ISP (specifically a sysadmin) who'd asked me to shut the
acct got so angry at this response, he took it all very personally and
unprofessionally, that I had to bring in his own legal dept to explain
this to him which he of course took as a further affront. It got ugly
but you don't need the details.

That's the problem with all this folksy armchair "law", it's often
very bad advice and based on the assumption that the law must agree
with one's emotional feelings. Good luck with that.

On July 29, 2016 at 08:08 rsk at gsp.org (Rich Kulawiec) wrote:
 > On Thu, Jul 28, 2016 at 11:30:12PM +0000, Donn Lasher via NANOG wrote:
 > > If we want to be accurate about it, Cloudflare doesn???t host the DDoS,
 > > they protect the website of seller of the product. We shouldn???t be
 > > de-peering Cloud Flare over sites they protect any more than we would
 > > de-peer GoDaddy over sites they host, some of which, no doubt, sell
 > > gray/black market/illegal items/services.
 > 
 > This strategy fails for two reasons.
 > 
 > First, nobody gets a pass.  Anybody providing services to abusers
 > needs to cut them off, whether it's a registrar, a web host, an email
 > provider, a DNS provider, or anything else.  Nobody gets to shrug it
 > off with "Well, but..."
 > 
 > Second, nobody *can* get a pass, because the people behind these operations
 > have long since learned to distribute their assets widely -- in an attempt
 > to avoid exactly the actions in the first point.  And you know what?
 > It works.  "We're just hosting their email", says X, and "We're just
 > hosting their DNS", says Y, and "We're just hosting their web site",
 > says Z, and none of them do anything, and nothing gets done. 
 > 
 > The only way to make action against them effective is to do it broadly,
 > do it swiftly, and do it permanently.
 > 
 > ---rsk

-- 
        -Barry Shein

Software Tool & Die    | bzs at TheWorld.com             | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

From larrysheldon at cox.net  Fri Jul 29 23:04:55 2016
From: larrysheldon at cox.net (Larry Sheldon)
Date: Fri, 29 Jul 2016 18:04:55 -0500
Subject: Google.com redirecting to Google.co.in
In-Reply-To: <1057746612.7763541.1469804564857.JavaMail.yahoo@mail.yahoo.com>
References: <1057746612.7763541.1469804564857.JavaMail.yahoo.ref@mail.yahoo.com>
 <1057746612.7763541.1469804564857.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <fea21304-9c95-07dc-665e-998555f1ef5c@cox.net>



On 7/29/2016 10:02, Vikash Sorout via NANOG wrote:
>  blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px #715FFA solid !important; padding-left:1ex !important; background-color:white !important; }  Hi All,
> When I am trying to hit Google.com it's redirecting me to Google.co.in. I am using VPN network globally over MPLS networks
> So for all locations internet is going via Level 3 in North America .
> You can go here for my IP details.
>
>
> I am seeking for support please help me out.
>
> Side note : Google geo-coding is looking good.
>
> Sent from Yahoo Mail for iPhone

What could be worse in a ASCII text-only environment than seriously 
broken HTML that
reads like spam if you take the time to decode it?


-- 
"Everybody is a genius.  But if you judge a fish by
its ability to climb a tree, it will live its whole
life believing that it is stupid."

--Albert Einstein

 From Larry's Cox account.

From jhellenthal at dataix.net  Fri Jul 29 23:40:45 2016
From: jhellenthal at dataix.net (J. Hellenthal)
Date: Fri, 29 Jul 2016 18:40:45 -0500
Subject: Google.com redirecting to Google.co.in
In-Reply-To: <fea21304-9c95-07dc-665e-998555f1ef5c@cox.net>
References: <1057746612.7763541.1469804564857.JavaMail.yahoo.ref@mail.yahoo.com>
 <1057746612.7763541.1469804564857.JavaMail.yahoo@mail.yahoo.com>
 <fea21304-9c95-07dc-665e-998555f1ef5c@cox.net>
Message-ID: <ADCF9ABD-D671-482F-8663-9817658BC7BD@DataIX.net>

Haha

-- 
Onward!
J. Hellenthal
Systems & Network Admin
JJH48-ARIN

On Jul 29, 2016, at 18:04, Larry Sheldon <larrysheldon at cox.net> wrote:



> On 7/29/2016 10:02, Vikash Sorout via NANOG wrote:
> blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px #715FFA solid !important; padding-left:1ex !important; background-color:white !important; }  Hi All,
> When I am trying to hit Google.com it's redirecting me to Google.co.in. I am using VPN network globally over MPLS networks
> So for all locations internet is going via Level 3 in North America .
> You can go here for my IP details.
> 
> 
> I am seeking for support please help me out.
> 
> Side note : Google geo-coding is looking good.
> 
> Sent from Yahoo Mail for iPhone

What could be worse in a ASCII text-only environment than seriously broken HTML that
reads like spam if you take the time to decode it?


-- 
"Everybody is a genius.  But if you judge a fish by
its ability to climb a tree, it will live its whole
life believing that it is stupid."

--Albert Einstein

From Larry's Cox account.

From Valdis.Kletnieks at vt.edu  Sat Jul 30 01:04:53 2016
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 29 Jul 2016 21:04:53 -0400
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <20160729125009.GA42429@e-fensive.net>
References: <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
 <28E6FC71-F6FF-49B9-B861-3B573372594F@f5.com> <20160729120805.GA5869@gsp.org>
 <20160729125009.GA42429@e-fensive.net>
Message-ID: <15438.1469840693@turing-police.cc.vt.edu>

On Fri, 29 Jul 2016 07:50:09 -0500, "J. Oquendo" said:

> In my ramblings on "Why network operators love filth", I
> associate a landlord that knowingly allows his/her tenant
> to sell drugs. In America, your house is gone. This should
> be the case on the Internet as well.

Oh, do *NOT* go there.  In America, "Civil forfeiture" is a *major*
out-of-control problem, because it is *not* done with any sort of judicial
review *at all*.  The police department simply seizes your house/car/etc
on *suspicion* of being involved with drugs or whatever - there doesn't
even need to be an arrest of anybody.

That's right - they can suspect you of dealing drugs, but not have enough
evidence to arrest you.  But they can take your car away anyhow.  It's
called "stop and seize".

They can take your car away because you loaned it to your brother-in-law
to go shopping, because they suspect *he* deals drugs.  The car doesn't
have to be involved in travelling to a drug deal.

Oh, and in most cases, the police department gets to *keep* the proceeds
(money, cars - often sold at auction for more money, etc) of the forfeiture.
This of course makes their budget look better.

The end result - in the US, in 2014, the police took more money and assets
from people than all the reported robberies for the year.

http://www.zerohedge.com/news/2015-11-17/police-civil-asset-forfeitures-exceed-value-all-burglaries-2014

I sincerely *hope* that isn't how you want a global Internet run.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160729/08922715/attachment.pgp>

From cayers at ena.com  Fri Jul 29 18:11:43 2016
From: cayers at ena.com (Cory Ayers)
Date: Fri, 29 Jul 2016 18:11:43 +0000
Subject: ASR920-12G-2-10G
In-Reply-To: <CAJ_7C9DuDW0NAghZSg7v-RDtuh=14xRb4HZ+bAtuLfAUTw5dvg@mail.gmail.com>
References: <CAJ_7C9DuDW0NAghZSg7v-RDtuh=14xRb4HZ+bAtuLfAUTw5dvg@mail.gmail.com>
Message-ID: <BY2PR0201MB07917108368019CD4D2C2EECC0010@BY2PR0201MB0791.namprd02.prod.outlook.com>

Hi,

>Hello,
>We're looking to purchase 1. Can anyone confirm this is a permanent license for the router?
> Thanks.
>Andrew

It is permanent.  We purchase the ASR920-12CZ-A with both ASR920-S-A and ASR920-12G-2-10G licenses and below is the output from show license.

asr920#show license 
Index 1 Feature: advancedmetroipaccess          
        Period left: Life time
        License Type: Permanent
        License State: Active, In Use
        License Count: Non-Counted
        License Priority: Medium
Index 2 Feature: metroipaccess                  
        Period left: Not Activated
        License Type: Evaluation
        License State: Active, Not in Use, EULA not accepted
        License Count: Non-Counted
        License Priority: None
Index 3 Feature: metroaccess                    
        Period left: Not Activated
        License Type: Evaluation
        License State: Active, Not in Use, EULA not accepted
        License Count: Non-Counted
        License Priority: None
Index 4 Feature: 1588                           
Index 5 Feature: 1GEupgradelicense              
Index 6 Feature: 10GEupgradelicense             
Index 7 Feature: 12portGE-2port10GE             
        Period left: Life time
        License Type: Permanent
        License State: Active, In Use
        License Count: Non-Counted
        License Priority: Medium

Regards,


Cory



From owen at delong.com  Sat Jul 30 17:51:54 2016
From: owen at delong.com (Owen DeLong)
Date: Sat, 30 Jul 2016 10:51:54 -0700
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <22427.45091.239632.929005@gargle.gargle.HOWL>
References: <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
 <28E6FC71-F6FF-49B9-B861-3B573372594F@f5.com> <20160729120805.GA5869@gsp.org>
 <22427.45091.239632.929005@gargle.gargle.HOWL>
Message-ID: <69ACB258-40B1-496D-A957-4A3283DC1976@delong.com>

If they are using a website hosted or accelerated by your CDN to advertise
an illegal activity or an activity in violation of your ToS, then if you
have written your ToS properly, you are free to shut down said site (or
at least your portions of it) based on their violation of your ToS.

That?s not a business boycott because you didn?t conspire with their other
providers to shut it down, you took an independent action based on your
own ToS.

There?s fairly wide latitude to ?reserve the right to refuse service to
anyone?, especially if you can show that their use of said service is
in violation of the contract(s) applicable to that service.

Owen

> On Jul 29, 2016, at 12:36 , bzs at theworld.com wrote:
> 
> 
> Unfortunately that raises the issue of what's generally termed in law
> a "business boycott" which is at least tortiable if not illegal.
> 
> The grocer can't agree with your landlord not to sell you food until
> you catch up on the rent.
> 
> They can agree to use this information to refuse you credit but even
> that's quite constrained by law even if often done anyhow. And that's
> a credit relationship so different.
> 
> I went over this with my attorney when another ISP asked me to shut a
> customer's account down because they were spamming them from a third
> ISP's account.
> 
> I asked to look at the emails (spam) in question and none originated
> at our site. The acct in question on my site didn't do anything
> problematic that I could find.
> 
> My lawyer explained the above to me: You can't do that, business
> boycott.
> 
> The other ISP (specifically a sysadmin) who'd asked me to shut the
> acct got so angry at this response, he took it all very personally and
> unprofessionally, that I had to bring in his own legal dept to explain
> this to him which he of course took as a further affront. It got ugly
> but you don't need the details.
> 
> That's the problem with all this folksy armchair "law", it's often
> very bad advice and based on the assumption that the law must agree
> with one's emotional feelings. Good luck with that.
> 
> On July 29, 2016 at 08:08 rsk at gsp.org (Rich Kulawiec) wrote:
>> On Thu, Jul 28, 2016 at 11:30:12PM +0000, Donn Lasher via NANOG wrote:
>>> If we want to be accurate about it, Cloudflare doesn???t host the DDoS,
>>> they protect the website of seller of the product. We shouldn???t be
>>> de-peering Cloud Flare over sites they protect any more than we would
>>> de-peer GoDaddy over sites they host, some of which, no doubt, sell
>>> gray/black market/illegal items/services.
>> 
>> This strategy fails for two reasons.
>> 
>> First, nobody gets a pass.  Anybody providing services to abusers
>> needs to cut them off, whether it's a registrar, a web host, an email
>> provider, a DNS provider, or anything else.  Nobody gets to shrug it
>> off with "Well, but..."
>> 
>> Second, nobody *can* get a pass, because the people behind these operations
>> have long since learned to distribute their assets widely -- in an attempt
>> to avoid exactly the actions in the first point.  And you know what?
>> It works.  "We're just hosting their email", says X, and "We're just
>> hosting their DNS", says Y, and "We're just hosting their web site",
>> says Z, and none of them do anything, and nothing gets done. 
>> 
>> The only way to make action against them effective is to do it broadly,
>> do it swiftly, and do it permanently.
>> 
>> ---rsk
> 
> -- 
>        -Barry Shein
> 
> Software Tool & Die    | bzs at TheWorld.com             | http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*


From bzs at theworld.com  Sat Jul 30 19:34:32 2016
From: bzs at theworld.com (bzs at theworld.com)
Date: Sat, 30 Jul 2016 15:34:32 -0400
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <69ACB258-40B1-496D-A957-4A3283DC1976@delong.com>
References: <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
 <28E6FC71-F6FF-49B9-B861-3B573372594F@f5.com>
 <20160729120805.GA5869@gsp.org>
 <22427.45091.239632.929005@gargle.gargle.HOWL>
 <69ACB258-40B1-496D-A957-4A3283DC1976@delong.com>
Message-ID: <22429.328.693730.411532@gargle.gargle.HOWL>


On July 30, 2016 at 10:51 owen at delong.com (Owen DeLong) wrote:
 > If they are using a website hosted or accelerated by your CDN to advertise
 > an illegal activity or an activity in violation of your ToS, then if you
 > have written your ToS properly, you are free to shut down said site (or
 > at least your portions of it) based on their violation of your ToS.

Well, yes, of course, which is why I suggested developing generally
agreed upon definitions and writing them into contracts.

One can't really write a useful contract if terms aren't well defined.

 > 
 > That?s not a business boycott because you didn?t conspire with their other
 > providers to shut it down, you took an independent action based on your
 > own ToS.

The issue arises if you shut them down when you're not the harmed or
involved party.

I don't know if one can write a ToS which says you will be shut down
if you harm another party utilizing another party's services but not
otherwise involving us. Well, you can write anything but is it lawful
and enforceable?

In some cases where that sort of thing has come up I've turned it into
a credit relationship which has greater leeway.

Something like:

  It has come to our attention that you are engaged in activities,
  even if not thus far involving our services, which might incur us
  legal fees. Consequently we require a deposit to cover those legal
  fees, in advance, of $10,000 [pick a number] with the understanding
  that any such legal fees will be billable in full even if above and
  beyond that $10,000 deposit. Since I extend you no credit a failure
  to provide that deposit by [date in the near future] will result in
  termination of services. Please feel free to contact us with any
  questions or concerns.

but consult your attorney, state and local regulations and your own
ToS and corporate organization may affect how and whether you can do
that sort of thing or exactly how it has to be architected.

If one wants to one can include demand for indemnification with
evidence of ability to indemnify and/or business insurance policies
where you've been written in as a legitimate potential claimant for
legal fees and damages assuming the business insurance policy covers
that but as I said you need a lawyer to suss that out.

They probably could still fight with you over all that if none of it
was anticipated in your ToS (hint: might be something to add to a ToS,
reserving the right to...blah blah.) Or even try to perfect an
argument based on some theory of estoppel (you changed the conditions
in a way which harms me the client.)

More likely they'll ask for time and assistance to leave your service
(in my experience), generally what you actually wanted. Buh-bye!

 > 
 > There?s fairly wide latitude to ?reserve the right to refuse service to
 > anyone?, especially if you can show that their use of said service is
 > in violation of the contract(s) applicable to that service.

Yeah well as any lawyer will tell you relying on broad principles like
that rather than specifying covenants is just asking for legal fees :-)

 > 
 > Owen
 > 
 > > On Jul 29, 2016, at 12:36 , bzs at theworld.com wrote:
 > > 
 > > 
 > > Unfortunately that raises the issue of what's generally termed in law
 > > a "business boycott" which is at least tortiable if not illegal.
 > > 
 > > The grocer can't agree with your landlord not to sell you food until
 > > you catch up on the rent.
 > > 
 > > They can agree to use this information to refuse you credit but even
 > > that's quite constrained by law even if often done anyhow. And that's
 > > a credit relationship so different.
 > > 
 > > I went over this with my attorney when another ISP asked me to shut a
 > > customer's account down because they were spamming them from a third
 > > ISP's account.
 > > 
 > > I asked to look at the emails (spam) in question and none originated
 > > at our site. The acct in question on my site didn't do anything
 > > problematic that I could find.
 > > 
 > > My lawyer explained the above to me: You can't do that, business
 > > boycott.
 > > 
 > > The other ISP (specifically a sysadmin) who'd asked me to shut the
 > > acct got so angry at this response, he took it all very personally and
 > > unprofessionally, that I had to bring in his own legal dept to explain
 > > this to him which he of course took as a further affront. It got ugly
 > > but you don't need the details.
 > > 
 > > That's the problem with all this folksy armchair "law", it's often
 > > very bad advice and based on the assumption that the law must agree
 > > with one's emotional feelings. Good luck with that.
 > > 
 > > On July 29, 2016 at 08:08 rsk at gsp.org (Rich Kulawiec) wrote:
 > >> On Thu, Jul 28, 2016 at 11:30:12PM +0000, Donn Lasher via NANOG wrote:
 > >>> If we want to be accurate about it, Cloudflare doesn???t host the DDoS,
 > >>> they protect the website of seller of the product. We shouldn???t be
 > >>> de-peering Cloud Flare over sites they protect any more than we would
 > >>> de-peer GoDaddy over sites they host, some of which, no doubt, sell
 > >>> gray/black market/illegal items/services.
 > >> 
 > >> This strategy fails for two reasons.
 > >> 
 > >> First, nobody gets a pass.  Anybody providing services to abusers
 > >> needs to cut them off, whether it's a registrar, a web host, an email
 > >> provider, a DNS provider, or anything else.  Nobody gets to shrug it
 > >> off with "Well, but..."
 > >> 
 > >> Second, nobody *can* get a pass, because the people behind these operations
 > >> have long since learned to distribute their assets widely -- in an attempt
 > >> to avoid exactly the actions in the first point.  And you know what?
 > >> It works.  "We're just hosting their email", says X, and "We're just
 > >> hosting their DNS", says Y, and "We're just hosting their web site",
 > >> says Z, and none of them do anything, and nothing gets done. 
 > >> 
 > >> The only way to make action against them effective is to do it broadly,
 > >> do it swiftly, and do it permanently.
 > >> 
 > >> ---rsk
 > > 
 > > -- 
 > >        -Barry Shein
 > > 
 > > Software Tool & Die    | bzs at TheWorld.com             | http://www.TheWorld.com
 > > Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
 > > The World: Since 1989  | A Public Information Utility | *oo*
 > 

-- 
        -Barry Shein

Software Tool & Die    | bzs at TheWorld.com             | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

From baldur.norddahl at gmail.com  Sat Jul 30 22:07:05 2016
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Sun, 31 Jul 2016 00:07:05 +0200
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <22429.328.693730.411532@gargle.gargle.HOWL>
References: <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
 <28E6FC71-F6FF-49B9-B861-3B573372594F@f5.com> <20160729120805.GA5869@gsp.org>
 <22427.45091.239632.929005@gargle.gargle.HOWL>
 <69ACB258-40B1-496D-A957-4A3283DC1976@delong.com>
 <22429.328.693730.411532@gargle.gargle.HOWL>
Message-ID: <CAPkb-7CScd5dTj6wWW7gWTrNCwnLHktw9ytTH7RmQb5SPawbxg@mail.gmail.com>

This is silly. Anyone is of course allowed to deny service to parties
involved in obvious criminal activity. Moreover, Cloudflare benefits from
this illegal activity that they allow on their service. In addition most
other services disallow the same illegal sites. This can only lead to one
conclusion.

Regards

Baldur

Den 30. jul. 2016 21.36 skrev <bzs at theworld.com>:

>
> On July 30, 2016 at 10:51 owen at delong.com (Owen DeLong) wrote:
>  > If they are using a website hosted or accelerated by your CDN to
> advertise
>  > an illegal activity or an activity in violation of your ToS, then if you
>  > have written your ToS properly, you are free to shut down said site (or
>  > at least your portions of it) based on their violation of your ToS.
>
> Well, yes, of course, which is why I suggested developing generally
> agreed upon definitions and writing them into contracts.
>
> One can't really write a useful contract if terms aren't well defined.
>
>  >
>  > That?s not a business boycott because you didn?t conspire with their
> other
>  > providers to shut it down, you took an independent action based on your
>  > own ToS.
>
> The issue arises if you shut them down when you're not the harmed or
> involved party.
>
> I don't know if one can write a ToS which says you will be shut down
> if you harm another party utilizing another party's services but not
> otherwise involving us. Well, you can write anything but is it lawful
> and enforceable?
>
> In some cases where that sort of thing has come up I've turned it into
> a credit relationship which has greater leeway.
>
> Something like:
>
>   It has come to our attention that you are engaged in activities,
>   even if not thus far involving our services, which might incur us
>   legal fees. Consequently we require a deposit to cover those legal
>   fees, in advance, of $10,000 [pick a number] with the understanding
>   that any such legal fees will be billable in full even if above and
>   beyond that $10,000 deposit. Since I extend you no credit a failure
>   to provide that deposit by [date in the near future] will result in
>   termination of services. Please feel free to contact us with any
>   questions or concerns.
>
> but consult your attorney, state and local regulations and your own
> ToS and corporate organization may affect how and whether you can do
> that sort of thing or exactly how it has to be architected.
>
> If one wants to one can include demand for indemnification with
> evidence of ability to indemnify and/or business insurance policies
> where you've been written in as a legitimate potential claimant for
> legal fees and damages assuming the business insurance policy covers
> that but as I said you need a lawyer to suss that out.
>
> They probably could still fight with you over all that if none of it
> was anticipated in your ToS (hint: might be something to add to a ToS,
> reserving the right to...blah blah.) Or even try to perfect an
> argument based on some theory of estoppel (you changed the conditions
> in a way which harms me the client.)
>
> More likely they'll ask for time and assistance to leave your service
> (in my experience), generally what you actually wanted. Buh-bye!
>
>  >
>  > There?s fairly wide latitude to ?reserve the right to refuse service to
>  > anyone?, especially if you can show that their use of said service is
>  > in violation of the contract(s) applicable to that service.
>
> Yeah well as any lawyer will tell you relying on broad principles like
> that rather than specifying covenants is just asking for legal fees :-)
>
>  >
>  > Owen
>  >
>  > > On Jul 29, 2016, at 12:36 , bzs at theworld.com wrote:
>  > >
>  > >
>  > > Unfortunately that raises the issue of what's generally termed in law
>  > > a "business boycott" which is at least tortiable if not illegal.
>  > >
>  > > The grocer can't agree with your landlord not to sell you food until
>  > > you catch up on the rent.
>  > >
>  > > They can agree to use this information to refuse you credit but even
>  > > that's quite constrained by law even if often done anyhow. And that's
>  > > a credit relationship so different.
>  > >
>  > > I went over this with my attorney when another ISP asked me to shut a
>  > > customer's account down because they were spamming them from a third
>  > > ISP's account.
>  > >
>  > > I asked to look at the emails (spam) in question and none originated
>  > > at our site. The acct in question on my site didn't do anything
>  > > problematic that I could find.
>  > >
>  > > My lawyer explained the above to me: You can't do that, business
>  > > boycott.
>  > >
>  > > The other ISP (specifically a sysadmin) who'd asked me to shut the
>  > > acct got so angry at this response, he took it all very personally and
>  > > unprofessionally, that I had to bring in his own legal dept to explain
>  > > this to him which he of course took as a further affront. It got ugly
>  > > but you don't need the details.
>  > >
>  > > That's the problem with all this folksy armchair "law", it's often
>  > > very bad advice and based on the assumption that the law must agree
>  > > with one's emotional feelings. Good luck with that.
>  > >
>  > > On July 29, 2016 at 08:08 rsk at gsp.org (Rich Kulawiec) wrote:
>  > >> On Thu, Jul 28, 2016 at 11:30:12PM +0000, Donn Lasher via NANOG
> wrote:
>  > >>> If we want to be accurate about it, Cloudflare doesn???t host the
> DDoS,
>  > >>> they protect the website of seller of the product. We shouldn???t be
>  > >>> de-peering Cloud Flare over sites they protect any more than we
> would
>  > >>> de-peer GoDaddy over sites they host, some of which, no doubt, sell
>  > >>> gray/black market/illegal items/services.
>  > >>
>  > >> This strategy fails for two reasons.
>  > >>
>  > >> First, nobody gets a pass.  Anybody providing services to abusers
>  > >> needs to cut them off, whether it's a registrar, a web host, an email
>  > >> provider, a DNS provider, or anything else.  Nobody gets to shrug it
>  > >> off with "Well, but..."
>  > >>
>  > >> Second, nobody *can* get a pass, because the people behind these
> operations
>  > >> have long since learned to distribute their assets widely -- in an
> attempt
>  > >> to avoid exactly the actions in the first point.  And you know what?
>  > >> It works.  "We're just hosting their email", says X, and "We're just
>  > >> hosting their DNS", says Y, and "We're just hosting their web site",
>  > >> says Z, and none of them do anything, and nothing gets done.
>  > >>
>  > >> The only way to make action against them effective is to do it
> broadly,
>  > >> do it swiftly, and do it permanently.
>  > >>
>  > >> ---rsk
>  > >
>  > > --
>  > >        -Barry Shein
>  > >
>  > > Software Tool & Die    | bzs at TheWorld.com             |
> http://www.TheWorld.com
>  > > Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
>  > > The World: Since 1989  | A Public Information Utility | *oo*
>  >
>
> --
>         -Barry Shein
>
> Software Tool & Die    | bzs at TheWorld.com             |
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*
>

From owen at delong.com  Sat Jul 30 22:47:37 2016
From: owen at delong.com (Owen DeLong)
Date: Sat, 30 Jul 2016 15:47:37 -0700
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <22429.328.693730.411532@gargle.gargle.HOWL>
References: <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
 <28E6FC71-F6FF-49B9-B861-3B573372594F@f5.com> <20160729120805.GA5869@gsp.org>
 <22427.45091.239632.929005@gargle.gargle.HOWL>
 <69ACB258-40B1-496D-A957-4A3283DC1976@delong.com>
 <22429.328.693730.411532@gargle.gargle.HOWL>
Message-ID: <98BA5A68-86E6-4BBA-A811-FE289FD00221@delong.com>


> On Jul 30, 2016, at 12:34 PM, bzs at theworld.com wrote:
> 
> 
> On July 30, 2016 at 10:51 owen at delong.com <mailto:owen at delong.com> (Owen DeLong) wrote:
>> If they are using a website hosted or accelerated by your CDN to advertise
>> an illegal activity or an activity in violation of your ToS, then if you
>> have written your ToS properly, you are free to shut down said site (or
>> at least your portions of it) based on their violation of your ToS.
> 
> Well, yes, of course, which is why I suggested developing generally
> agreed upon definitions and writing them into contracts.
> 
> One can't really write a useful contract if terms aren't well defined.
> 
>> 
>> That?s not a business boycott because you didn?t conspire with their other
>> providers to shut it down, you took an independent action based on your
>> own ToS.
> 
> The issue arises if you shut them down when you're not the harmed or
> involved party.

Not if they are using your service in a way that is contrary to the agreement
they have signed.

> I don't know if one can write a ToS which says you will be shut down
> if you harm another party utilizing another party's services but not
> otherwise involving us. Well, you can write anything but is it lawful
> and enforceable?

Probably not, but you wouldn?t do that anyway.

What you would write instead is that ?You shall not use the service to
carry out attacks or other malicious activity, nor shall you use the
service to advertise, solicit, or contract to carry out such actions even
if the actions themselves are carried out independent of the service.?

You can, of course, prohibit any action you want on your network, even
if the prohibited action isn?t the actual objectionable action.

> In some cases where that sort of thing has come up I've turned it into
> a credit relationship which has greater leeway.
> 
> Something like:
> 
>  It has come to our attention that you are engaged in activities,
>  even if not thus far involving our services, which might incur us
>  legal fees. Consequently we require a deposit to cover those legal
>  fees, in advance, of $10,000 [pick a number] with the understanding
>  that any such legal fees will be billable in full even if above and
>  beyond that $10,000 deposit. Since I extend you no credit a failure
>  to provide that deposit by [date in the near future] will result in
>  termination of services. Please feel free to contact us with any
>  questions or concerns.

Here you risk running up against a claim that this new requirement
is a change to the ToS which they haven?t agreed to and which,
depending on how well they negotiated the contract may not be
enforceable until it comes time for contract renewal and you add
this deposit to the terms of the new contract.

> but consult your attorney, state and local regulations and your own
> ToS and corporate organization may affect how and whether you can do
> that sort of thing or exactly how it has to be architected.

Always.

> If one wants to one can include demand for indemnification with
> evidence of ability to indemnify and/or business insurance policies
> where you've been written in as a legitimate potential claimant for
> legal fees and damages assuming the business insurance policy covers
> that but as I said you need a lawyer to suss that out.

Sure, but it?s questionable whether the aggrieved party has any legitimate
claim against the hosting company that merely hosted the site that
advertised the DDOS service in question.

Much easier to just prohibit advertising such a service in the first
place, IMHO.

> They probably could still fight with you over all that if none of it
> was anticipated in your ToS (hint: might be something to add to a ToS,
> reserving the right to...blah blah.) Or even try to perfect an
> argument based on some theory of estoppel (you changed the conditions
> in a way which harms me the client.)
> 
> More likely they'll ask for time and assistance to leave your service
> (in my experience), generally what you actually wanted. Buh-bye!

Yep? Unless they?re starting to run out of options.

>> There?s fairly wide latitude to ?reserve the right to refuse service to
>> anyone?, especially if you can show that their use of said service is
>> in violation of the contract(s) applicable to that service.
> 
> Yeah well as any lawyer will tell you relying on broad principles like
> that rather than specifying covenants is just asking for legal fees :-)

Sure, but my point is that specifically spelling out certain actions that
you refuse to provide service to is usually the easiest way to terminate
someone for committing such actions on your service.

Owen

> 
>> 
>> Owen
>> 
>>> On Jul 29, 2016, at 12:36 , bzs at theworld.com wrote:
>>> 
>>> 
>>> Unfortunately that raises the issue of what's generally termed in law
>>> a "business boycott" which is at least tortiable if not illegal.
>>> 
>>> The grocer can't agree with your landlord not to sell you food until
>>> you catch up on the rent.
>>> 
>>> They can agree to use this information to refuse you credit but even
>>> that's quite constrained by law even if often done anyhow. And that's
>>> a credit relationship so different.
>>> 
>>> I went over this with my attorney when another ISP asked me to shut a
>>> customer's account down because they were spamming them from a third
>>> ISP's account.
>>> 
>>> I asked to look at the emails (spam) in question and none originated
>>> at our site. The acct in question on my site didn't do anything
>>> problematic that I could find.
>>> 
>>> My lawyer explained the above to me: You can't do that, business
>>> boycott.
>>> 
>>> The other ISP (specifically a sysadmin) who'd asked me to shut the
>>> acct got so angry at this response, he took it all very personally and
>>> unprofessionally, that I had to bring in his own legal dept to explain
>>> this to him which he of course took as a further affront. It got ugly
>>> but you don't need the details.
>>> 
>>> That's the problem with all this folksy armchair "law", it's often
>>> very bad advice and based on the assumption that the law must agree
>>> with one's emotional feelings. Good luck with that.
>>> 
>>> On July 29, 2016 at 08:08 rsk at gsp.org (Rich Kulawiec) wrote:
>>>> On Thu, Jul 28, 2016 at 11:30:12PM +0000, Donn Lasher via NANOG wrote:
>>>>> If we want to be accurate about it, Cloudflare doesn???t host the DDoS,
>>>>> they protect the website of seller of the product. We shouldn???t be
>>>>> de-peering Cloud Flare over sites they protect any more than we would
>>>>> de-peer GoDaddy over sites they host, some of which, no doubt, sell
>>>>> gray/black market/illegal items/services.
>>>> 
>>>> This strategy fails for two reasons.
>>>> 
>>>> First, nobody gets a pass.  Anybody providing services to abusers
>>>> needs to cut them off, whether it's a registrar, a web host, an email
>>>> provider, a DNS provider, or anything else.  Nobody gets to shrug it
>>>> off with "Well, but..."
>>>> 
>>>> Second, nobody *can* get a pass, because the people behind these operations
>>>> have long since learned to distribute their assets widely -- in an attempt
>>>> to avoid exactly the actions in the first point.  And you know what?
>>>> It works.  "We're just hosting their email", says X, and "We're just
>>>> hosting their DNS", says Y, and "We're just hosting their web site",
>>>> says Z, and none of them do anything, and nothing gets done. 
>>>> 
>>>> The only way to make action against them effective is to do it broadly,
>>>> do it swiftly, and do it permanently.
>>>> 
>>>> ---rsk
>>> 
>>> -- 
>>>       -Barry Shein
>>> 
>>> Software Tool & Die    | bzs at TheWorld.com             | http://www.TheWorld.com
>>> Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
>>> The World: Since 1989  | A Public Information Utility | *oo*
>> 
> 
> -- 
>        -Barry Shein
> 
> Software Tool & Die    | bzs at TheWorld.com <mailto:bzs at theworld.com>             | http://www.TheWorld.com <http://www.theworld.com/>
> Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*


From eric at ericheather.com  Sun Jul 31 03:38:14 2016
From: eric at ericheather.com (Eric C. Miller)
Date: Sun, 31 Jul 2016 03:38:14 +0000
Subject: Brighthouse Orlando Port blocking ISAKMP
Message-ID: <DC85D08B84BB854086E9524DAB67D1877EBF2F34@Teriwood.miller.local>

Hello!

Subject says it all!!! I cannot open any IPSec tunnels, because UDP 500 is not making it through to my Brighthouse connection. I've tried from Level3, Cogent, and AT&T. Are there any Brighthouse engineers on that would help me shed some light on this?

Thank you,

Eric

From randy at psg.com  Sun Jul 31 03:46:54 2016
From: randy at psg.com (Randy Bush)
Date: Sun, 31 Jul 2016 12:46:54 +0900
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <CAPkb-7CScd5dTj6wWW7gWTrNCwnLHktw9ytTH7RmQb5SPawbxg@mail.gmail.com>
References: <CAHnQ7e+tCBMoLQ1eVLO8xtDNAznzDKbiDq7o9rjCa1CPLVKRZQ@mail.gmail.com>
 <CAJayEpF4jbEMfLCEcjgrZVnOo36RRO=gB0q4Jc6fDwtfj87jJA@mail.gmail.com>
 <f4d5a2c7-46a9-f259-f6f3-3d322d7b2aa5@meetinghouse.net>
 <9578293AE169674F9A048B2BC9A081B401E66668BE@MUNPRDMBXA1.medline.com>
 <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
 <28E6FC71-F6FF-49B9-B861-3B573372594F@f5.com>
 <20160729120805.GA5869@gsp.org>
 <22427.45091.239632.929005@gargle.gargle.HOWL>
 <69ACB258-40B1-496D-A957-4A3283DC1976@delong.com>
 <22429.328.693730.411532@gargle.gargle.HOWL>
 <CAPkb-7CScd5dTj6wWW7gWTrNCwnLHktw9ytTH7RmQb5SPawbxg@mail.gmail.com>
Message-ID: <m2lh0i8o5t.wl%randy@psg.com>

> This is silly. Anyone is of course allowed to deny service to parties
> involved in obvious criminal activity.

so block cloudflare from your network and go back to work already.

randy

From rsk at gsp.org  Sun Jul 31 12:39:47 2016
From: rsk at gsp.org (Rich Kulawiec)
Date: Sun, 31 Jul 2016 08:39:47 -0400
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <22429.328.693730.411532@gargle.gargle.HOWL>
References: <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
 <28E6FC71-F6FF-49B9-B861-3B573372594F@f5.com>
 <20160729120805.GA5869@gsp.org>
 <22427.45091.239632.929005@gargle.gargle.HOWL>
 <69ACB258-40B1-496D-A957-4A3283DC1976@delong.com>
 <22429.328.693730.411532@gargle.gargle.HOWL>
Message-ID: <20160731123947.GA6377@gsp.org>

On Sat, Jul 30, 2016 at 03:34:32PM -0400, bzs at theworld.com wrote:
> I don't know if one can write a ToS which says you will be shut down
> if you harm another party utilizing another party's services but not
> otherwise involving us. Well, you can write anything but is it lawful
> and enforceable?

Yes.  And it doesn't require that the activity be illegal, which is
a good thing because of what most of us recognize as abusive may or
may not be illegal depending on which legal professional is interpreting
the law, which law they're interpreting, and what jurisidction(s) apply.

I fired an 11-year customer in under an hour when I discovered them
spamming via one of the numerous spammers-for-hire out there.  This
activity had nothing to do with the services I was providing them,
but it fell under the provision that said (abbreviating liberally
from the legalese) "if you spam from anywhere, you're toast".
I didn't like doing it to a longtime customer, particularly because
they happened to be my biggest customer, but I did...because it
was the right thing to do, and because I had made it crystal-clear
to them when they signed on that I would do it without hesitation.

I expect the same from everyone else.  If I can do it without
the budgets, staff, and legal departments that so many far larger
operations enjoy, then so can they.  It's just a question of whether
or not they recognize their ethical, professional obligation to
the rest of the Internet and are willing to put that ahead of profit.

---rsk

From mark.tinka at seacom.mu  Sun Jul 31 12:58:13 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Sun, 31 Jul 2016 14:58:13 +0200
Subject: SAFNOG-3 Deferred to April 2017
Message-ID: <415ab9dd-9d13-e8e9-fc51-0afa56672fec@seacom.mu>

Hello all.

I, with much regret, have to inform you that due to unavoidable
circumstances, the SAFNOG-3 meeting has been deferred to our usual slot
in April of 2017.

Details have been posted to our web site at the link below:

    http://www.safnog.org/safnog-3-deferred-to-april-2017/

On behalf of the SAFNOG Management Committee, I sincerely apologize for
the inconvenience this will most certainly cause you, and look forward
to seeing you at the meeting in April of 2017.

For all delegates that had already registered to attend the meeting this
August, you will be automatically refunded in full.

If you have any questions, please do not hesitate to send an e-mail to:

	secretariat at safnog dot org

Details on the SAFNOG-3 meeting in April of 2017 will be communicated in
the coming weeks.

Mark Tinka
On Behalf of the SAFNOG Management Committee

From bzs at theworld.com  Sun Jul 31 21:36:55 2016
From: bzs at theworld.com (bzs at theworld.com)
Date: Sun, 31 Jul 2016 17:36:55 -0400
Subject: Cloudflare, dirty networks and politricks
In-Reply-To: <20160731123947.GA6377@gsp.org>
References: <20383357-93E7-4B19-B2DF-10FFDAD0F7A2@isprime.com>
 <CAKnNFz--RvWjGb_Dh0j68_Lwec8h7ODBio8FX_6LEdVjBPQxpw@mail.gmail.com>
 <9578293AE169674F9A048B2BC9A081B401E6666A3B@MUNPRDMBXA1.medline.com>
 <55A34C0A-015C-4353-9C5A-EF78A24182AE@isprime.com>
 <20160728171708.GA87119@e-fensive.net>
 <28E6FC71-F6FF-49B9-B861-3B573372594F@f5.com>
 <20160729120805.GA5869@gsp.org>
 <22427.45091.239632.929005@gargle.gargle.HOWL>
 <69ACB258-40B1-496D-A957-4A3283DC1976@delong.com>
 <22429.328.693730.411532@gargle.gargle.HOWL>
 <20160731123947.GA6377@gsp.org>
Message-ID: <22430.28535.860625.509197@gargle.gargle.HOWL>


Besides legal costs I've informed customers that I will charge them
(insert billable hourly rate) for any complaints or similar our staff
has to field beyond what we'd consider a normal volume which is pretty
low.

One guy who wasn't quite to the level of spamming as usually
conceived, not in intent, but ran a professional content list but had
a bad habit of wholesale adding mail addresses -- this was quite a
while ago when such things weren't so clear. I finally billed him
~$1,000 after several warnings and he paid it and said he understood
that our time is worth money.

I kind of felt bad because I didn't believe his intentions were in any
way malicious. Mostly he'd scrape similarly themed lists and websites,
but we really were getting quite a few complaints per day some which
merited responses...and he did run the list to promote his own
consulting. But at some point time really is money.

I suppose that sort of thing could be used in a case like this where
someone hosts a web site of questionable intent but never uses your
service to actually do anything questionable. If it incurs you costs
such as telling people you're not the right party it seems reasonable
to expect reimbursement. I think the law uses the term "attractive
nuisance".

Which of course leads to shutting someone down if they refuse to pay.
Again you've reduced it to just a credit or payment issue rather than
citing the content specifically other than perhaps as an explanation
why you're getting too many complaints.

-- 
        -Barry Shein

Software Tool & Die    | bzs at TheWorld.com             | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

From m at cyrixsys.com  Sat Jul 30 14:54:10 2016
From: m at cyrixsys.com (Mark Bodley)
Date: Sat, 30 Jul 2016 10:54:10 -0400
Subject: XO, Bad day?
Message-ID: <CAM9mRhNfWjrkmkPqSggd5DjNxbX0=uFUD0aJGJ027wf_yzY29Q@mail.gmail.com>

I am getting mass reports of problems on any ISP using XO for
longhaul/interconnect. Anyone @ XO care to share a status, and or ETR?